[BXXPwg] some notes on the issue of ERR after multiple ANS

Joe Touch touch@ISI.EDU
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
sequence.

Joe