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

[Clive D.W. Feather]

Russ Allbery said:
> I don't mind throwing out a new response code on the MODE READER case, but
> I think it's complete overkill for that particular case.

If this were the only case, I'd agree.

> 480, on the
> other hand, is simply set in stone.  We can't start using another code for
> "need authentication"; we'd just gratuitously break all the clients.

Okay.

> The privacy angle *is* new, which is why we did develop a generic solution
> to that problem, namely reserving the 48x response block for "need to
> negotiate security features."

See below.

>> The problem *is* a generic one.
> I still don't really believe this.

If we want a future-proof specification, it is going to have to be a
generic one:

>> We have stated, as a principle, that extensions MUST NOT issue unknown
>> response codes to base commands before the client invokes the
>> extension. We have been given examples of extensions that want to issue
>> new response codes to base commands.
> One of the reasons why we said that extensions shouldn't cause new
> unknown response codes to be returned for base commands is that this is a
> poor design.  There should be a way to avoid this.

Right.

> Security features are
> a special case in that their whole point is to interfere with base
> commands; for other extensions, you generally want to introduce a new
> command.

I'm not convinced this is specific to security features. They're the most
obvious case, yes, but I really really hate to say there won't be any
others.

>> Here's an example of an extension that might need this. Remember the HOST
>> proposal of a few months ago? Well, consider:
>> (1) A server provides several newsbases, and doesn't want to provide a
>>     default. It therefore needs to reject some commands until HOST has
>>     been issued.
> Okay, this is a good example.  The drawback of using 502 for this
> situation is that the client doesn't really know that what's missing is
> that it needs to issue a HOST command.  That's the first really good
> example I've seen.

Thanks. And that's just one thing that happens to have come up. Sod's Law
says the next good example will come up just after we reach RFC status.

> So, given that we can't change 480, do we want to introduce a new response
> code just for a privacy layer and for this extension (since MODE READER is
> kind of irrelevant and it doesn't matter what we use for it)?

I don't want to do it just for this extension, no.

> One alternative to doing this in this draft is to introduce it with a
> later draft, such as the one that introduces HOST.  We *can* amend the RFC
> with a later standards-track RFC, after all.

Yes, but then we've broken anyone who relied on the specification we'd
published. I don't like doing that if it can be avoided.

>> (2) A server wants to provide a response to GROUP meaning "I've got it
>>     on another HOST; you'll need to select that".
> This is a bad example,

Perhaps. But perhaps there's a similar example which someone can think of.


> Right now, the best response code we have for the "must issue HOST first"
> case is 502, which sucks because it's lying about being a permanent
> failure.

Right.

> Bear in mind that there is no requirement that we future-proof NNTP.  It's
> perfectly reasonable to produce additional standards-track documents down
> the road amending this one, and the problems with introducing a new code
> won't be any worse then than they are now.

Except that we'll have published *the* new NNTP standard, so incompatible
changes will be unpopular.

> (I really, *really* want to get to last call, since what we have is
> drastically better than RFC 977 already.)

Agreed.

Okay, can you live with all (or even some) of the following?

(1) We've already reserved x8x for authentication and authorization
extensions; expand that to include "privacy".

(2) Allow any existing command to return 48x to mean that such an extension
is blocking the action. Possibly limit this to 48[0-3].

(3) Go further, and recommend 480 for authentication, 483 for privacy, and
482 for authorization. [Query 1: what's the difference between
authentication and authorization? Query 2: will anyone scream if we change
483 to 481?]

(4) Provide 401 as a generic "you need to jump through a hoop" response for
any hoops other than auth/auth/priv.

(5) Recommend that the first word after 401 is the label of the extension
that defines the hoop.

(6) State that the MODE READER case SHOULD use 401, but historically uses
502.

I'll look at wording changes on this basis when I get a moment.

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