[standards-jig] The Jabber Transport, and File Transfer Too

Julian Missig julian at jabber.org
Mon Jun 10 19:48:11 UTC 2002


On Mon, 2002-06-10 at 12:31, Iain Shigeoka wrote:
> 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
> routers/firewalls/etc.
> 
> > 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.

I agree with all of the above, and I agree with Iain that I would much
rather have it be human-friendly if possible.

> 
> > 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...

Right, I thought part of the reason so many of the server people want to
move to SASL is that we could move to SASL everywhere, including the
possibility of SASL between components and servers.

Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org




More information about the Standards mailing list