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

Jehan Jehan.3k7ei1 at no-mx.jabberforum.org
Wed Dec 10 12:59:32 UTC 2008


no feedback on this? Noone is interested? :-( On the same XEP, I have
other interrogations/remarks.

Aren't section "6.2 Discovering Capabilities" and "7. Determining
Support" nearly the same?

I understand that the separation is mostly to make the difference
between the case where there is a discovery query as a reaction to the
sent presence with caps, in order to know what is the capabilities of
the given node/ver/hash triplet (6.2) with the case where you just want
to determine support as entities currently do (7).

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

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.

One of the initial goal of this extension is to avoid the
"disco/version flood" (cf. 1.1 Motivation). Hence there should be no
"classical" service discovery query generated if the receiving entity
supports this "Entity Capabilities" extension as well. As a conclusion,
section 7 should not happen "in a perfect world". So my new change
propositions are:

1/ I would propose to change the intro text of section 7 like to
something like this:

> If all communicating entities supports "caps", there should be no
> service discovery information request sent other than one to learn the
> features associated to a caps information (section 6.2).
> Yet if an entity  (the "requesting entity") does not support caps and
> still wants to know another's entity's (the "generating entity")
> features, it may send a typical service discovery information request.
> In such case, the service discovery information response must have the
> exact same list of features that in section 6.2, including a feature of
> 'http://jabber.org/protocol/caps', the only difference in the request
> and response stanzas being the absence of the "node" attribute on the
> "query" element.

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> 

And finally a question: what do you call the "caps node" in this

> 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


Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=1175

More information about the Standards mailing list