[Standards] certification etc.
Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Boyd.Fletcher at je.jfcom.mil
Wed Mar 28 10:59:50 UTC 2007
Fair enough those reasons make good sense. So I think most of us are in agreement now that stream compression should be required for servers. Optional for clients. But is the required going to be in basic or intermediate server profiles?
Btw, the community needs to push sun to get efficient xml into the next j2me release that would help out cell phone xmpp clients quite a bit.
USJFCOM J9/SPAWAR SSC SD
M: 757.535.8190 (GSM)
M: 757.771.7084 (BB)
Sent from my BlackBerry.
From: standards-bounces at xmpp.org <standards-bounces at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>
Sent: Wed Mar 28 01:33:03 2007
Subject: Re: [Standards] certification etc.
> 4) agree further discussion is needed but i haven't heard any
> technical arguments on why stream compression should not be
> required for clients.
Mostly because there are some environments (notably, as was already
pointed out, some Flash and web-embedded client situations) where
compression is exceptionally difficult. Additionally, there may be
other situations where Zlib simply cannot be included; clients built
in environments where, for security purposes, you cannot link to
anything outside a 'default kit' which might not even contain Zlib,
for instance. If you put stream compression in as part of XMPP Basic
Client requirements -- the 'deepest' level of specification, that
everyone must implement -- then you basically ensure no client in
that set will ever be able to gain certification.
Requiring it on servers at the most basic specification makes perfect
sense; it needs to be there to make the feature useful to the clients
that do implement it. Requiring it in clients seems not only
unnecessary, but counter-productive. :)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards