Subject: [NNTP] Working group last call

From: Russ Allbery <[email-masked]>
Date: Sat, 05 Mar 2005 17:15:05 -0800

I'm very sorry I've not been on top of this.  I got way behind on
everything not work-related.

I believe that with the last round of released I-Ds, we should be done.
I'm not aware of any remaining major open issues, just maybe some wording
and editing tweaks.  Accordingly, I would like to start a working group
last call for all of the following:

    draft-ietf-nntpext-base-25.txt
    draft-ietf-nntpext-authinfo-06.txt
    draft-ietf-nntpext-streaming-03.txt
    draft-ietf-nntpext-tls-nntp-04.txt

with the intention that, if no issues are discovered during the last call
period, the documents will be put forward for publication as Proposed
Standards together.

I will also be posting a message about this to news.software.nntp to make
sure that the broader NNTP community is aware that we did another round on
capabilities and now believe that we're done, and I'm also going to let
Mark Crispin know so that he can review the current documents.

The last call period will be two weeks from today, and will therefore end
March 19, 2005.  At that point, I expect that I'll put these documents
forward for IESG approval, possibly after a round of minor modifications
if we turn up necessary wording improvements.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 7 Mar 2005 11:51:44 +0000

> everything not work-related.

You're not the only one!

>     draft-ietf-nntpext-base-25.txt

I'm fine with that. I've just made a couple of minor wording tweaks based
on Ken's email.

>     draft-ietf-nntpext-tls-nntp-04.txt

These are older than base-25. They need to be reviewed and updated to
ensure they are consistent with it.

-- 
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: Ken Murchison <[email-masked]>
Date: Mon, 07 Mar 2005 11:32:54 -0500

> ensure they are consistent with it.

http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-07pre1.txt
http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-streaming-04pre1.txt
http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-05pre1.txt

-- 
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: Russ Allbery <[email-masked]>
Date: Mon, 07 Mar 2005 09:34:29 -0800

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-05pre1.txt

Consider the last call amended to apply to these documents, and I'm sorry
for not having realized / remembered they'd not been released as I-Ds
yet.  We're in a blackout window around an IETF meeting at the moment when
it comes to publishing new drafts, but I think that's okay for a working
group last call.  We can push out the I-Ds for the IETF Last Call.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Mar 2005 11:12:46 +0000

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-streaming-04pre1.txt

2.3.2 para 1: "If a server supports this extension ..." would be better.
Otherwise you're requiring the server to support MODE STREAM if it supports
MODE STREAM, which is a bit nonsensical.

Para 2: surely that SHOULD should be a MUST? A conforming implementation
MUST provide MODE STREAM, right?

---

From: Ken Murchison <[email-masked]>
Date: Tue, 08 Mar 2005 07:36:30 -0500

> MUST provide MODE STREAM, right?

This point keeps coming up, so obviously I'm not getting the text right. 
  I'm trying to convey that MODE STREAM is not required in order to 
implement or use this extension.  MODE STREAM is deprecated in favor of 
CAPABILITIES.

Perhaps I should start with:

"If a server supports this extension and the optional MODE STREAM 
command ..."

Russ, can you offer any insight?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Mar 2005 12:44:01 +0000

> "If a server supports this extension and the optional MODE STREAM 

Okay, let me try again.

I understand that a client SHOULD use CAPABILITIES to determine if the
extension is supported. A client should only use MODE STREAM if it's
concerned about old implementations. However, that's not my point.

Let me ask the same question in two ways:

Version 1: can an implementation conforming to your specification
NOT implement the MODE STREAM command?

Version 2: is the following allowed with a conforming server?

    [C] CAPABILITIES
    [S] 101 Capability list:
    [S] VERSION 2 
    [S] READER LISTGROUP 
    [S] LIST ACTIVE NEWSGROUPS
    [S] STREAMING
    [S] .
    [C] MODE STREAM
    [S] 501 Unknown mode STREAM

If the answer to both of them is "no", then you need my changes.

If the answer to both of them is "yes", then you badly need to rephrase
that text, because I thought it was a mandatory command.

If the answer to one is "yes" and the other is "no", somebody is *really*
confused.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Mar 2005 21:58:53 +0000

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-tls-nntp-05pre1.txt

Only one item: 2.2.2.1 para 1 line 5 says "with without"!

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 9 Mar 2005 12:15:59 +0000

> http://www.oceana.com/ftp/drafts/draft-ietf-nntpext-authinfo-07pre1.txt

Should 2.4.3 have an example of the 504 response code (for bad base-64
encoding)? Or is it unnecessary?

---

From: Ken Murchison <[email-masked]>
Date: Fri, 11 Mar 2005 13:36:32 -0500

> encoding)? Or is it unnecessary?

Added.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 11 Mar 2005 13:36:41 -0500

