[standards-jig] JNG Ramblings.
mikelin at MIT.EDU
Fri Aug 9 17:23:09 UTC 2002
Well, one thing is for sure, is that we don't want make ourselves do our
own BEEP implementations because we bastardized the protocol. BEEP
implementations are quite heavy with channel management and flow
control, and amount to 50% of a user-space TCP implementation - on top
of TCP. Use existing BEEP implementations, or don't use it at all. A
framer for the protocol I laid out is an order of magnitude less complex
than a BEEP implementation.
We are already dumping telnet-and-type in Jabber by switching over to
SASL authentication, which requires cryptographic operations on every
There are reasons to use a binary protocol for framing, and reasons to
use an XML protocol for extensibility. I am trying to blend the two. I
don't know if it's right, that's why I'm implementing it to find out.
It would be trivially simple to write a program that lets you type
messages to the server, and wraps it in the binary frame for you.
On Fri, 2002-08-09 at 12:53, Iain Shigeoka wrote:
> 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.
> 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).
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards