ietf-nntp DEBUG command

[Chin Chee-Kai]

On Mon, 24 Jul 2000, Clive D.W. Feather wrote:

>> section-4d1.txt: Assumes DEBUG is mandatory, and restricts private extensions
>>                  to x8x responses.

Draft-10 indicats that,

In Draft-10,
[==========
   11.  Other Keywords
   There are other keywords that may be used at any time between
   the beginning of a session and its termination.  Using these
   keywords does not alter any state information, but the
   response generated from the use of these keywords may provide
   useful information to clients that use them.
==========]

The "may" on lines 1 and 4 should really be "MAY".  These "MAY"s
suggest that the client can try to issue these "Other Keywords"
during the course of the session.  However, the draft is not clear
on whether these "Other Keywords" are mandatory for a server, 
although by assumption of it being grouped with other important
commands such as NEWGROUPS and NEWNEWS, it seems to be mandatory.

I would go a little further by suggesting the removal of "DEBUG"
as a keyword specified in this replacement of RFC977, which 
incidentally does not have a DEBUG command at all.  What RFC977
does is to allocate a response space reserved for debugging.  
How implementors like to use this space is up to them.  For instance,
if an implementor tries to add a non-standard new command 
"RELAY hostname", it could use the x9x space to reply "290 Ok"
if its experimental client issues this non-standard keyword "RELAY".
The implementor shouldn't be required or made obligated, through
the existence of a "DEBUG" specification, to use "DEBUG" to debug
the new changes.

I think on the debugging aspect, it may be better to follow the
spirit of RFC977 by maintaining a message space x9x for the
server and remaining stateless about the debugging mode.  Adding
the DEBUG command doesn't help the implementors as it may not be
the most suitable mechanism for the process or feature being 
debugged, doesn't help the administrators as this posts a 
security risk, and doesn't help this draft discussion
process as it makes all the x9x allocation and talks redundant
(as this stateful DEBUG command allows both server and client
to know they are in debugging mode and so can or should behave
differently.  This means that even a "200 OK" in debugging mode
can really mean "290 OK" in non-debugging mode).




On another related note, there is one other aspect which RFC977
and draft-10 don't seem to address, which is the required response
of clients when they received unexpected x9x messages (such as
"290", which may mean OK, but is for debugging purposes).  A suggestion
here is to force the client to flag error as debugging results
may not be reliably used for further processing.  With the new
extensions mechanism in this revision, there may be more clients
facing experimental or debuging x9x messages accidentally.

In Draft-10 Page 5,
[==========
   By default, a server implementation
   MUST NOT send debugging responses. Such behavior MUST only
   occur when specifically activated. See section XX for
   information on the DEBUG command.
==========]

suggested change (with reference to suggested removal of DEBUG
above) -->

[==========
   A server implementation MUST NOT send debugging responses to
   documented responses stated in this specification.  A client
   implementation WILL NOT normally receive a debugging response.
   But if it does, it MUST treat the response as 500 as if the
   server had not recognised the client's issued keyword.
==========]



Cheers,
CK