[Standards] Re: compliance levels for 2008
rcb at ceruleanstudios.com
Sat May 5 00:05:56 UTC 2007
> 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...
More information about the Standards