[Standards] Proposed XMPP Extension: Service Discovery Notifications

[Joe Hildebrand]

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