[Standards-JIG] Proposed: Simplified Client Caps

Chris Mullins chris.mullins at coversant.net
Sun Nov 20 20:12:10 UTC 2005


Jep 115 as it sits now introduces significant complexity into client
development. Clients need to perform caching, numerous discovery
requests, and provide handlers for a number of discovery responses. 

In addition, JEP 115 increases the bandwidth of both presence and
message stanzas by adding opaque capabilities into them. 

A simplification of this JEP would allow more clients to implement it,
and greatly increase compatibility between clients.

My proposed solution to this (which has probably been considered at some
point) is to make the client capabilities NOT opaque. 

This means that instead of:
<presence>
  <c xmlns='http://jabber.org/protocol/caps'
     node='http://exodus.jabberstudio.org/caps'
     ver='0.9'/>
</presence>

The client would announce
<presence>
  <c xmlns='http://jabber.org/protocol/caps' features='xhtml
filetransfer continueconversation' />
</presence> 

Then, via the Jabber Registrar, the client would translate:
'xthml' -> <feature var='http://jabber.org/protocol/xhtml-im'/>
'ft' -> <feature
var='http://jabber.org/protocol/si/profile/file-transfer'/>

This eliminates the need for disco requests, serving disco responses,
caching, and a number of other complex use cases. 

I see no obvious downside to this when compared to the current JEP 115.
It's roughly the same presence bandwidth, with a complete elimination of
the disco infrastructure. It allows client to modify the capabilities at
any time during a session. 

It makes client startup with large rosters much faster as well, as the
time taken f

The only additional work is "shorthand" for the various registrar items.


Given the growing popularity of stream compression, I would even be find
abandoning the shorthand and using the complete registrar feature name. 

-- 
Chris Mullins



More information about the Standards mailing list