> Only one item: 2.2.2.1 para 1 line 5 says "with without"!

Done.

---

From: Ken Murchison <[email-masked]>
Date: Fri, 11 Mar 2005 13:42:17 -0500

> NOT implement the MODE STREAM command?

Yes, that was the idea.

>     [S] 501 Unknown mode STREAM

I think we'd like it to be since we're deprecating MODE STREAM, but this 
is probably an unrealistic goal in the short term for interop reasons.

Russ, how do you want to handle this?  Should we make MODE STREAM 
mandatory to implement for servers, but warn clients that this command 
should only be used with legacy servers, and that this command will be 
most likely removed from later versions of the specification?

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Sat, 12 Mar 2005 12:02:39 -0500

On Mar 11, 2005, at 1:42 PM, Ken Murchison wrote:

>>     [S] VERSION 2     [S] READER LISTGROUP     [S] LIST ACTIVE 
>> NEWSGROUPS
>>     [S] STREAMING
>>     [S] .
>>     [C] MODE STREAM
> I think we'd like it to be since we're deprecating MODE STREAM, but 
> this is probably an unrealistic goal in the short term for interop 
> reasons.

I see no reason to -require- servers that implement STREAMING to 
provide support for legacy clients.  As long as the text is clear that 
MODE STREAM would be used by such clients, I think server authors can 
decide for themselves whether or not to implement it.

> most likely removed from later versions of the specification?

Given that updated clients will be using CAPABILITIES, I think it's 
reasonable for us to forbid a client to send MODE STREAM if STREAMING 
is listed by the server.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: Russ Allbery <[email-masked]>
Date: Sat, 12 Mar 2005 23:38:43 -0800

>>     [S] VERSION 2     [S] READER LISTGROUP     [S] LIST ACTIVE NEWSGROUPS
>>     [S] STREAMING
>>     [S] .
>>     [C] MODE STREAM

> most likely removed from later versions of the specification?

I would tend to be conservative here, since if a server that supports
streaming and that's upgraded to support this specification drops MODE
STREAM, it will fail to interoperate with existing servers.  I think it
makes sense to make it mandatory (or at least a SHOULD) to implement on
the server side, but on the client side we should say that it's only for
compatibility with existing servers.  (I don't see the justification in
preventing the client from sending it, since sending it won't cause
interoperability problems, but I do think there should be a warning, as
you say, that the command will be dropped in a later verison of the
specification.)

---

From: Ken Murchison <[email-masked]>
Date: Sun, 13 Mar 2005 20:48:48 -0500

> you say, that the command will be dropped in a later verison of the

Here is the current wording.  I've just about reached the end of my 
word-smithing ability on this one, so any further change requests will 
have to be accompanied by suggested text.  ;)

"2.3. MODE STREAM Command

      Historically this command was used by a client to discover if a
      server supported the CHECK and TAKETHIS commands.  This command is
      deprecated in favor of the CAPABILITIES discovery command and is
      only documented here for compatibility with legacy implementations
      [NNTP-COMMON] of these transport commands.

      New clients SHOULD use the CAPABILITIES command to check a server
      for support of the STREAMING extension but MAY implement and use
      the MODE STREAM command for backwards compatibility with legacy
      servers that don't support the CAPABILITIES discovery command.
      Servers SHOULD accept the MODE STREAM command for backwards
      compatibility with legacy clients which don't use the CAPABILITIES
      discovery command.

      NOTE: This command will be removed from subsequent versions of this
      specification, therefore clients are urged to transition to the
      CAPABILTIES command wherever possible.

2.3.1. Usage

      Syntax
         MODE STREAM

      Responses
         203   Streaming permitted

2.3.2. Description

      If a server supports this extension and the MODE STREAM command, 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 the
      server state in any way.  A server MUST NOT require that the MODE
      STREAM command be issued by the client before accepting the CHECK
      or TAKETHIS commands."

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 14 Mar 2005 14:41:45 +0000

> have to be accompanied by suggested text.  ;)

Taking the view that the command is mandatory but discouraged, the

>      [NNTP-COMMON] of these transport commands.

s/documented/provided/

>      servers that don't support the CAPABILITIES discovery command.

s/implement and use/use/

["Implement" is, to me, what a server does.]

>      compatibility with legacy clients which don't use the CAPABILITIES

s/SHOULD/MUST/, since it's required for this version.

>      CAPABILTIES command wherever possible.

s/will be removed from subsequent versions/may be removed from a future
version/, since we don't know what issues will drive future versions.

>      If a server supports this extension and the MODE STREAM command, it

s/and the MODE STREAM command//, since it's mandatory.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Mar 2005 11:20:28 -0500

> following would satisfy me:

These changes look good to me.  Consider them done (sometime today).  If 
I don't hear different in the next day or two, I'll submit the new 
drafts to the I-D editor.