[Standards] XEP-0115 redux

Rachel Blackman rcb at ceruleanstudios.com
Tue Jan 15 17:58:17 CST 2008


> However, we could opt to stuff that information into the caps  
> element anyway,
> just to save ourselves from having to transmit another element/xmlns:

Honestly, the only gain here is saving a few bytes (by not having  
another entire element), and at this point, this no longer really has  
any direct bearing on caps.  After all, the only association  
previously was that the disco#info identity element, and the client- 
unique nature of the original node#ver query, dovetailed nicely to  
allow you to cache client identity as an unintended benefit of the  
design (since you got that information when querying the features  
anyway).

With the node disconnected from the client identity, there's no longer  
that tie; the only reason we've still been discussing this is that in  
order to not LOSE previously-available information, clients would need  
to re-introduce the iq:version flood (which I think EVERYONE agrees is  
bad).  So really, the client identity stuff doesn't conceptually  
belong in caps anymore.

I DO agree putting client info like this into presence is a big gain,  
since if it's there, you just use it, and if it's not there, you  
assume the client does not want to offer it and do not go around  
mucking up the network with floods of queries.  But it's not  
conceptually really tied to 'capabilities,' and arguably stuffing it  
into XEP-0115 makes the XEP try to solve too many usage cases.   
Conversely, as noted, the only gain from keeping this tied into  
XEP-0115 is the saving of a couple of bytes.

(However, given how paranoid we as a community are about sticking too  
much stuff into presence, that small bandwith savings may be reason  
enough to merit stuffing it into caps.)

There's my take on it.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/




More information about the Standards mailing list