[Standards] Proposed XMPP Extension: Service Discovery Notifications

[Peter Saint-Andre]

Joe Hildebrand wrote:
> 
> 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.

Oh, I thought you meant the subscribe, not the notify.

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

Well if I'm going to send presence to the groupchat service I might like 
to receive presence in return (what if the service goes offline?). I see 
this as similar to sharing directed presence in a one-to-one chat with 
someone who's not in your roster. But I suppose there's no guarantee 
that the service will reciprocate.

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

"One small step for clients, one giant step for the network."

Explicit subscribe would still require changes to lots of components, 
but the changes would not be as significant in scope as adding PEP 
everywhere.

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

Heh, true.

>> I'm still pondering. :)
> 
> Me too.

Another consideration is that a newly-connected client might send a very 
large number of service discovery requests. E.g., I have 1711 people in 
my roster. Will my client send a service discovery request to each one? 
If so, will include the <subscribe/> in each one? I don't see how it 
will determine whether to include the <subscribe/> (it can't do so based 
on the service discovery identity because we're saying that it might 
want to include the <subscribe/> in the disco#info request) so I assume 
it will do so in every request. Is that acceptable? Or is it better to 
go the PEP route? (Yes, there is more work involved on the component 
side, but clients can be relatively dumb yet get this functionality at a 
low cost. Perhaps there could be code re-use from servers that do PEP to 
components that want to. And this moves us a step closer to things like 
PEP in chatrooms.)

As I mentioned, it seems to me that we already have caps for dynamic 
communication of disco#info data. In my experience it's disco#items 
where we have the gap (the main use case I've heard about is wanting to 
find out about newly-created chatrooms at a groupchat service, but there 
may be others).

But I'm still pondering... :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080107/8a2df04d/attachment.bin