Subject: [NNTP] RE: Last Call: 'Network News Transfer Protocol' to Proposed Standard

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 24 May 2005 15:31:57 -0400

The IESG has received a last call comment that raises a question about the
status of RFC 2980 and the proposed new NNTP base specification.  2980 is
currently listed as an informative reference in draft-ietf-nntpext-base-26.
Is the new base spec supposed to obsolete 2980?

-Scott-

---

From: Ken Murchison <[email-masked]>
Date: Tue, 24 May 2005 15:53:52 -0400

> Is the new base spec supposed to obsolete 2980?

IMO, the combination of BASE, AUTHINFO, and STREAMING effectively 
supercede/obsolete the most common parts of 2980 (the recent discussion 
of LIST SUBSCRIPTIONS notwithstanding), and 2980 could probably be moved 
to historical for the remaining parts.

That said, others in the WG might disagree.

-- 
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: Tue, 24 May 2005 13:32:15 -0700

>> The IESG has received a last call comment that raises a question about
>> the status of RFC 2980 and the proposed new NNTP base specification.
>> 2980 is currently listed as an informative reference in
>> draft-ietf-nntpext-base-26.  Is the new base spec supposed to obsolete
>> 2980?

> That said, others in the WG might disagree.

There are a small handful of things for which RFC 2980 is still the only
available specification, but none of them are particularly
earth-shattering.  That being said, I'm not sure we want to decide to
obsolete RFC 2980 without some more thought and work on the things that
we've left out.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 25 May 2005 11:49:03 +0100

> obsolete RFC 2980 without some more thought and work on the things that

Making a quick scan, it contains the following:

CHECK                - in streaming document
MODE STREAM          - in streaming document
TAKETHIS             - in streaming document
XREPLIC              - deprecated as unnecessary
LIST ACTIVE          - in core document
LIST ACTIVE.TIMES    - in core document
LIST DISTRIBUTIONS   - no equivalent
LIST DISTRIB.PATS    - in core document
LIST NEWSGROUPS      - in core document
LIST OVERVIEW.FMT    - in core document
LIST SUBSCRIPTIONS   - no equivalent
LISTGROUP            - in core document
MODE READER          - in core document
XGTITLE              - deprecated in favour of LIST NEWSGROUPS
XHDR                 - replaced by HDR in core document
XINDEX               - deprecated in favour of OVER (?)
XOVER                - replaced by OVER in core document
XPAT                 - no equivalent
XPATH                - deprecated as not useful
XROVER               - deprecated in favour of HDR (?)
XTHREAD              - deprecated in favour of OVER (?)
AUTHINFO USER        - in authinfo document
AUTHINFO PASS        - in authinfo document
AUTHINFO SIMPLE      - deprecated in favour of AUTHINFO SASL
AUTHINFO GENERIC     - replaced by AUTHINFO SASL in authinfo document
DATE                 - in core document

Do people think this is correct?

It would seem to me that the best approach is:
* core, authinfo, streaming all "update 2980";
* a future work item is 2980bis, giving the contents of the above table
  (as corrected) plus specifications for the three remaining commands
  and any others we are/become aware of.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Wed, 25 May 2005 10:57:24 GMT

>Is the new base spec supposed to obsolete 2980?

I think RFC 2980 should remain for people who still want to use those
features (for sure, we could declare some of them like STREAMING, to be
obsoleted by the new drafts).

Anybody who continues to use these features will probably want to include
them in the CAPABILITIES response. It is pretty obvious what the correct
keyword to use should be (and for using XHDR, XOVER and XPAT as keywords
there is no need for formal action anyway because they begin with 'X').

So I think RFC 2980 should just be left there as a marginal anomaly that
causes no actual harm.

I do not think it would be a good idea to write a new draft to supersede
it, because then we would be forced to look seriously at XPAT. We decided
before that XPAT was a can of worms that we did not want to get bogged
down with, and I think that still remains the case. Someday, someone will
come up with a brand new clean command to do that job - if somebody does,
then an Experimental protocol would be the way to do it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 26 May 2005 11:57:29 GMT

>XOVER                - replaced by OVER in core document

Yes, but XHDR and XOVER are hard coded into too many existing agents, so
servers will need to provide them for many years to come (probably as just
synonyms for HDR and OVER). RFC 2980 remains as the justification for
their existence. I would expect servers that provide them to include
XHDR and XOVER in their CAPABILITIES.

This might be worth a brief mention somewhere, but I don't think any
2980bis is called for.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 26 May 2005 09:41:57 -0700

> Do people think this is correct?

Looks right to me, including the ones marked with a question mark.

>   and any others we are/become aware of.

Hm, yeah, that makes sense to me and would clear up the situation.  And
actually, if we do 2980bis, we should consider whether to include various
other extensions seen in practice (LIST MOTD and XBATCH are the main ones
that come to mind).  Assuming, that is, that no one writes them up for
standards track (I would assume that 2980bis would still be
informational).

---

From: Ken Murchison <[email-masked]>
Date: Thu, 26 May 2005 13:09:55 -0400

> XHDR and XOVER in their CAPABILITIES.

Actually I disagree.  What would be the point of advertising XHDR/XOVER? 
  If a client is updated to use CAPABILITIES, then it better damn well 
update itself to use HDR/OVER.  Any legacy client will get no benefit 
from "non-standard" extensions being advertised, because they won't be 
using CAPABILITIES anyways.

Obviously, any server which provides HDR/OVER probably SHOULD also 
support XHDR/XOVER as synonyms for backwards capability.