Joe Hildebrand wrote:
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. :)
Completely. :)
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.
Yeah I removed that from my working copy but didn't upload it yet.
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).
I think the MUST in XEP-0060 is a spec bug, because when you subscribe to the root collection node you don't include a 'node' attribute.
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.
Isn't disco#info handled by caps? It *could* be handled by this mechanism if presence isn't shared, but we're assuming that presence is shared.
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.
Simple clients, complex servers?
I can't think of a way to have both, either, since you would have to include the explicit subscription in all requests;
What might break if clients (and other entities) start including the <subscribe/> element in all their disco query requests? I suppose we'll find out (and any responding entity that breaks has a bug, since it must ignore elements it doesn't understand according to RFC 3920).
you don't know the capabilities of the receiver, since you would find those out from one of the requests in question.
Correct. You could find out from the disco#info response but then you'd need to block on receiving that before sending the disco#items query, which seems suboptimal.
As such, I guess I'm arguing for explicit subscription only.
I'm still pondering. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
