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

[Chin Chee-Kai]

Just got back from Bangkok and gotta filter through all
these prime number threads from recent IETF meeting mails.


On 3 Aug 2000, Russ Allbery wrote:

>>Chin Chee-Kai <cheekai at SoftML.net> writes:
>>
>>> Given a choice, I'll still go for the "-" continuation method
>>> as this has been done, deployed and used extensively.
>>
>>Not in NNTP.

True, not yet.  That's why I raised it for discussion.  
Understand that the WG has strict static scoping rules,
but as continuation method discussion arose from the
thread on patching up the missing parts if the DEBUG command
was removed, I thought it worth a while to introduce a 
summary of the many ideas and comments brought up by a
number of people.  Should the DEBUG command be removed,
the continuation method (whichever that goes into the
final version) will serve as a mechanism for arbitrary
debugging text to be included without affecting the 
multi-line data portion of the NNTP responses (difference
between protocol response and data response being explained
at length in my earlier mail).


>>#include <std_working_group_scope_comment.h>

It's good to be reminded from time to time if discussions
have gone off track.  Help me out here, we doing "gcc -g -Wall ..."
to debug RFC977, or  "gcc -O2 ..." to optimize WG output here?


>>Possibly worth discussing on the NNTP extensions mailing list, but I
>>personally dislike seeing more than one type of multiline response in a
>>given protocol.

The continuation mechanism discussed is not "more than one type 
of multiline response" -- it is one mechanism to introduce 
multi-line *protocol* response, which up till draft-10, is still 
a single line thingie messed up with some data response on the 
same physical line at times (e.g. GROUP).  It might have been 
an optimization at the time RFC977 was written since bandwidth 
was very scarce then.   A continuation mechanism for the 
*protocol* response will have to be compatible with the 
multi-line *data* response which requires a DOT CRLF trailer.


>>NNTP already does have a multiline response mechanism that's usable;
>>it's not as flexible as the method used by FTP and SMTP,
>>but that in and of itself I don't think is sufficient justification to
>>introduce a new method.

True, but the current mechanism is for multi-line data response.  
When we talk about sending debugging information lines as part of the 
"response" (generically), we will be forced into using the DOT CRLF
mechanism to continue what is actually meta-data protocol response,
if we don't delineate clearly between data and protocol response.
For e.g., for debugging purposes, if we send:

	[C]: BODY 1024 CRLF
	[S]: 222-[DEBUG] newsgroup="rec.humor.funny"
X	[S]: 222-[DEBUG] article="1024"
	[S]: 222-[DEBUG] size=237
	[S]: 222-[DEBUG] curmem=1.43Mbytes
	[S]: 222 1024 <acct at nowhere.net> article retrieved  CRLF
+	[S]: It was said that the 13 was not a prime in some culture.
	[S]: ................
	[S]: DOT CRLF

client would start displaying text from "X" onwards to the user,
instead of correctly displaying from "+" onwards.


Correct me if I'm wrong, but if there's no multi-line protocol 
response, then our debugging information MUST NOT (RFC style) be
more than 497 bytes in all for all responses.  Do we all agree
that is pretty sufficient for this draft revision?

I'm not saying that the discussed multi-line protocol response
should be in this upcoming draft, but I do think there's a
vacuum generated if the WG comes to consensus to remove the
DEBUG command.  This vacuum seems to me to be nicely filled up
by the continuation method discussed for the protocol response.


Cheers,
CK