Comments about XEP-0115 v.1.5pre5 (SVN)

Hi!

It seems to me that new version 1.5pre5 of XEP-0115 (Entity
capabilities) contains unnecessary complications (in
comparison with
more clear 1.4).

I think that it's not a good idea to send disco#info query
to a
specific node (concatenated node and ver attributes).
Instead, queries
should be sent to peer's JID without any node (as it is
specified in
version 1.4 of the XEP).

If I understand correctly, this change was made for two
reasons:
1) to make disco#info query the same as in version 1.3 of
the XEP;
2) to prevent race condition when disco#info query is sent
after the
peer has changed features list (so, the new features list
generates a
different hash value).

The first problem I see is that a client which indeed able
to change
its features must remember hashes for all possible
combinations of
features (at least those combinations which appeared in the
current
session). Otherwise, it simply can't answer disco#info
query
correctly.

The second problem is that the answer to a disco#info query
doesn't
reflect a current client capabilities. So, the XEP
introduces another
race condition (which is worse in my opinion). Moreover,
since the
hash can be calculated in my client, I can hash the peer's
capabilities without any info from his presence. And it's
likely that
the next capabilities hash in the presence packet will be
this new one
and not old one (which should reduce a network traffic
little bit).

As for compatibility with clients supporting version 1.3 I
would say
that it should be optional and separately described. (If you
don't see
algo attribute then send disco#info to a node#ver. If you
receive
query to node#ver then reply to it or whatever.) Probably
the 'node'
attribute should be made optional too and should be used
only if a
client wants to be compatible with 1.3. But if it's
desirable then
some degree of compatibility may be required.

Cheers!
-- 
Sergei Golovan

Le jeudi 30 août 2007, Sergei Golovan a écrit :
> I think that it's not a good idea to send disco#info
query to a
> specific node (concatenated node and ver attributes).
Instead, queries
> should be sent to peer's JID without any node (as it is
specified in
> version 1.4 of the XEP).

I fully agree with that.



> As for compatibility with clients supporting version
1.3 I would say
> that it should be optional and separately described.
(If you don't see
> algo attribute then send disco#info to a node#ver. If
you receive
> query to node#ver then reply to it or whatever.)
Probably the 'node'
> attribute should be made optional too and should be
used only if a
> client wants to be compatible with 1.3. But if it's
desirable then
> some degree of compatibility may be required.

Correct.

Node attribute should maybe become unique for all client.


And why should we put the version number in the node ?
If it is to substitute the XEP-0092, I think it's the wrong
way. (Because it 
break compatibility with xep-0115 1.3  (if the capabilities
doesn't change 
between versions 1.3.4b to 1.3.4c)

> And why should we put the version number in the node ?
> If it is to substitute the XEP-0092, I think it's the
wrong way. (Because it 
> break compatibility with xep-0115 1.3  (if the
capabilities doesn't change 
> between versions 1.3.4b to 1.3.4c)
>   

Personally I think the client version information should be
carried in 
the disco#info using XEP-0128 using a new special FORM_TYPE
(maybe even 
reusing using jabber:iq:version and using its elements as
the xdata 
field names).

Richard

> On Aug 30, 2007, at 10:01 AM, Richard Dobson wrote:
>> Personally I think the client version information
should be  
>> carried in the disco#info using XEP-0128 using a
new special  
>> FORM_TYPE (maybe even reusing using
jabber:iq:version and using  
>> its elements as the xdata field names).

Or it could be split out as a separate attribute.

   <c xmlns='http://jabber.org/pro
tocol/caps'
      node='http://exodus.jabbers
tudio.org/'
      ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='
      v='0.9.1'/>

Where the v attribute SHOULD be included.

-- 
Joe Hildebrand

>>> Personally I think the client version
information should be  
>>> carried in the disco#info using XEP-0128 using
a new special  
>>> FORM_TYPE (maybe even reusing using
jabber:iq:version and using  
>>> its elements as the xdata field names).
>
> Or it could be split out as a separate attribute.
>
>   <c xmlns='http://jabber.org/pro
tocol/caps'
>      node='http://exodus.jabbers
tudio.org/'
>      ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='
>      v='0.9.1'/>
>
> Where the v attribute SHOULD be included.

So, we ripped the version out, reused the ver tag as a hash
of the  
nodeless disco query results, then have decided you can no
longer  
query on that (since the hash may change as features are
added/ 
removed, and so the hash is not necessarily a valid disco
node)...  
and now we are putting the version back into caps, albeit in
a  
different attribute.

To me, this begs the question of why we do not simply:

   <c xmlns='http://jabber.org/pro
tocol/caps'
      node='http://exodus.jabbers
tudio.org/'
      ver='0.9.1'
      hash='8RovUdtOmiAjzj+xI7SK5BCw3A8=' algo='sha1'/>


In the new version, the 'ver' option would be /optional/; if
present,  
you do still need to present your base options to legacy
clients, but  
will continue to interoperate with legacy clients fine, and
-- for  
newer ones -- will have not only the nice hash for
verification, but  
the version for display purposes.  

-- 
Rachel Blackman <rcbceruleanstudios.com>
Trillian Messenger - http://www.trillianastr
a.com/

Le jeudi 30 août 2007, Rachel Blackman a écrit :
> >>> Personally I think the client version
information should be
> >>> carried in the disco#info using XEP-0128
using a new special
> >>> FORM_TYPE (maybe even reusing using
jabber:iq:version and using
> >>> its elements as the xdata field names).
> >
> > Or it could be split out as a separate attribute.
> >
> >   <c xmlns='http://jabber.org/pro
tocol/caps'
> >      node='http://exodus.jabbers
tudio.org/'
> >      ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='
> >      v='0.9.1'/>
> >
> > Where the v attribute SHOULD be included.
>
> So, we ripped the version out, reused the ver tag as a
hash of the
> nodeless disco query results, then have decided you can
no longer
> query on that (since the hash may change as features
are added/
> removed, and so the hash is not necessarily a valid
disco node)...
> and now we are putting the version back into caps,
albeit in a
> different attribute.
>
> To me, this begs the question of why we do not simply:
>
>    <c xmlns='http://jabber.org/pro
tocol/caps'
>       node='http://exodus.jabbers
tudio.org/'
>       ver='0.9.1'
>       hash='8RovUdtOmiAjzj+xI7SK5BCw3A8='
algo='sha1'/>
>
>
> In the new version, the 'ver' option would be
/optional/; if present,
> you do still need to present your base options to
legacy clients, but
> will continue to interoperate with legacy clients fine,
and -- for
> newer ones -- will have not only the nice hash for
verification, but
> the version for display purposes.  

This is not compatible with legacy client.
anyway, putting the hash in the ext='' would be ok.


But should the version be included?
Also, what about the operating system and his version? and
the architecture?