[Standards] Missing point in XEP-0115: Entity Capabilities ?

Dave Cridland dave at cridland.net
Wed Dec 10 15:51:44 UTC 2008

On Wed Dec 10 12:59:32 2008, Jehan wrote:
> Hi,
> no feedback on this? Noone is interested? :-( On the same XEP, I  
> have
> other interrogations/remarks.
This message is the only one in my mailbox with this subject - maybe  
I'm missing your earlier one.

> Aren't section "6.2 Discovering Capabilities" and "7. Determining
> Support" nearly the same?
No. 6.2 is concerned with expanding the caps data into a proper list  
of supported features, whereas 7 is concerned with explicitly  
discovering if XEP-0115 is supported by an entity which might not  
have sent presence at all.

> So yes, we can keep maybe the distinction, but it should be precised
> then that the answer is absolutely the same (fortunately, you don't
> change your capabilities from a stanza to another!) in both case,  
> except
> for the "node" attribute which is not present in classical service
> discovery, shoudn't it?
> The way it is presented currently, it looks like it is a completely
> separate stanza with a different answer, hence it is perturbating...
The features needn't, actually, be the same, although it'd be  
slightly odd. If you're not sending presence to someone, then you  
might choose not to offer, for example, VOIP features to them.

> Moreover I would even add that the classical service discovery from
> section 7 should be deprecated when both entities know how to use  
> the
> caps extension.
Not all entities exchange presence information.

> 2/ And the example 4 must be changed. It does not include a feature  
> of
> 'http://jabber.org/protocol/caps'! Here the right stanza:
> >
> > <iq from='romeo at montague.lit/orchard' id='disco1'
> > to='juliet at capulet.lit/balcony' type='result'>
> > <query xmlns='http://jabber.org/protocol/disco#info'
> >  
> node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
> > <identity category='client' type='pc'/>
> > <feature var='http://jabber.org/protocol/disco#info'/>
> > <feature var='http://jabber.org/protocol/disco#items'/>
> > <feature var='http://jabber.org/protocol/muc'/>
> > <feature var='http://jabber.org/protocol/caps'/>
> > </query>
> > </iq>
> >
Possibly - of course, caps is essentially advertised by its use - I'm  
not really sure of the point of advertising it in disco#info at all,  
since either you can see it happening, or else it simply doesn't  
affect you. Perhaps it's useful for marketing purposes.

> And finally a question: what do you call the "caps node" in this
> sentence:
> >
> > Note: The generating entity SHOULD NOT include the "caps node" in  
> the
> > list of entities it returns in its disco#items responses; i.e.,  
> the caps
> > node is a kind of virtual or phantom node, not a true items node  
> that is
> > associated with the generating entity for service discovery  
> purposes.
> >
> Is it the "node" attribute in the "query"? So is the goal of this
> sentence just to say that this attribute must not be set in  
> response to
> a non-caps service discovery request (which seems logical, because  
> it
> means nothing out of caps)? Then the sentence should probably be  
> made
> clearer (in my opinion) because I was looking where the term "caps  
> node"
> was given previously in the XEP (set between quotes here!), and it  
> was
> not.

No, that's not what its saying - it's saying that the node advertised  
by caps shouldn't be listed in a disco#items response - ie, the node  
shouldn't be discoverable.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list