[BXXPwg] proposal for 1:N interactions

Greg Hudson ghudson@MIT.EDU
Wed, 30 Aug 2000 16:05:58 -0400

> I should correct myself then.  They're needed to sort out which
> frames are guaranteed by BXXP to have been delivered to the peer
> before the transport erred.

Fair enough.  It doesn't seem like a protocol would want to use 1:0
interactions when it wants this information.  I see 1:0 interactions
as being mainly useful for "requests" of the form, "here is a piece of
information about me which you need to know to continue interacting on
this channel."  If a transport error occurs, you're just going to
start over anyway, so you don't need a reponse.

Another possible use for 1:0 interactions is a "no-op" command which
an endpoint can send for the sole purpose of provoking a TCP RST
packet if the other endpoint has disappeared ungracefully.  Since
keepalives pose a bandwidth issue to start with, you don't want to
double the packet overhead by requiring an application-level response.
I suppose you could do this directly with BEEP/TCP if you could
convince your BEEP implementation to send a gratuitous SEQ message.

> This conversation makes me wonder why we are proposing to change
> 'REQ' and 'RSP' to 'MSG', 'RPY', 'ANS', 'NULL' and 'ERR'-- did I
> miss an important interchange at the IETF meeting?

Well, there was consensus that we wanted to support 1:N interactions
for N != 1.  I don't know how much of that consensus came from a
desire to more naturally map protocols like LDAP, where one request
can result in multiple responses, and how much came from a desire to
more efficiently support requests which don't need a response.