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

Jehan Jehan.3k7otn at no-mx.jabberforum.org
Wed Dec 10 16:42:14 UTC 2008


Hi,


Dave Cridland;5492 Wrote: 
> 
> This message is the only one in my mailbox with this subject - maybe  
> I'm missing your earlier one.
> 

Here is my first message:
Jehan;5452 Wrote: 
> Hi,
> 
> I was rereading lately the XEP-0115 and one strange point strikes me
> (aïe!) in section "5.4 Processing Method". It seems explained that
> whether you know or not the sent entity capability verification string
> "ver", you send anyway a service discovery stanza to the generating
> entity!
> 
> Considering the fact that one of the main point of this XEP is in order
> to avoid <em>the older "disco/version flood" behavior</em> (cf. "1.1
> Motivation" own word), I guess this is an error.
> 
> I propose -- reading all this procedure -- that a point 4 should be
> added (and placed in fact before point 3!) to something like:
> 
> <<
> Else if the set formed by the "node", the verification string "ver" and
> the "hash" is globally cached, then consider the verification string as
> validated.
> >>
> 
> Then the current point 3 (will be 4) will be a "else if..." (thus the
> verification string is not known yet, although the used hash function is
> supported by the application).
> 
> Finally note also that the second part of the current point 3.9 (will
> be 4.9 if the former proposition is approved) is useless:
> 
> <<
> however, it SHOULD check the service discovery identity and supported
> features of another generating entity who advertises that value.
> >>
> 
> Indeed the first part of the point 3.9 specifies that the verification
> string will not be globally cached. Hence there will be anyway a new
> service discovery query to all further entity which will send the same
> verification string.
> Regards,
> 
> Jehan


> 
> 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.
> 
> [...]
> 
> Not all entities exchange presence information.
> 

Oh right, I haven't thought of this case. And anywa,y as I said, there
is also the case when the querying entity does not support caps. But
then both cases should be written down into the XEP to make things
clearer, no? Give the precision that normal disco request should not be
used if every entity uses caps and has received a presence, in order to
avoid disco flood would be nice.
This was my point.

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

True.

> 
> 
> > 2/ And the example 4 must be changed. It does not include a feature 
> 
> > of
> > 'http://jabber.org/protocol/caps'! Here the right stanza:
> > [...]
> > 
> 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.
> 

This is logical and I wouldn't really see it a problem if it was not
included. But then I foresee one issue: the verification string uses
(among other things) the features (that's its goal). Then:

- if the generating entity doesn't advertize caps in the disco result,
should it all the same use it to generate the verification string?
- when the querying entity receive the answer to the disco request, and
if ever the generating entity didn't advertize caps, should the querying
entity add it to make its check (cf. 5.4 Processing Method), as it is
obviously supported (because both entities have just used it!)?

This is possible, why not. But then I am worrying we may be adding a
little complexity by having to handle these cases instead of "simply"
read down the feature list and compute the check (stupidly, but securely
at least. It is often better to have "stupid" procedure than
"intelligent" one, in my opinion).

Note also that in this XEP, all other examples of the disco result
advertizes caps (in the intro: "1.2 How it works"; generation examples
in 5.2 and 5.3). Only this example 4 does not.

> 
> 
> > And finally a question: what do you call the "caps node" in this
> > sentence:
> [...]
> 
> 
> 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.
> 

Ah oki. Yes, now that you explain me and when I reread the sentence, I
understand it this way. 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




More information about the Standards mailing list