[standards-jig] NEW JEP: Inband Bytestream (JEP-0047)
thoutbeckers at splendo.com
Mon Sep 30 11:01:17 UTC 2002
Justin Karneges <justin-jdev at affinix.com> wrote on 30-9-2002 2:25:47:
>> Why BASE64? Surely there are more compact encoding mechanisms?
>> For example: http://b-news.sourceforge.net/
>> I don't think this particular method would work in XML, but the
>> theory behind it can be applied to have less than the 33% hit that
>> BASE64 has.
>Looks interesting. Can someone else comment on this?
B-news and yEnc are meant for Usenet. Problems that arise are that some
of the characters they use are not fit for XML (<>&'"). Also they are
not meant for UTF-8, wich means some of the characters they asume are 1
byte long will actually take 2 bytes. I know that yEnc (b-news neither
I think) does *not* use the = CR LF characters while for Jabber/XML
this would be no problem. Even NULL should work I think. So we could
adapt all their work and make something that's actually effective with
UTF-8 and XML, but this wouldn't help UTF-16 clients much.
Overall, I think BASE-64 isn't such a bad solution, it's not so hard to
decode and less CPU intensive (think of the embedded / mobile clients).
Maybe someone could write a module for the server that allows a 7-bit
character streams instead of UTF-8? :) This would make Base64 a lot
We should at least keep Base-64. I think an addition to better
integrate it with something like your Stream Negotiation Protocol (is
there a JEP for it yet? or did it die a silent death?) is needed for
JEP-0047 in any case.
More information about the Standards