[Standards-JIG] JEP-0163 (PEP) comments

Peter Saint-Andre stpeter at jabber.org
Thu Jul 20 21:07:07 UTC 2006


Ralph Meijer wrote:
> As promised in the council, here my list of comments:
> 
>  - In both JEP-0060 and JEP-0163, there is mention of advertising:
> 
>      <feature var='http://jabber.org/protocol/pubsub'/>
> 
>    I'm not sure if this is useful when the identity has category 'pubsub',
>    or is this to enable possible other future protocols?

In general, JEP-0030 says you must advertise what namespaces you
understand. I suppose the information is a bit redundant, but JEP-0030
assumes that it may not be obvious which namespaces you support based on
the category.

>  - 4.1, note #3 mentions access models advertised via disco. We removed
>    that from JEP-0060 and here one should just fetch the default config
>    form.

Yes, I'd already fixed that in my working copy -- it was an oversight in
the last round of edits.

>  - The SHIM 'replyto' field is used for conveying the origin of the
>    message. How does this relate to pubsub proxies of foreign nodes
>    (Atom-over-XMPP). Also, does it go inside the item or not? Example
>    208 in JEP-0060 seems to have it there. I'm not sure what is good
>    form now.

I think the form in Example 208 of JEP-0060 is correct because it is
possible for each item to be received from a different collection or
(regarding "replyto"). In PEP, there is only one publisher (the account
owner), so making the replyto a child of <message/> seems to make sense.
But then where does the address go in generic pubsub? E.g., it is
possible for each generic pubsub notification to be generated by a
different entity (if the node has multiple publishers) and so we might
want to have a different replyto for each item. But that's not what
Example 212 of JEP-0060 shows -- instead, there the replyto is, again, a
child of <message/>. Perhaps if we want to keep track of publishers we
would do that with a SHIM header (like Example 208) rather than a
replyto address (as in Example 212). Given that JEP-0033 addresses are
always shown as the child of <message/> rather than placed anywhere in
the stanza (as we do with SHIM headers), I think that the current
examples are fine.

What do you think?

>  - The reply to a <subscribe/> is not examined, assuming that in the PEP
>    case, it always succeeds? Should we change JEP-0060 to have an empty
>    reply mean success?

The example in JEP-0163 is wrong, since the empty IQ-result shown there
is not consistent with JEP-0060. Fixed in my working copy.

>  - In 6. Is <subscriptions/> supported?

You mean the "retrieve subscriptions" use case? Right now that is
optional. Do you see a need for it to be recommended or mandatory?

>  - 7.1. Item 3. Only when that subscriber would be a recipient of
>    notifications?

Er, yes, of course. Maybe I'm missing something, but why would the
service send a notification to an entity that is not a subscriber, and
isn't the definition of subscriber essentially "a recipient of
notifications"?

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060720/e0fdf6b6/attachment.bin>


More information about the Standards mailing list