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

Chin Chee-Kai cheekai at SoftML.net
Mon Aug 7 02:30:19 PDT 2000


On Sat, 5 Aug 2000 23:11:32 +0100, "Clive D.W. Feather" <clive at demon.net> wrote,
>> Thoughts:
>> 
>> * If the command doesn't have any multiline responses, assume that unknown
>>   codes are not multiline.

I presume this is referring to multiline *data* responses in above.
One example is "GROUP" command, which produces only a single
line protocol response currently.  If multiline *protocol*
response is introduced, an implementor may use it to debug
"GROUP" command, such as:
	[C]: GROUP rec.humor.funny
	[S]: 211-[DEBUG] Before GROUP, group-ptr=""
	[S]: 211-[DEBUG] After  GROUP, group-ptr="rec.humor.funny"
	[S]: 211 11 1072 1111 rec.humor.funny selected

So it cannot be assumed that current commands which give 
one-liner *data* response will not have multi-line *protocol*
response (if this were the case, it'd defeat the purpose of having
multi-line mechanism for sending multi-line protocol response
for whatever reasons, such as debugging, annotations, site-to-site
administrative notes, etc).



>> * If all legitimate 2XX responses are multiline (I don't think we have
>>   any multiline responses that *aren't* 2XX, do we ?), then assume that
>>   an unknown 2XX is multiline, but nothing else is.

This requires all clients to know what exactly is all known (and valid)
2XX response for each command.  So instead of looking at first digit
"2" and knowing immediately that this is an OK response, a client 
will have to have a database of error codes to see which command has 
which valid 2XX code, kinda undo the ease of parsing the 3-digit 
error code.



>> * If some 2XX responses are multiline, but not all, it's harder.

If "multiline" here means "multiline data response" (as per current
RFC977), then, sure, examples are "BODY" and "HEAD".
If "multiline" here means "multiline protocol response", then,
such response may occur for any and all commands as all commands
are subject to debugging or annotations by the implementor.



>> * You could send something innocuous and unusual, like DATE, then:
>>   - if the next line of input begins 111, the odd response was on its own;
>>   - otherwise the next line was multiline, so skip down to the dot.

Is this suggesting that "111" is a "non-multiline-marker"?
And, if the first line of input to the client is not "111", then
where does the client stop interpreting the input lines as part
of the meta-data protocol response or the actual data response?
What'bout other commands?  



>> * You could assume that any further lines will appear within 10 seconds,
>>   so do a read with timeout on the socket.

If server needs to send only 1 protocol response line, does this
mean now that the client must wait for more than 10 seconds to
conclude that there's only a 1-liner response?
Besides, I won't assume everyone has very good modems/link-ups.



Just some comments on the alternative thoughts.


Cheers,
CK




More information about the ietf-nntp mailing list