[standards-jig] JNG Ramblings.

Iain Shigeoka iain.shigeoka at messaginglogic.com
Fri Aug 9 16:53:11 UTC 2002


As another person that telnets into the server regularly to check behavior,
I'll have to say that binary is a bummer.  If efficiency (wire and code) and
computer friendliness were the highest priorities, we might as well drop XML
as the packet format too.  There are much more efficient ways of creating
and reading binary formatted messages that don't require parsing XML.

I think a pure ascii text protocol (UTF-8 but limited to ascii) is the best
internet protocol format because of its hackability.  I can telnet into an
SMTP server anywhere and send an email with no tools (beyond telnet) and
almost no knowledge of the protocol itself (hell you can even type "help" on
most systems as part of the protocol and get the available commands).  The
same applies to almost all largely deployed internet protocols.

I keep banging on the BEEP drum (thanks for plugging it as well David)
because it is there, an IETF standard, and it basically works.  I understand
there are problems with its larger requirements (breaking Jabber simplicity)
but we don't have to use the whole BEEP standard.  We could define a subset
of BEEP specifically for Jabber so that Jabber on BEEP would work on any
BEEP compliant system/library (but Jabber on BEEP systems wouldn't
necessarily support all BEEP features like multi-packet responses and
anything requiring sophisticated windowing).

The only real drawback to BEEP that I see is that you still need to count
octets in the packet in order to generate the frame which is pretty
unfriendly to someone typing in things to talk to the server.  To
accommodate direct human-to-BEEP interaction, I might propose a small
modification to break some of BEEP to provide for non-octet counting based
framing...  Maybe just unique begin/end text tags ala multi-part mime.

-iain

PS - I wouldn't be that opposed to coopting some of the APEX stuff too if it
seems like it would be useful.  I like the APEX idea that routers and end
points are not the same (although they could be).  This seems to be much
more ISP friendly and creates the real possibility of moving a lot of the
server bottlenecks into hardware (the APEX router stuff).




More information about the Standards mailing list