[NNTP] Extension snapshots 2

Ken Murchison ken at oceana.com
Tue Jan 4 10:40:29 PST 2005


Russ Allbery wrote:

>> Ken Murchison <ken at oceana.com> writes:


> There's no point in sending MODE READER after authentication, though; it
> won't do anything useful.  I think we need to make that clear to future
> implementors.

> 
> MODE READER has no purpose except with a mode-switching server or to cover
> one's ass just in case one is talking to a mode-switching server, so I
> think that we should describe how to send it unilaterally.

OK, I'm fine with this.  My question is what text goes where?  See below.



>>Ideally, a mode-switching server would discontinue advertising the MODE
>>READER capability after TLS and/or authentication.
> 
> 
> Oh, definitely.  Any client that can watch the capabilities won't have a
> problem with this.

OK, so should I state in AUTHINFO/STARTTLS that the MODE_READER 
capability (is this what we're calling it?) SHOULD (MUST?) NOT be 
advertised after successful authentication/TLS negotiation?

As an alternative (or in addition to the above) should I state in 
AUTHINFO/STARTTLS that client MUST NOT issue MODE READER after 
successful authentication/TLS negotiation?


> I don't see any reason to leave it that mild.  I would say:
> 
>     If a client intends to use the MODE READER command, it SHOULD issue it
>     before issuing any commands other than CAPABILITIES and MUST issue it
>     before any security or privacy commands are issued.
> 
> The client knows whether it wants to be a reader or a peer.  The only
> thing it needs to do before issuing MODE READER is to check whether it's
> needed.

Works for me.

Since the above text would go into the base doc and the issue of 
capabilities being added/removed as a result of other commands is also 
addressed in the base doc, I'm wondering what kind of text you want to 
see in the AUTHINFO and STARTTLS docs.  It seems to me that most, if not 
all, of the MODE READER issue can be addressed in the base doc, thus 
eliminating duplicate text in AUTHINFO, STARTTLS and any other 
security/privacy extensions down the road.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list