ietf-nntp Re: Last major open issue (48x return codes)

[Jeffrey M. Vinocur]

On Thu, 2 Oct 2003, Clive D.W. Feather wrote:

>    401: the client must change the state of the connection in some other
>       manner. The first argument of the response SHOULD be the
>       extension-label (see Section 8) of the extension that provides the
>       necessary mechanism.

I can see that SHOULD being really nasty for clients to parse.  Can we 
make it a MUST?  Probably then we'd need to do at least one of these:

    - provide a special first parameter that means "no specific extension
      is related, please display this string to the user"

    - point out that extension-labels starting with X are appropriate
      for local use


> Maybe I'm losing the plot here, but now that I read what I've written I'm
> not sure what an "authorization extension" would be. Lack of authorization
> means you need to present some kind of credentials to use the command that
> just failed. What those credentials are - if not related to identity or
> privacy - are going to be command-specific. Aren't they? Does anyone have
> an example, or even a sketch, of an authorization extension that I can look
> at to see why I'm wrong?

Here's a glimpse of a whim of an idea that might be relevant.

There's periodically discussion in news.software.nntp of better ways to
post multi-part binaries, and the discussion often drifts to the way that
Message-IDs are chosen or allocated by the server.  (Sometimes a
suggestion is made that the client might use a special command to
"request" a bunch of Message-IDs from the server.)

I can vaguely imagine that this might evolve into a situation where the 
client issues POST, and the server wants to respond with a code that says 
"must use this command to request Message-IDs before posting" -- and that 
wouldn't fall into either the authentication or privacy umbrellas.



-- 
Jeffrey M. Vinocur
jeff at litech.org