[BXXPwg] proposal for 1:N interactions

james woodyatt jhw@wetware.com
Wed, 30 Aug 2000 12:41:32 -0700

At 15:07 -0400 2000.08.30, Greg Hudson wrote:
>This argument doesn't make sense to me.  Acknowledging frames doesn't
>help you determine which frames were delivered or not in the case of a
>transport error; the error could occur during delivery of the
>acknowledgement, for instance, in which case the sender cannot tell
>whether the frame has been delivered.

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.

After an error occurs at the transport layer, it will be more than 
"nice to know" which, of the messages we have sent, are the ones that 
are not guaranteed to have been processed at the peer.  Whether the 
error occurs during the delivery of the first frame of the 
acknowledgement message or the last frame of the request message, the 
reliability guarantee does not hold-- i.e. "your request may or may 
not have been processed at the peer" is an error.

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?

j h woodyatt <jhw@wetware.com>