Subject: Re: [NNTP] Extension snapshots 3

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Feb 2005 14:26:07 +0000

Jeffrey M. Vinocur said:
> There's something askew grammatically there (the implicit subject of 
> the last clause is "a server," but the verb is "have").  I tried 
> rephrasing:
> 
> "If a server supports the MODE STREAM, CHECK, and TAKETHIS commands, it 
> MUST return a 203 response to the MODE STREAM command (or 501 if an 
> argument is given), [but / and] the command MUST NOT have any other 
> effect."
> 
> But that's a little awkward regardless of if I use "but" or "and"?  I'm 
> having trouble with this one.

"If a server supports the MODE STREAM, CHECK, and TAKETHIS commands, the
MODE STREAM command MUST return a 203 response (or 501 if an argument is
given), [but / and] MUST NOT have any other effect."

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Feb 2005 14:28:47 +0000

Ken Murchison said:
>> Your various CAPABILITIES examples need to be audited against the
>> latest [NNTP], to ensure that, for example, they have the correct LIST
>> arguments based on the other capabilities.
> Added LIST OVERVIEW.FMT to STARTTLS draft and LIST HEADERS to STREAMING 
> draft.  Did you see anything else missing?

I didn't do a full audit, just noted the point. Sorry.

>> STREAMING
>> 
>> 2.3.2: the last sentence contradicts the first. Since the first sentence
>> says it MUST support MODE STREAM if streaming works, the SHOULD in the last
>> sentence makes no sense. Just delete the last sentence.
> 
> OK, I see your point.  What I'm trying to say is that MODE STREAM isn't 
> required (because its deprecated by CAPABILITIES), but if supported, it 
> returns 203.

Isn't it easier just to require it? What's the benefit in allowing it to be
not provided?

>> 2.1. The sentence "However, ..." needs adjusting. Try:
>> 
>>     However, the capability MUST NOT be advertised once a TLS layer
>>     is active (see section 2.2.2.2), or after any alternative mechanism
>>     that installs a security layer (e.g. [NNTP-AUTH]).
>> 
>> Note the change to MUST NOT. The second bit is because, in principle,
>> STARTTLS after a USER authentication, or an SASL authentication that
>> does *not* set up a security layer, should be fine.
> 
> Not true.  Successful STARTTLS resets the state of the connection, so we 
> don't allow STARTTLS after *any* authentication.

Good point.

> Here's the current 
> sentence:
> 
> "However, this capability MUST NOT be advertised once a TLS layer is 
> active (see section 2.2.2.2), or after successful authentication 
> [NNTP-AUTH]."

Okay.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Feb 2005 10:00:08 -0500

> given), [but / and] MUST NOT have any other effect."

How about splitting the sentence, e.g.:

"If a server supports the CHECK and TAKETHIS commands it MUST return a 
203 response to the MODE STREAM command (or 501 if an argument is 
given).  The MODE STREAM command MUST NOT affect any changes on the server".

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Feb 2005 15:05:14 +0000

> given).  The MODE STREAM command MUST NOT affect any changes on the server".

I have difficulty with "affect" in that context.

The corresponding wording for MODE READER is:

    If the server is not mode-switching, then:
    * If it advertises the READER capability, it MUST return a 200 or 201
      response with the same meaning as for the initial greeting; in this
      case the command MUST NOT affect the server state in any way.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Feb 2005 10:12:30 -0500

> Isn't it easier just to require it? What's the benefit in allowing it to be

Based on Russ' input, we're deprecating it because its only use was as a 
limited capability discovery command.  In the presence of LIST 
CAPABILITIES, it really serves no purpuse.  We're only documenting it so 
that a VERSION 2 server can still support a legacy client (peer).

I'll defer to whatever Russ thinks is "the right thing".

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Feb 2005 10:13:53 -0500

>       case the command MUST NOT affect the server state in any way.

OK, I'll use "MUST NOT affect the server state in any way".

---

From: Russ Allbery <[email-masked]>
Date: Tue, 08 Feb 2005 09:05:23 -0800

>> Isn't it easier just to require it? What's the benefit in allowing it
>> to be not provided?

> I'll defer to whatever Russ thinks is "the right thing".

Yeah, I have a minor preference for leaving open the possibility that in a
future VERSION 2-only world, servers will stop bothering to implement it.
I don't feel strongly about it, but if it doesn't pose any problems I'd
rather go that route.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Feb 2005 20:04:44 -0500

> I don't feel strongly about it, but if it doesn't pose any problems I'd

So, are you happy with the wording in -03 plus the change suggested by 
Jeff/Clive?

---

From: Russ Allbery <[email-masked]>
Date: Tue, 08 Feb 2005 17:43:48 -0800

> So, are you happy with the wording in -03 plus the change suggested by

Yup!