[standards-jig] The Jabber Transport, and File Transfer Too
iainshigeoka at yahoo.com
Mon Jun 10 16:31:22 UTC 2002
On 6/9/02 8:22 PM, "Mike Lin" <mlin at mlin.net> wrote:
> 1. Length Prefixed Framing
Agreed. In addition to the reasons you site, framing makes it much more
feasible to do things in hardware, intelligently configure
> 2. Maximum Packet Size
Agreed. Actually, I don't like a hard limit so much as an ability for a
server or packet to refuse the current packet due to size, and suggest an
acceptable size. So you send your packet header and start to stream data
saying a packet of size X is coming. The recipient can send a packet back
to the sender suggesting a new maximum packet size. If the sender continues
to send beyond that size, the connection is dropped. To avoid the rough
behavior, senders should query the recipient for maximum packet size to make
sure this doesn't happen.
> 3. Inline Binary Data
Yes. With framing, this should become simple. You could indicate what
should and should not be binary, and then send arbitrary binary packets.
BEEP shows an elegant mechanism for doing this, using XML for control, and
any arbitrary data on other channels.
> -- Begin Speculative Wire Protocol --
> -- End Speculative Wire Protocol --
I like the basic ideas. Binary headers is probably going a little too far
into computer-simple, human-hard protocol design. Something a little more
human friendly would probably work better. I'm going to keep harping on
BEEP since it provides human-friendly framing, plus channels (which we could
exploit in so many ways), and is already an ietf standard.
> The most critical problem that remains to be solved for this or any
> other proposal moving forward is security. The recent work with SASL has
> been great, but client-server authentication is not the real problem.
> Dialback today is somewhat acceptable for preventing packet forging;
> however, it has difficulty with firewalls and is insufficient for
> multi-hop routing. Totally end-to-end trust based on PKI will be
> necessary but probably not sufficient moving forward.
True. Although there is nothing preventing us from using SASL between
servers and requiring a certificate exchange. Since it is servers, we could
realistically use a CA for truly secure s2s connections...
More information about the Standards