On Jan 4, 2008, at 2:30 PM, Peter Saint-Andre wrote:
Where the JID was implicit from the from address, and the node was
implicit from the disco query node. As such, the JID in the
subscription tag and (potentially) the notification seem superfluous.
Agreed. You want to send to full JID, not bare JID.
Yes, always, for this application. The fact that I think XEP-60
should also be like this is *completely* immaterial. :)
The node in the notification should be the node of the disco
request, not disco#items.
I assume that most of the time the node will be empty (e.g., you're
temporarily subscribing to "conference.jabber.org" and not any
special node there), though naturally you could subscribe to a
specific node if appropriate.
Specifically, I'm talking about examples 4 and 5. The items element
has a node attribute. I would expect that to only be there if the
original request had a node (in the disco sense) in it. The node is
required in the XEP-60 schema, so there has to be something, but it
would be nice to be able to distinguish the "no node" case from a
disco publish (see section 5 of XEP-30).
Looking at the proto-xep this morning, I realized that I think we
should allow this for disco#info as well. The use case is that the
admin reconfigures a component at run time with connected clients.
On the implicit/explicit bit, after thinking about it some more, I
really don't want to have to implement caps in all of the components
that are going to use this. I can't think of a way to have both,
either, since you would have to include the explicit subscription in
all requests; you don't know the capabilities of the receiver, since
you would find those out from on of the requests in question. As
such, I guess I'm arguing for explicit subscription only.
--
Joe Hildebrand
