[NNTP] Changes from RFC 977 / RFC 2980

Clive D.W. Feather clive at demon.net
Thu May 19 02:54:26 PDT 2005


Russ Allbery said:
>> Since I suggested that we add an appendix that lists the changes that
>> we're making to RFC 977 and RFC 2980, I thought I'd take a first stab at
>> it.  Here's what I came up with, which may not be an exhaustive list.
> This list looks good to me, combined with the additions from Charles.
> Clive, if you're comfortable with this, could you include it in the draft?

I've used that list as the basis for a new appendix (I think I spotted one
or two other matters).

Section 1, paragraphs 3 and 4 are now largely redundant and have been
replaced by:

   While the protocol specification in this document is largely
   compatible with the version specified in RFC 977 [RFC977], there are
   a number of changes which are summarised in Appendix D.  In
   particular: 
   o  the default character set is changed from US-ASCII [ANSI1986] to
      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
   o  a number of commands that were optional in RFC 977 or have been
      taken from RFC 2980 [RFC2980] are now mandatory;
   o  a CAPABILITIES command has been added to allow clients to
      determine what functionality is available from a server.

Then the new Appendix D:

   Appendix D.  Changes from RFC 977
   
   In general every attempt has been made to ensure that the protocol
   specification in this document is compatible with the version
   specified in RFC 977 [RFC977] and the various facilities adopted from
   RFC 2980 [RFC2980].  However, there have been a number of changes,
   some compatible and some not.
   
   This appendix lists these changes.  It is not guaranteed to be
   exhaustive or correct and MUST NOT be relied on.
         
   o  A formal syntax specification (Section 9) has been added.
      
   o  The default character set is changed from US-ASCII [ANSI1986] to
      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8).  This
      matter is discussed further in Section 10.
      
   o  All articles are required to have a message-id, eliminating the
      "<0>" placeholder used in RFC 977 in some responses.
   
   o  The newsgroup name matching capabilities already documented in
      RFC 977 ("wildmats" (Section 4)) are clarified and extended.  The
      new facilities (e.g. the use of commas and exclamation marks) are
      allowed wherever wildmats appear in the protocol.
   
   o  Support for pipelining of commands (Section 3.5) is made
      mandatory.
   
   o  The principles behind response codes (Section 3.2) have been
      tidied up.  In particular:
      *  the x8x response code family, formerly used for private
         extensions, is now reserved for authentication and privacy
         extensions;
      *  the x9x response code family, formerly intended for debugging
         facilities, are now reserved for private extensions;
      *  the 502 and 503 generic response codes (Section 3.2.1) have  
         been redefined;
      *  new 401, 403, 480, 483, and 504 generic response codes have
         been added.
   
   o  The rules for article numbering (Section 6) have been clarified.
   
   o  The SLAVE command (which was ill-defined) is removed from the 
      protocol.
      
   o  Four-digit years are permitted in the NEWNEWS (Section 7.4) and
      NEWGROUPS (Section 7.3) commands (two-digit years are still
      permitted).  The optional distribution parameter to these commands
      has been removed.
   
   o  The argument to GROUP (Section 6.1.1) is optional.
      
   o  The LIST (Section 7.6.1) command is greatly extended; the original
      is available as LIST ACTIVE, while new variants include
      ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS.  A new "m" status flag
      is added to the LIST ACTIVE response.
   
   o  A new CAPABILITIES (Section 5.2) command allows clients to
      determine what facilities are supported by a server.
         
   o  The DATE (Section 7.1) command is adopted from RFC 2980
      effectively unchanged.
   
   o  The LISTGROUP (Section 6.1.2) command is adopted from RFC 2980.
      An optional range argument has been added, and the 211 initial
      response line now has the same format as the 211 response from the
      GROUP command.
      
   o  The MODE READER (Section 5.3) command is adopted from RFC 2980 and
      its meaning and effects clarified.
   
   o  The XHDR command in RFC 2980 has been formalised as the new HDR
      (Section 8.5) and LIST HEADERS (Section 8.6) commands.
   
   o  The XOVER command in RFC 2980 has been formalised as the new OVER
      (Section 8.3) and LIST OVERVIEW.FMT (Section 8.4) commands.  The  
      former can be applied to a message-id as well as to a range.
   
   o  The concept of article metadata (Section 8.1) has been formalised,
      allowing the Bytes and Lines pseudo-headers to be deprecated.
         
   Client authors should note in particular that lack of support for the
   CAPABILITIES command is a good indication that the server does not
   support this specification.

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



More information about the ietf-nntp mailing list