[NNTP] Notes on auxiliary documents

[Jeffrey M. Vinocur]

On Nov 11, 2004, at 11:37 AM, Ken Murchison wrote:

>> Section 2.2: "Servers are not required to accept unsolicited 
>> authentication". I don't follow this. Since the server advertises its 
>> conformance with this document (through CAPABILITY / LIST 
>> EXTENSIONS), it is soliciting authentication. The only way I can read 
>> this is that, despite that, authentication is not permitted *until* a 
>> 480 happens.
>
> Correct, I think this is what Jeff is trying to say.  That the client 
> can go ahead and authenticate without having received a 480 response 
> and the server must accept authentication even is not prompted by a 
> 480. Essentially, this sentence is to be paired up with the first 
> sentence of the previous paragraph.

Well, Clive's initial read is correct.  Before we had the strong 
extension discovery mechanism we do now, the original text was trying 
to document existing practice.  And presently there's quite a mess 
about AUTHINFO, in that some servers will return a non-empty group list 
(and thus not issue 480) despite having additional private groups that 
appear after authentication.  Thus many newsreaders have an "always 
send username/password even when not prompted" option.

And from that point of view, without LIST EXTENSIONS, Ken's comment is 
correct that

     A client MAY attempt the first step of authentication at any time
     during a session to acquire additional privileges without having
     received a 480 response. [...] Servers are not required to accept
     unsolicited authentication information from the client, therefore
     clients MUST accommodate servers that reject such authentication
     information.

was intended to be one coherent thought.  (And I think it is, in fact, 
quite sensible, as documentation of current practice.)

But I think Clive's observation is correct, that this doesn't make much 
sense with extension discovery.  So I guess this is another spot that 
needs rewording to distinguish interoperability with old servers as 
separate.

Ken, given the above, can you edit, or do I have to come up with 
something concrete?  :-)

-- 
Jeffrey M. Vinocur
jeff at litech.org