[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