[Standards] Proposed XMPP Extension: Service Discovery Notifications

[Joe Hildebrand]

On Jan 7, 2008, at 10:53 AM, Peter Saint-Andre wrote:

>> 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.

I'm not sure.  Notifications there come in a collection tag, not an  
item tag.

>> 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.

You often won't get caps from a component.  I'm imagining that I want  
to get the disco#info of a groupchat service, and get notified when  
the admin modifies the config.  I never did get presence from the  
groupchat service.

>> 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?

Small change to clients that have to be modified, large change to lots  
of different places in servers, including caching, hashing, and state  
management.

>> 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).

+1.  The biggest issue I would expect is programs that expect the  
query to be empty swapping to/from, and adding to the existing query  
element.  In that case, you'll receive the subscribe element back,  
which is why I'm glad that we look for "subscription" in the response.

> I'm still pondering. :)

Me too.

-- 
Joe Hildebrand