[Standards] Re: compliance levels for 2008

[Rachel Blackman]

> Basic Client includes Service Discovery which is probably essential  
> to any client that wants to deal with different clients other than  
> it's own exact version.  Probably a safe assumption.  But it also  
> includes Entity Capabilities, which seems to assume that a Basic  
> Client needs to go to extra efforts to conserve bandwidth.  If this  
> is the assumption, why exclude XEP-0138 Stream Compression?

Caps needs to be supported even on clients which are not bandwidth- 
starved, for it to be useful to the clients which /are/.  After all,  
caps is mostly useful when the majority of clients support /sending/  
caps information, whether or not they themselves need to save  
bandwidth and so would require caps for /receiving/.

Sure, maybe Superclient 1.0, a high-end desktop-only multimedia  
client, doesn't need to save bandwidth.  But MobileChatter 2.3, over  
on that wireless PDA via a paid data plan, probably does... and  
unless Superclient supports caps, then any MobileChatter connection  
is going to still have to query each contact on its roster that uses  
Superclient individually, generating a lot more traffic.  If  
Superclient supports caps, MobileChatter only needs to query a  
Superclient contact once and then tada, it has the capabilities list. :)

I'd expect that an XMPP Server specification will eventually be  
written with stream compression a requirement, and probably an XMPP  
Mobile specification will have stream compression a recommended or  
required element.  But caps needs to be widely supported by /all/  
clients in order to be fundamentally useful.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20070504/2795c4ce/attachment.htm