Hi, 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='[EMAIL PROTECTED]/orchard' id='disco1' > to='[EMAIL PROTECTED]/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 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. Thanks. Jehan -- Jehan ------------------------------------------------------------------------ Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911 View this thread: http://www.jabberforum.org/showthread.php?t=1175
