[Standards-JIG] JEP-0163 (PEP) comments
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
> - 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
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
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
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards