[2] [standards-jig] NEW JEP: Inband Bytestream (JEP-0047)

Tijl Houtbeckers 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 
more effective. 

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 mailing list