ietf-nntp DEBUG command x9x (was: 9xx)

[Chin Chee-Kai]

On Mon, 31 Jul 2000, Charles Lindsey wrote:

>>May I suggest the following convention for X9X?
>>
>>Such a response should NEVER be used as the only response to a command
>>(i.e. it should always be followed/preceded by the normal response).
>>Therefore, an implementation that simply ignores an X9X response as if it
>>had never been seen would still function correctly. In other words, an X9X
>>response is simply a comment from the server that might or might not be
>>'helpful' to a client.

At least up till draft-10, I haven't seen a distinction between
NNTP's protocol response and the actual data of news articles.
RFC977 and draft-10 for that matter treat both classes of data
as "response".  Herein lies perhaps an inherent problem when we
try to introduce multiple lines of protocol responses such as
the x9x or 9xx lines.  Current RFC977, draft-10, and most (or
all?) clients require a DOT CRLF after multi-line responses 
(interpreted as inclusive of both protocol and data responses).  

If multiple physical response lines are desirable by this WG,
it may be necessary to elaborate further in the draft what a
protocol repsonse is.  It could be a single logical response
but physically continued using continuation mechanism such as
x9x, 9xx or the "-" in the 4th character of all but the last 
physical line as used in FTP.   One must define that such multiples 
of physical lines continued in this manner does not require DOT CRLF.
The DOT CRLF termination will also need to be clarified to terminate
only multiple data line responses.  

Given a choice, I'll still go for the "-" continuation method
as this has been done, deployed and used extensively.  Of course,
the x9x and 9xx methods, when properly and clearly defined, will
serve the same function.  I see the intended purpose to be pretty
much the same as those used in "-" knowledgeable clients, such as
FTP programs.  So there's no clear purpose in trying to introduce
another continuation convention.


Cheers,
CK