[BEEPwg] Trouble with TLS and transport mappings

Jered Floyd jered@permabit.com
21 Nov 2001 15:26:00 -0500


> i don't think beep has enough in it to solve the byzantine generals'
> problem.

I agree entirely.  But I believe that it is our responsibility in
defining a standard to avoid issues that are open to interpretation,
or that allow applications to get into untenable states.

Either the definition of BEEP should be expanded to address issues
that could affect implementation interoperability, or (much
preferably) BEEP should be restricted so that the situation cannot
occur.  I believe that my most recent concern is addressed by the
following change in Section 3.1.3.1:

  [...]; similarly, the receiving BEEP peer must wait until any
  pending replies have been generated and sent before it processes
  a "ready" element.

changes to:

  [...]; similarly, the receiving BEEP peer may wait until any
  pending replies to messages that have been fully received 
  have been generated and sent before it processes a "ready" 
  element.


In any case, the specification should document recommendations to
implementors on how to be good network citizens.  This is also why I
previously brought up the lack of recommendation to avoid sending many
small frames (as appears in TCP).

Yes, I am being obtuse.  Yes, I am being pedantic. But BEEP is a
standards track RFC, and I'd like to see it become a standard.


I'll be out of contact for the remainer of the week and early next.
To the US participants of this list, happy thanksgiving!

--Jered