[BXXPwg] some notes on the issue of ERR after multiple ANS
Thu, 21 Dec 2000 16:30:18 -0800
This regards the issue of multiple ANS followed by NUL,
and whether there should be provisions for ERR as an
alternate to NUL, as raised at the San Diego IETF...
The primary issue is how and what errors are mapped
to BEEP errors, and whether it is necessary to provide
for errors after an ANS sequence commences.
There are two parts:
1. that BEEP ERRs encode application errors,
as opposed to only BEEP protocol errors.
On this point, the ID indicates (page 11) that
many BEEP MSG framing errors do NOT generate BEEP ERRs
(the session is terminated without a response). So the
BEEP ERRs do not indicate BEEP-level protocol errors.
Later the ID indicates that the code attribute of an
error is a 3-digit value meaningful to programs, indicating
that it is an _application_ level error message (page 22).
Thus ERRs indicate application errors, so it is
relevant to consider what the implication of
ANS terminated only by NUL is.
2. The ANS format thus asserts that multiple ANS
cannot be terminated by an application
ERR. That makes assumptions on the kind of errors that can
be encoded as BEEP ERRs - that they can occur only prior
to beginning a reply.
There is no reason to believe that this is necessarily the case.
Further examination of the IDs have convinced me that
it would be prudent to make the change to allow the ANS...ERR