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

[Clive D.W. Feather]

Jeffrey M. Vinocur said:
>>    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?

I'd be happy, but I wasn't sure how it would play here.

> 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"

"-" seems the obvious choice (you can't have dash in extension-labels).

>> 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.

Right: that's a perfect example of a "hoop" that we hadn't though of. But
if we suppose this is done though the GETMSGID extension, the correct
sequence is then:

    C: POST
    S: 401 GETMSGID You need to ask for message-IDs first
    C: GETMSGID 10
    S: 291 Here they come
    S: <123 at example.com>
    S: <456 at example.com>
    ...

What I actually meant was, is there such a thing as a *generic*
"authorization extension" that justifies its own 48x *generic* response and
which justifies the use of the word in the description of x8x responses?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646