[Standards] Proposed XMPP Extension: Service Discovery Notifications

[Peter Saint-Andre]

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/

-------------- 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/bda37682/attachment.bin