ietf-nntp NNTP AUTH draft update

[Chris Newman]

--On Thursday, November 18, 1999 12:50 -0500 Howard Swinehart
<howard at redrose.net> wrote:
> How about allowing the client to send it's own list of extensions
> after it receives the server's extensions?  The server then uses this
> information to decide which response codes to send.  If the client
> sends no extensions list, send it the old responses.

Jim Calvin <jcalvin at ll.mit.edu> wrote:
> Why not something a bit more straightforward. Like:
>
> [C] MODE 977BIS (or READER xxx, or whatever, to describe this rev of 
> the spec compliance)
>
> [S] 20x 977bis compliant client acknowledged

I'm uncomfortable with generic two-way option negotiation.  Telnet, in
particular, is a great example of what not to do.  I'm also uncomfortable
adding an extra round trip to a protocol which is already a bit "chatty".

However, the observation that the "MODE READER" command is already a form
of client capability command is a good one.  Perhaps extending "MODE" to
take a list of client capabilities (e.g., READER and x5x for starters)
would be reasonable.

I could support a client capability command if:
(1) Client capabilities were disjoint from server capabilities (to avoid
the telnet mess).
(2) Use of client capabilities was discouraged (to avoid an arbitrary mix
of client and server capability announcement).  Text like this would make
me happy:

    In general, NNTP is extended by having the server advertise behaviors or
    capabilities in response to "LIST EXTENSIONS" and have the client choose
    to use them or not.  In a few exceptional circumstances it is useful to
    have the client announce behaviors or the ability to process certain
types
    of responses which may occur as a result of multiple commands.

Do people prefer this approach to the "LIST EXTENSIONS" side-effect
approach, or the approach of retroactively staking a cliam on the
private-use error code space?

		- Chris