Subject: [NNTP] Header terminology

From: Russ Allbery <[email-masked]>
Date: Sun, 12 Jun 2005 11:27:24 -0700

Forwarding from USEFOR.  What do folks think about making the editorial
changes noted below for compatibility with mail terminology?  See the end
of Richard's message for the exact details; other than in the base
document (which might not be worth the hassle), the changes are trivial
and I don't think they reduce the readability any.

It sticks in my mind that we may have raised this before, but I don't
remember for sure so I'm asking again just in case.

Date: Sun, 12 Jun 2005 12:52:34 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1031 backward compatibility and handling incompatibilities
X-Mailer: Turnpike Integrated Version 5.02 M <Hm3$+Pcr77fJAOKLReX+dOUPoc>

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>I think he is upset because we use the term "header" rather than "header
>field" and "header name" rather than "field name".
>
>I would point out that our drafts have always used this terminology (and
>have carefully documented that usage).

Although I have sympathy for the view that this is continuing the
tradition of how "news" documentation is written, I think that's a
mistake :(

Considerable leverage is gained by defining "news" as a special case of
"mail" (albeit, I sometimes wonder if -- when the minutiae is debated at
such length -- the gain is entirely worth the pain).

Whilst we continue down that path then it behoves us to use the jargon
from "mail" in a consistent and user-friendly manner.

Although there may be mileage in saying "In this standard we use frooble
to mean 'some very long phrase that is hard to keep repeating'" I don't
think that it does anything other than create confusion to use a
substitute for quite short phrases AND what's more, to use a word
"header" that so closely resembles what is being substituted.

As a data point, I'm currently in the process of finally editing my PhD
thesis (yes, they let you do PhDs even at my advanced age!) and realised
that I'd been very sloppy with my own use of the word "header". It took
less than an hour to work through the document and fix every mention to
the correct 2822 jargon.  I really do not think that it reads any worse
now that I've done it, nor is it harder to understand for a neophyte.

>RFC 1036 used the term "header" (though not consistently, since it
>sometimes used "header line" - a quick look revealed no occurrence of
>"field", though I have not grepped to confirm it).
>
>Son-of-1036 used the term "header".
>
>The NNTP draft, which has just completed its IETF Last Call period, uses the
>term "header".

of these three points, this is the _only_ one that would concern me (we
are, I trust, hoping to reach a situation where only historians consult
the other two documents, so who cares what they say?) ... so I checked
the documents recently exiting last call, which appear to be:

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-authinfo-09.txt

        which contains the single phrase "This may be accomplished, for
        example, by inserting headers in the posted articles ..."

        ie: trivial change to "header fields"

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-06.txt

        which doesn't contain "header" at all

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-streaming-05.txt

        this uses "headers" twice, both of which can easily be changed
        to "header fields"

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-base-27.txt

        this uses "header" extensively in 3.6 (relating to folding) and
        would require a moderate amount of work :-(  though in my view
        that work is mechanical and should not give rise to debate.

>I move that we make no change to this long established practice.

You can argue that both alternatives are "long established".

The question is what is best going forward. And there the choice appears
to be between creating significant consistency in the set of documents
that future implementors consult; and in doing some mechanical editing
to documents that are not yet set in stone (albeit some are already a
long way towards that state).

If we are still allowed to disrupt the smooth progress of the NNTP
documents then, in my view, that is what we should do.

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 13 Jun 2005 09:37:58 +0100

> and I don't think they reduce the readability any.

Richard is a colleague of mine when not off doing his Ph.D., so if I
*don't* change the base document, he will nag me to death next time he's at
the desk next to mine :-)

It's a pity that this happened just after the post-Last Call draft went
off.

When I get a moment, I'll look to see what the changes would be like.

-- 
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: Russ Allbery <[email-masked]>
Date: Mon, 13 Jun 2005 01:49:31 -0700

>> changes noted below for compatibility with mail terminology?  See the
>> end of Richard's message for the exact details; other than in the base

> When I get a moment, I'll look to see what the changes would be like.

We may be able to take care of it with a note to the RFC editor, depending
on how simple and mechanical the changes are.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Jun 2005 09:44:23 GMT

>and I don't think they reduce the readability any.

I think we should leave it be. The terminology we use is what is used in
the Real World out there (even for email in fact), quite apart from its
previous use in other Netnews related documents.

-- 
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: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 13 Jun 2005 08:08:47 -0400

> -----Original Message-----
> From: Russ Allbery [mailto:[email-masked]] 
> Sent: Monday, June 13, 2005 4:50 AM
> To: [email-masked]
> Subject: Re: [NNTP] Header terminology
> 

There may also be IESG evaluation comments that require an update.

I can add a note to the RFC Editor if that's the path the group wishes to
take.  I'll need that text before the 23rd.

-Scott-

---

From: Ken Murchison <[email-masked]>
Date: Mon, 13 Jun 2005 10:14:49 -0400

> and I don't think they reduce the readability any.

The change seems reasonable to me.  I never really liked the overloading 
of the term "header".  In one case it means a single "header field", and 
in the other it means the entire message "header" (as opposed to the 
"body").

-- 
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, 13 Jun 2005 08:56:15 -0700

> in the other it means the entire message "header" (as opposed to the

Yeah, that's exactly why the mail terminology is the way that it is, as I
recall.  I'm generally in favor of the change as long as it's not too
disruptive; it's just the sort of thing that's worth cleaning up while
we're in here and rewriting things and making NNTP play better with the
other children.

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Mon, 13 Jun 2005 21:45:56 +0200

Ken Murchison:

> I never really liked the
> overloading of the term "header".  In one case it means a single
> "header field", and in the other it means the entire message "header"
> (as opposed to the "body").

A nice alternative for 'message header' is 'message head'. 
The empty line between 'head' and 'body' is the 'neck'. 

May I propose a new command 'neck', for specifically demanding 
that empty line from the article? No CFWS in there, please.
;)

-- 
Grtz, Ruud

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 28 Jun 2005 09:35:06 +0100

> on how simple and mechanical the changes are.

I finally got round to doing this; it was rather longer than I expected.
Full diffs can be found following my signature.

Russ, this feels rather big to be "editorial".

--- news/nntp/draft27.unpg	Thu Jun  9 07:29:00 2005
+++ news/nntp/draft28.unpg	Tue Jun 28 08:01:43 2005
@@ -3,13 +3,13 @@
 
 NNTP                                                          C. Feather
 Internet-Draft                                                  Thus plc
-Updates: 2980 (if approved)                                 June 8, 2005
+Updates: 2980 (if approved)                                June 27, 2005
 Obsoletes: 977 (if approved)
-Expires: December 10, 2005
+Expires: December 29, 2005

                      Network News Transfer Protocol
-                       draft-ietf-nntpext-base-27
+                       draft-ietf-nntpext-base-28
 
 Status of this Memo
 
@@ -34,7 +34,7 @@
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on December 10, 2005.
+   This Internet-Draft will expire on December 29, 2005.
 
 Copyright Notice
 
@@ -54,6 +54,8 @@
    This document is a product of the NNTP Working Group, chaired by Russ
    Allbery and Ned Freed.
 
+   This is draft 28 pre-publication version 1.
+
 Author's Note
 
    This document is written in XML using an NNTP-specific DTD.  Custom
@@ -179,7 +181,7 @@
      14.1. Normative References
      14.2. Informative References
    A.  Interaction with other specifications
-     A.1.  Header folding
+     A.1.  Header field folding
      A.2.  Message-IDs
      A.3.  Article posting
    B.  Summary of Commands
@@ -746,7 +748,7 @@
 
    HDR
       This capability indicates that the server implements the header
-      access commands (HDR and LIST HEADERS).
+      field access commands (HDR and LIST HEADERS).
 
    OVER
       This capability indicates that the server implements the overview
@@ -870,7 +872,7 @@
    +--------------------+-------------------------+--------------------+
    | AUTHINFO           | Authentication          | [NNTP-AUTH]        |
    |                    |                         |                    |
-   | HDR                | Batched header          | Section 3.3.2,     |
+   | HDR                | Batched header field    | Section 3.3.2,     |
    |                    | retrieval               | Section 8.5, and   |
    |                    |                         | Section 8.6        |
    |                    |                         |                    |
@@ -1097,7 +1099,7 @@
    Also see Appendix A for further restrictions on the format of
    articles in some uses of NNTP.
 
-   An article consists of two parts: the headers and the body.  They are
+   An article consists of two parts: the header and the body.  They are
    separated by a single empty line, or in other words by two
    consecutive CRLF pairs (if there is more than one empty line, the
    second and subsequent ones are part of the body).  In order to meet
@@ -1107,35 +1109,35 @@
    puts no further restrictions on the body; in particular, it MAY be
    empty.
 
-   The headers of an article consist of one or more header lines.  Each
-   header line consists of a header name, a colon, a space, the header
-   content, and a CRLF in that order.  The name consists of one or more
-   printable US-ASCII characters other than colon and, for the purposes
-   of this specification, is not case-sensitive.  There MAY be more than
-   one header line with the same name.  The content MUST NOT contain
-   CRLF; it MAY be empty.  A header may be "folded"; that is, a CRLF
-   pair may be placed before any TAB or space in the line; there MUST
-   still be some other octet between any two CRLF pairs in a header
-   line.  (Note that folding means that the header line occupies more
-   than one line when displayed or transmitted; nevertheless it is still
-   referred to as "a" header line.)  The presence or absence of folding
-   does not affect the meaning of the header line; that is, the CRLF
-   pairs introduced by folding are not considered part of the header
-   content.  Header lines SHOULD NOT be folded before the space after
-   the colon that follows the header name, and SHOULD include at least
-   one octet other than %x09 or %x20 between CRLF pairs.  However, if an
-   article has been received from elsewhere with one of these, clients
-   and servers MAY transfer it to the other without re-folding it.
+   The header of an article consists of one or more header fields.  Each
+   header field is a line composed of a field name, a colon, a space,
+   the field body, and a CRLF in that order.  The field name consists of
+   one or more printable US-ASCII characters other than colon and, for
+   the purposes of this specification, is not case-sensitive.  There MAY
+   be more than one header field with the same name.  The field body
+   MUST NOT contain CRLF; it MAY be empty.  A header field body may be
+   "folded"; that is, a CRLF pair may be placed before any TAB or space
+   in the line; there MUST still be some other octet between any two
+   CRLF pairs in a header field.  (Note that folding means that the
+   header field occupies more than one line when displayed or
+   transmitted.)  The presence or absence of folding does not affect the
+   meaning of the header field; that is, the CRLF pairs introduced by
+   folding are not considered part of the header field body.  Header
+   fields SHOULD NOT be folded before the space after the colon that
+   follows the field name, and SHOULD include at least one octet other
+   than %x09 or %x20 between CRLF pairs.  However, if an article has
+   been received from elsewhere with one of these, clients and servers
+   MAY transfer it to the other without re-folding it.
 
-   The content of a header SHOULD be in UTF-8.  However, if an
+   A header field body SHOULD be in UTF-8.  However, if an
    implementation receives an article from elsewhere that uses octets in
    the range 128 to 255 in some other manner, it MAY pass it to a client
    or server without modification.  Therefore implementations MUST be
-   prepared to receive such headers and also data derived from them
-   (e.g. in the responses from the OVER (Section 8.3) command) and MUST
-   NOT assume that they are always UTF-8.  Any external processing of
-   those headers, including identifying the encoding used, is outside
-   the scope of this document.
+   prepared to receive such header fields and also data derived from
+   them (e.g. in the responses from the OVER (Section 8.3) command) and
+   MUST NOT assume that they are always UTF-8.  Any external processing
+   of those header fields, including identifying the encoding used, is
+   outside the scope of this document.
 
    Each article MUST have a unique message-id; two articles offered by
    an NNTP server MUST NOT have the same message-id.  For the purposes
@@ -2055,8 +2057,8 @@
    client and in the successful response code.  The ARTICLE command is
    described here in full, while the other commands are described in
    terms of the differences.  As specified in Section 3.6, an article
-   consists of two parts: the article headers and the article body.
-   When responding to one of these commands, the server MUST present the
+   consists of two parts: the article header and the article body.  When
+   responding to one of these commands, the server MUST present the
    entire article or appropriate part and MUST NOT attempt to alter or
    translate it in any way.
 
@@ -2100,7 +2102,7 @@
 6.2.1.2.  Description
 
    The ARTICLE command selects an article based on the arguments and
-   presents the entire article (that is, the headers, an empty line, and
+   presents the entire article (that is, the header, an empty line, and
    the body in that order).  The command has three forms.
 
    In the first form, a message-id is specified and the server presents
@@ -2237,18 +2239,18 @@
 
    First form (message-id specified)
 
-     221 0|n message-id    Headers follow (multi-line)
+     221 0|n message-id    Header follows (multi-line)
      430                   No article with that message-id
 
    Second form (article number specified)
 
-     221 n message-id      Headers follow (multi-line)
+     221 n message-id      Header follows (multi-line)
      412                   No newsgroup selected
      423                   No article with that number
 
    Third form (current article number used)
 
-     221 n message-id      Headers follow (multi-line)
+     221 n message-id      Header follows (multi-line)
      412                   No newsgroup selected
      420                   Current article number is invalid
 
@@ -2262,12 +2264,12 @@
 
    The HEAD command behaves identically to the ARTICLE command except
    that, if the article exists, the response code is 221 instead of 220
-   and only the headers are presented (the empty line separating the
-   headers and body MUST NOT be included).
+   and only the header is presented (the empty line separating the
+   header and body MUST NOT be included).
 
 6.2.2.3.  Examples
 
-   Example of a successful retrieval of the headers of an article (using
+   Example of a successful retrieval of the header of an article (using
    no article number):
 
       [C] GROUP misc.test
@@ -2283,7 +2285,7 @@
       [S] Message-ID: <[email-masked]>
       [S] .
 
-   Example of a successful retrieval of the headers of an article by
+   Example of a successful retrieval of the header of an article by
    message-id:
 
       [C] HEAD <[email-masked]>
@@ -2297,13 +2299,13 @@
       [S] Message-ID: <[email-masked]>
       [S] .
 
-   Example of an unsuccessful retrieval of the headers of an article by
+   Example of an unsuccessful retrieval of the header of an article by
    message-id:
 
       [C] HEAD <[email-masked]>
       [S] 430 No Such Article Found
 
-   Example of an unsuccessful retrieval of the headers of an article by
+   Example of an unsuccessful retrieval of the header of an article by
    number:
 
       [C] GROUP misc.test
@@ -2311,14 +2313,14 @@
       [C] HEAD 300256
       [S] 423 No article with that number
 
-   Example of an unsuccessful retrieval of the headers of an article by
+   Example of an unsuccessful retrieval of the header of an article by
    number because no newsgroup was selected first:
 
       [Assumes currently selected newsgroup is invalid.]
       [C] HEAD 300256
       [S] 412 No newsgroup selected
 
-   Example of an attempt to retrieve the headers of an article when the
+   Example of an attempt to retrieve the header of an article when the
    currently selected newsgroup is empty:
 
       [C] GROUP example.empty.newsgroup
@@ -2367,7 +2369,7 @@
 
    The BODY command behaves identically to the ARTICLE command except
    that, if the article exists, the response code is 222 instead of 220
-   and only the body is presented (the empty line separating the headers
+   and only the body is presented (the empty line separating the header
    and body MUST NOT be included).
 
 6.2.3.3.  Examples
@@ -2688,14 +2690,14 @@
    response MUST be returned.
 
    If transmission of the article is requested, the client MUST send the
-   entire article, including headers and body, to the server as a multi-
-   line data block (see Section 3.1.1).  Thus a single dot (".") on a
-   line indicates the end of the text, and lines starting with a dot in
-   the original text have that dot doubled during transmission.  The
-   server MUST return either a 235 response, indicating that the article
-   was successfully transferred, a 436 response, indicating that the
-   transfer failed but should be tried again later, or a 437 response,
-   indicating that the article was rejected.
+   entire article, including both header and body, to the server as a
+   multi-line data block (see Section 3.1.1).  Thus a single dot (".")
+   on a line indicates the end of the text, and lines starting with a
+   dot in the original text have that dot doubled during transmission.
+   The server MUST return either a 235 response, indicating that the
+   article was successfully transferred, a 436 response, indicating that
+   the transfer failed but should be tried again later, or a 437
+   response, indicating that the article was rejected.
 
    This function differs from the POST command in that it is intended
    for use in transferring already-posted articles between hosts.  It
@@ -2707,9 +2709,9 @@
    article, it deems it inappropriate to do so.  Reasons for such
    subsequent rejection of an article may include such problems as
    inappropriate newsgroups or distributions, disc space limitations,
-   article lengths, garbled headers, and the like.  These are typically
-   restrictions enforced by the server host's news software and not
-   necessarily the NNTP server itself.
+   article lengths, garbled header fields, and the like.  These are
+   typically restrictions enforced by the server host's news software
+   and not necessarily the NNTP server itself.
 
    The client SHOULD NOT assume that the article has been successfully
    transferred unless it receives an affirmative response from the
@@ -2741,7 +2743,7 @@
 
    Example of sending an article to another site that rejects it.  Note
    that the message-id in the IHAVE command is not the same as the one
-   in the article headers; while this is bad practice and SHOULD NOT be
+   in the article header; while this is bad practice and SHOULD NOT be
    done, it is not forbidden.
 
       [C] IHAVE <[email-masked]>
@@ -3319,12 +3321,12 @@
    This keyword is optional.
 
    The distrib.pats list is maintained by some NNTP servers to assist
-   clients to choose a value for the content of the Distribution header
-   of a news article being posted.  Each line of this list consists of
-   three fields separated from each other by a colon (":").  The first
-   field is a weight, the second field is a wildmat (which may be a
-   simple newsgroup name), and the third field is a value for the
-   Distribution header content.  For example:
+   clients to choose a value for the body of the Distribution header
+   field of a news article being posted.  Each line of this list
+   consists of three fields separated from each other by a colon (":").
+   The first field is a weight, the second field is a wildmat (which may
+   be a simple newsgroup name), and the third field is a value for the
+   Distribution header field body.  For example:
 
       [C] LIST DISTRIB.PATS
       [S] 215 information follows
@@ -3334,11 +3336,11 @@
       [S] .
 
    The client MAY use this information to construct an appropriate
-   Distribution header given the name of a newsgroup.  To do so, it
-   should determine the lines whose second field matches the newsgroup
-   name, select from among them the line with the highest weight (with 0
-   being the lowest), and use the value of the third field to construct
-   the Distribution header.
+   Distribution header field given the name of a newsgroup.  To do so,
+   it should determine the lines whose second field matches the
+   newsgroup name, select from among them the line with the highest
+   weight (with 0 being the lowest), and use the value of the third
+   field to construct the Distribution header field.
 
    The information is not newsgroup-based and an argument MUST NOT be
    specified.
@@ -3383,11 +3385,11 @@
 8.  Article field access commands
 
    This section lists commands that may be used to access specific
-   article fields; that is, headers of articles and metadata about
+   article fields; that is, header fields of articles and metadata about
    articles.  These commands typically fetch data from an "overview
-   database", which is a database of headers extracted from incoming
-   articles plus metadata determined as the article arrives.  Only
-   certain fields are included in the database.
+   database", which is a database of header fields extracted from
+   incoming articles plus metadata determined as the article arrives.
+   Only certain fields are included in the database.
 
    This section is based on the Overview/NOV database [ROBE1995]
    developed by Geoff Collyer.
@@ -3397,13 +3399,13 @@
    Article "metadata" is data about articles that does not occur within
    the article itself.  Each metadata item has a name which MUST begin
    with a colon (and which MUST NOT contain a colon elsewhere within
-   it).  As with header names, metadata item names are not case-
+   it).  As with header field names, metadata item names are not case-
    sensitive.
 
    When generating a metadata item, the server MUST compute it for
    itself and MUST NOT trust any related value provided in the article.
-   (In particular, a Lines or Bytes header in the article MUST NOT be
-   assumed to specify the correct number of lines or bytes in the
+   (In particular, a Lines or Bytes header field in the article MUST NOT
+   be assumed to specify the correct number of lines or bytes in the
    article.)  If the server has access to several non-identical copies
    of an article, the value returned MUST be correct for any copy of
    that article retrieved during the same session.
@@ -3418,7 +3420,7 @@
 8.1.1.  The :bytes metadata item
 
    The :bytes metadata item for an article is a decimal integer.  It
-   SHOULD equal the number of octets in the entire article - headers,
+   SHOULD equal the number of octets in the entire article - header,
    body, and separating empty line (counting a CRLF pair as two octets,
    and excluding both the "." CRLF terminating the response and any "."
    added for "dot-stuffing" purposes).
@@ -3437,7 +3439,7 @@
 
    The :lines metadata item for an article is a decimal integer.  It
    MUST equal the number of lines in the article body (excluding the
-   empty line separating headers and body); equivalently, it is two less
+   empty line separating header and body); equivalently, it is two less
    than the number of CRLF pairs that the BODY command would return for
    that article (the extra two are those following the response code and
    the termination octet).
@@ -3446,20 +3448,20 @@
 
    The information stored in the overview database may change over time.
    If the database records the content or absence of a given field (that
-   is, a header or metadata item) for all articles, it is said to be
-   "consistent" for that field.  If it records the content of a header
-   for some articles but not for others that nevertheless included that
-   header, or records a metadata item for some articles but not others
-   to which that item applies, it is said to be "inconsistent" for that
-   field.
+   is, a header field or metadata item) for all articles, it is said to
+   be "consistent" for that field.  If it records the content of a
+   header field for some articles but not for others that nevertheless
+   included that header, or records a metadata item for some articles
+   but not others to which that item applies, it is said to be
+   "inconsistent" for that field.
 
    The LIST OVERVIEW.FMT command SHOULD list all the fields for which
    the database is consistent at that moment.  It MAY omit such fields
    (for example if it is not known whether the database is consistent or
    inconsistent).  It MUST NOT include fields for which the database is
    inconsistent or which are not stored in the database.  Therefore if a
-   header appears in the LIST OVERVIEW.FMT output but not the OVER
-   output for a given article, that header does not appear in the
+   header field appears in the LIST OVERVIEW.FMT output but not the OVER
+   output for a given article, that header field does not appear in the
    article, and similarly for metadata items.
 
    These rules assume the fields being stored in the database remain
@@ -3546,11 +3548,11 @@
    The first 8 fields MUST be the following, in order:
 
       "0" or article number (see below)
-      Subject header content
-      From header content
-      Date header content
-      Message-ID header content
-      References header content
+      Subject header field body
+      From header field body
+      Date header field body
+      Message-ID header field body
+      References header field body
       :bytes metadata item
       :lines metadata item
 
@@ -3562,36 +3564,38 @@
    for more details).  In the other two forms of the command, the
    article number MUST be returned.
 
-   Any subsequent fields are the contents of the other headers and
+   Any subsequent fields are the contents of the other header fields and
    metadata held in the database.
 
-   For the five mandatory headers, the content of each field MUST be
-   based on the content of the header (that is, with the header name and
-   following colon and space removed).  If the article does not contain
-   that header, or if the content is empty, the field MUST be empty.
-   For the two mandatory metadata items, the content of the field MUST
-   be just the value, with no other text.
-
-   For all subsequent fields that contain headers, the content MUST be
-   the entire header line other than the trailing CRLF.  For all
-   subsequent fields that contain metadata, the field consists of the
-   metadata name, a single space, and then the value.
+   For the five mandatory header fields, the content of each field in
+   the response MUST be based on the body of the header field (that is,
+   with the header field name and following colon and space removed).
+   If the article does not contain that header field, or if the body is
+   empty, the field MUST be empty.  For the two mandatory metadata
+   items, the content of the field in the response MUST be just the
+   value, with no other text.
+
+   For all subsequent fields in the response that contain header fields,
+   the content MUST be the entire header field other than the trailing
+   CRLF.  For all subsequent fields that contain metadata, the field
+   consists of the metadata name, a single space, and then the value.
 
    For all fields, the value is processed by first removing all CRLF
    pairs (that is, undoing any folding and removing the terminating
    CRLF) and then replacing each TAB with a single space.  If there is
-   no such header in the article, or no such metadata item, or no header
-   or item stored in the database for that article, the corresponding
-   field MUST be empty.
+   no such header field in the article, or no such metadata item, or no
+   header field or item stored in the database for that article, the
+   corresponding field MUST be empty.
 
    Note that, after unfolding, the characters NUL, LF, and CR cannot
-   occur in the header of an article offered by a conformant server.
-   Nevertheless, servers SHOULD check for these characters and replace
-   each one by a single space (so that, for example, CR LF LF TAB will
-   become two spaces, since the CR and first LF will be removed by the
-   unfolding process).  This will encourage robustness in the face of
-   non-conforming data; it is also possible that future versions of this
-   specification could permit these characters to appear in articles.
+   occur in the header field of an article offered by a conformant
+   server.  Nevertheless, servers SHOULD check for these characters and
+   replace each one by a single space (so that, for example, CR LF LF
+   TAB will become two spaces, since the CR and first LF will be removed
+   by the unfolding process).  This will encourage robustness in the
+   face of non-conforming data; it is also possible that future versions
+   of this specification could permit these characters to appear in
+   articles.
 
    The server SHOULD NOT produce output for articles that no longer
    exist.
@@ -3675,9 +3679,9 @@
       <[email-masked]>|9234|51
       [S] .
 
-   Note the missing "References" and Xref headers in the second line,
-   the missing trailing field(s) in the first and last lines, and that
-   there are only results for those articles that still exist.
+   Note the missing "References" and Xref header fields in the second
+   line, the missing trailing field(s) in the first and last lines, and
+   that there are only results for those articles that still exist.
 
    Example of an unsuccessful retrieval of overview information on an
    article by number:
@@ -3748,17 +3752,17 @@
        Bytes:
        Lines:
 
-   even though they refer to metadata, not headers.
+   even though they refer to metadata, not header fields.
 
-   All subsequent lines MUST consist of either a header name followed by
-   ":full", or the name of a piece of metadata.
+   All subsequent lines MUST consist of either a header field name
+   followed by ":full", or the name of a piece of metadata.
 
    There are no leading or trailing spaces in the output.
 
    Note that the 7 fixed lines describe the 2nd to 8th fields of the
    OVER output.  The "full" suffix (which may use either uppercase,
    lowercase, or a mix) is a reminder that the corresponding fields
-   include the header name.
+   include the header field name.
 
    This command MAY generate different results if used more than once in
    a session.
@@ -3817,18 +3821,18 @@
 
    First form (message-id specified)
 
-     225    Headers follow (multi-line)
+     225    Header fields follow (multi-line)
      430    No article with that message-id
 
    Second form (range specified)
 
-     225    Headers follow (multi-line)
+     225    Header fields follow (multi-line)
      412    No newsgroup selected
      423    No articles in that range
 
    Third form (current article number used)
 
-     225    Headers follow (multi-line)
+     225    Header fields follow (multi-line)
      412    No newsgroup selected
      420    Current article number is invalid
 
@@ -3844,14 +3848,15 @@
    specified by message-id, or from a specified article or range of
    articles in the currently selected newsgroup.  It MAY take the
    information directly from the articles or from the overview database.
-   In the case of headers, an implementation MAY restrict the use of
-   this command to a specific list of headers or MAY allow it to be used
-   with any header; it may behave differently when it is used with a
-   message-id argument and when it is used with a range or no argument.
-
-   The required field argument is the name of a header with the colon
-   omitted (e.g. "subject"), or the name of a metadata item including
-   the leading colon (e.g. ":bytes"), and is case-insensitive.
+   In the case of header fields, an implementation MAY restrict the use
+   of this command to a specific list of header fields or MAY allow it
+   to be used with any header field; it may behave differently when it
+   is used with a message-id argument and when it is used with a range
+   or no argument.
+
+   The required field argument is the name of a header field with the
+   colon omitted (e.g. "subject"), or the name of a metadata item
+   including the leading colon (e.g. ":bytes"), and is case-insensitive.
 
    The message-id argument indicates a specific article.  The range
    argument may be any of the following:
@@ -3866,8 +3871,8 @@
    article in the range that exists (note that unless the argument is a
    range including a dash, there will be exactly one line in the data
    block).  The line consists of the article number, a space, and then
-   the contents of the field.  In the case of a header, the header name,
-   colon, and the first space after the colon are all omitted.
+   the contents of the field.  In the case of a header field, the field
+   name, colon, and the first space after the colon are all omitted.
 
    If the article is specified by message-id (the first form of the
    command), the article number MUST be replaced with zero, except that
@@ -3877,29 +3882,29 @@
    for more details).  In the other two forms of the command, the
    article number MUST be returned.
 
-   Header contents are modified as follows: all CRLF pairs are removed,
-   and then each TAB is replaced with a single space (note that this is
-   the same transformation as is performed by the OVER command
+   Header field bodies are modified as follows: all CRLF pairs are
+   removed, and then each TAB is replaced with a single space (note that
+   this is the same transformation as is performed by the OVER command
    (Section 8.3.2), and the same comment concerning NUL, CR, and LF
    applies).
 
-   Note the distinction between headers and metadata appearing to have
-   the same meaning.  Headers are always taken unchanged from the
-   article; metadata are always calculated.  For example, a request for
-   "Lines" returns the contents of the "Lines" header of the specified
-   articles, if any, no matter whether or not they accurately state the
-   number of lines, while a request for ":lines" returns the line count
-   metadata, which is always the actual number of lines irrespective of
-   what any header may state.
-
-   If the requested header is not present in the article or if it is
-   present but empty, a line for that article is included in the output
-   but the header content portion of the line is empty (the space after
-   the article number MAY be retained or omitted).  If the header occurs
-   in a given article more than once, only the content of the first
-   occurrence is returned by HDR.  If any article number in the provided
-   range does not exist in the group, no line for that article number is
-   included in the output.
+   Note the distinction between header fields and metadata appearing to
+   have the same meaning.  Header fields are always taken unchanged from
+   the article; metadata are always calculated.  For example, a request
+   for "Lines" returns the contents of the "Lines" header field of the
+   specified articles, if any, no matter whether or not they accurately
+   state the number of lines, while a request for ":lines" returns the
+   line count metadata, which is always the actual number of lines
+   irrespective of what any header field may state.
+
+   If the requested header field is not present in the article or if it
+   is present but empty, a line for that article is included in the
+   output but the header field body portion of the line is empty (the
+   space after the article number MAY be retained or omitted).  If the
+   header field occurs in a given article more than once, only the body
+   of the first occurrence is returned by HDR.  If any article number in
+   the provided range does not exist in the group, no line for that
+   article number is included in the output.
 
    If the second argument is a message-id and no such article exists, a
    430 response MUST be returned.  If the second argument is a range or
@@ -3925,12 +3930,13 @@
 8.5.3.  Examples
 
    Example of a successful retrieval of subject lines from a range of
-   articles (3000235 has no Subject header, and 3000236 is missing):
+   articles (3000235 has no Subject header field, and 3000236 is
+   missing):
 
       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 misc.test
       [C] HDR Subject 3000234-300238
-      [S] 225 Headers follow
+      [S] 225 Header fields follow
       [S] 3000234 I am just a test article
       [S] 3000235
       [S] 3000237 Re: I am just a test article
@@ -3943,7 +3949,7 @@
       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 misc.test
       [C] HDR :lines 3000234-300238
-      [S] 225 Headers follow
+      [S] 225 Header fields follow
       [S] 3000234 42
       [S] 3000235 5
       [S] 3000237 11
@@ -3956,7 +3962,7 @@
       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 misc.test
       [C] HDR subject <[email-masked]>
-      [S] 225 Header information follows
+      [S] 225 Header field information follows
       [S] 0 I am just a test article
       [S] .
 
@@ -3966,33 +3972,33 @@
       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 misc.test
       [C] HDR subject
-      [S] 225 Header information follows
+      [S] 225 Header field information follows
       [S] 3000234 I am just a test article
       [S] .
 
-   Example of an unsuccessful retrieval of a header from an article by
-   message-id:
+   Example of an unsuccessful retrieval of a header field from an
+   article by message-id:
 
       [C] HDR subject <[email-masked]>
       [S] 430 No Such Article Found
 
-   Example of an unsuccessful retrieval of headers from articles by
-   number because no newsgroup was selected first:
+   Example of an unsuccessful retrieval of header fields from articles
+   by number because no newsgroup was selected first:
 
       [Assumes currently selected newsgroup is invalid.]
       [C] HDR subject 300256-
       [S] 412 No newsgroup selected
 
-   Example of an unsuccessful retrieval of headers because the currently
-   selected newsgroup is empty:
+   Example of an unsuccessful retrieval of header fields because the
+   currently selected newsgroup is empty:
 
       [C] GROUP example.empty.newsgroup
       [S] 211 0 0 0 example.empty.newsgroup
       [C] HDR subject 1-
       [S] 423 No articles in that range
 
-   Example of an unsuccessful retrieval of headers because the server
-   does not allow HDR commands for that header:
+   Example of an unsuccessful retrieval of header fields because the
+   server does not allow HDR commands for that header field:
 
       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 misc.test
@@ -4027,24 +4033,24 @@
 
    The information is returned as a multi-line data block following the
    215 response code and contains one line for each field name
-   (excluding the trailing colon for headers and including the leading
-   colon for metadata items).  If the implementation allows any header
-   to be retrieved, it MUST NOT include any header names in the list but
-   MUST include the special entry ":" (a single colon on its own); it
-   MUST still explicitly list any metadata items that are available.
-   The order of items in the list is not significant; the server need
-   not even consistently return the same order.  The list MAY be empty
-   (though in this circumstance there is little point in providing the
-   HDR command).
+   (excluding the trailing colon for header fields and including the
+   leading colon for metadata items).  If the implementation allows any
+   header field to be retrieved, it MUST NOT include any header field
+   names in the list but MUST include the special entry ":" (a single
+   colon on its own); it MUST still explicitly list any metadata items
+   that are available.  The order of items in the list is not
+   significant; the server need not even consistently return the same
+   order.  The list MAY be empty (though in this circumstance there is
+   little point in providing the HDR command).
 
    An implementation that also supports the OVER command SHOULD at least
-   permit all the headers and metadata items listed in the output from
-   the LIST OVERVIEW.FMT command.
+   permit all the header fields and metadata items listed in the output
+   from the LIST OVERVIEW.FMT command.
 
    If the server treats the first form of the HDR command (message-id
    specified) differently to the other two forms (range specified or
-   current article number used) in respect of which headers or metadata
-   items are available, then:
+   current article number used) in respect of which header fields or
+   metadata items are available, then:
    o  if the MSGID argument is specified, the results MUST be those
       available for the first form of the HDR command;
    o  if the RANGE argument is specified, the results MUST be those
@@ -4062,10 +4068,11 @@
 
 8.6.3.  Examples
 
-   Example of an implementation providing access to only a few headers:
+   Example of an implementation providing access to only a few header
+   fields:
 
       [C] LIST HEADERS
-      [S] 215 headers supported:
+      [S] 215 header fields supported:
       [S] Subject
       [S] Message-ID
       [S] Xref
@@ -4083,7 +4090,7 @@
       [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT
       [S] .
       [C] LIST HEADERS
-      [S] 215 headers and metadata items supported:
+      [S] 215 header fields and metadata items supported:
       [S] Date
       [S] Distribution
       [S] From
@@ -4095,7 +4102,7 @@
       [S] :lines
       [S] .
 
-   Example of an implementation providing access to all headers:
+   Example of an implementation providing access to all header fields:
 
       [C] LIST HEADERS
       [S] 215 metadata items supported:
@@ -4115,7 +4122,7 @@
       [S] :bytes
       [S] .
       [C] LIST HEADERS MSGID
-      [S] 215 headers and metadata items supported:
+      [S] 215 header fields and metadata items supported:
       [S] Date
       [S] Distribution
       [S] From
@@ -4127,7 +4134,7 @@
       [S] :x-article-number
       [S] .
       [C] LIST HEADERS
-      [S] 215 headers and metadata items supported:
+      [S] 215 header fields and metadata items supported:
       [S] Date
       [S] Distribution
       [S] From
@@ -4241,7 +4248,7 @@
      date4y = 4DIGIT 2DIGIT 2DIGIT
      date2y = 2DIGIT 2DIGIT 2DIGIT
      date-time = date WS time [WS "GMT"]
-     header-meta-name = header-name / metadata-name
+     header-meta-name = header-field-name / metadata-name
      list-arguments = keyword [WS token]
      metadata-name = ":" 1*A-NOTCOLON
      range = article-number ["-" [article-number]]
@@ -4337,7 +4344,7 @@
      capabilities-101-ml-content = version-line CRLF
            *(capability-line CRLF)
      hdr-225-ml-content = *(article-number SP hdr-content CRLF)
-     head-221-ml-content = 1*header
+     head-221-ml-content = 1*header-field
      help-100-ml-content = *(*U-CHAR CRLF)
      list-215-ml-content = list-content
      listgroup-211-ml-content = *(article-number CRLF)
@@ -4348,7 +4355,8 @@
      active-groups-list = *(newsgroup-name SPA article-number
            SPA article-number SPA newsgroup-status CRLF)
      hdr-content = *S-NONTAB
-     hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content]
+     hdr-n-content = [(header-field-name ":" / metadata-name)
+           SP hdr-content]
      list-content = body
      newsgroup-status = %x79 / %x6E / %x6D / private-status
      over-content = 1*6(TAB hdr-content) /
@@ -4448,7 +4456,7 @@
            "Message-ID:" CRLF
            "References:" CRLF
            ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF
-           *((header-name ":full" / metadata-name) CRLF)
+           *((header-field-name ":full" / metadata-name) CRLF)

 9.7.  Articles
@@ -4457,9 +4465,10 @@
    format of an article as described in Section 3.6.

-     article = 1*header CRLF body
-     header = header-name ":" [CRLF] SP header-content CRLF
-     header-content = *(S-CHAR / [CRLF] WS)
+     article = 1*header-field CRLF body
+     header-field = header-field-name ":" [CRLF]
+           SP header-field-body CRLF
+     header-field-body = *(S-CHAR / [CRLF] WS)
      body = *(*B-CHAR CRLF)

@@ -4477,7 +4486,7 @@
      termination = "." CRLF
 
      article-number = 1*16DIGIT
-     header-name = 1*A-NOTCOLON
+     header-field-name = 1*A-NOTCOLON
      keyword = ALPHA 2*11(ALPHA / DIGIT / "." / "-")
      message-id = "<" 1*248A-NOTGT ">"
      newsgroup-name = 1*wildmat-exact
@@ -4630,12 +4639,12 @@
    necessarily appropriate elsewhere.  For example, some have adopted a
    default 8-bit character set appropriate to their needs (such as ISO/
    IEC 8859-1 in Western Europe or KOI-8 in Russia), others have used
-   ASCII (either US-ASCII or national variants) in headers but local 16-
-   bit character sets in article bodies, and still others have gone for
-   a combination of MIME [RFC2045] and UTF-8.  With the increased use of
-   MIME in email, it is becoming more common to find NNTP articles
-   containing MIME headers identifying the character set of the body,
-   but this is far from universal.
+   ASCII (either US-ASCII or national variants) in header fields but
+   local 16-bit character sets in article bodies, and still others have
+   gone for a combination of MIME [RFC2045] and UTF-8.  With the
+   increased use of MIME in email, it is becoming more common to find
+   NNTP articles containing MIME header fields identifying the character
+   set of the body, but this is far from universal.
 
    The resulting confusion does not help interoperability.
 
@@ -4665,17 +4674,17 @@
    the use of arbitrary 8-bit data in articles subject to the following
    requirements and recommendations.
 
-   o  The names of headers (e.g.  "From" or "Subject") MUST be in US-
-      ASCII.
+   o  The names of header fields (e.g.  "From" or "Subject") MUST be in
+      US-ASCII.
 
-   o  Header values SHOULD use US-ASCII or an encoding based on it such
-      as RFC 2047 [RFC2047] until such time as another approach has been
-      standardised.  At present, 8-bit encodings (including UTF-8)
+   o  Header field bodies SHOULD use US-ASCII or an encoding based on it
+      such as RFC 2047 [RFC2047] until such time as another approach has
+      been standardised.  At present, 8-bit encodings (including UTF-8)
       SHOULD NOT be used because they are likely to cause
       interoperability problems.
 
    o  The character set of article bodies SHOULD be indicated in the
-      article headers, and this SHOULD be done in accordance with MIME.
+      article header, and this SHOULD be done in accordance with MIME.
 
    o  Where an article is obtained from an external source an
       implementation MAY pass it on, and derive data from it (such as
@@ -4781,12 +4790,12 @@
    information is available in some of those articles.  It is very
    important that designers and implementers provide informative
    warnings to users so personal and/or proprietary information in
-   material that is added automatically to articles (e.g. in headers) is
-   not disclosed inadvertently.  Additionally, effective and easily
-   understood mechanisms to manage the distribution of news articles
-   SHOULD be provided to NNTP Server administrators, so that they are
-   able to report with confidence the likely spread of any particular
-   set of news articles.
+   material that is added automatically to articles (e.g. in header
+   fields) is not disclosed inadvertently.  Additionally, effective and
+   easily understood mechanisms to manage the distribution of news
+   articles SHOULD be provided to NNTP Server administrators, so that
+   they are able to report with confidence the likely spread of any
+   particular set of news articles.
 
 12.2.  Abuse of Server Log Information
 
@@ -5096,19 +5105,19 @@
 14.2  Informative References
 
    [NNTP-AUTH]
-              Vinocur, J., Murchison, K., and C. Newman, "NNTP
-              Authentication", draft-ietf-nntpext-authinfo-06 (work in
-              progress), December 2004.
+              Vinocur, J., Murchison, K., and C. Newman, "NNTP Extension
+              for Authentication", draft-ietf-nntpext-authinfo-09 (work
+              in progress), June 2005.
 
    [NNTP-STREAM]
-              Vinocur, J. and K. Murchison, "NNTP Authentication",
-              draft-ietf-nntpext-streaming-03 (work in progress),
-              December 2004.
+              Vinocur, J. and K. Murchison, "NNTP Extension for
+              Streaming Feeds", draft-ietf-nntpext-streaming-06 (work in
+              progress), June 2005.
 
    [NNTP-TLS]
               Vinocur, J., Murchison, K., and C. Newman, "Using TLS with
-              NNTP", draft-ietf-nntpext-tls-nntp-04 (work in progress),
-              December 2004.
+              NNTP", draft-ietf-nntpext-tls-nntp-07 (work in progress),
+              June 2005.
 
    [RFC1036]  Horton, M. and R. Adams, "Standard for interchange of
               USENET messages", RFC 1036, December 1987.
@@ -5159,26 +5168,27 @@
    this specification and to that other one; this appendix describes
    some relevant issues.
 
-A.1.  Header folding
+A.1.  Header field folding
 
-   NNTP allows a header line to be folded (by inserting a CRLF pair)
+   NNTP allows a header field to be folded (by inserting a CRLF pair)
    before any space or TAB character.
 
    Both email and Netnews articles are required to have at least one
-   octet other than space or TAB on each header line.  Thus folding can
-   only happen at one point in each sequence of consecutive spaces or
-   TABs.  Netnews articles are further required to have the header name,
-   colon, and following space all on the first line; folding may only
-   happen beyond that space.  Finally, some non-conforming software will
-   remove trailing spaces and TABs from a line.  Therefore it might be
-   inadvisable to fold a header after a space or TAB.
+   octet other than space or TAB on each line of the header.  Thus
+   folding can only happen at one point in each sequence of consecutive
+   spaces or TABs.  Netnews articles are further required to have the
+   header field name, colon, and following space all on the first line;
+   folding may only happen beyond that space.  Finally, some non-
+   conforming software will remove trailing spaces and TABs from a line.
+   Therefore it might be inadvisable to fold a header field after a
+   space or TAB.
 
-   For maximum safety, header lines SHOULD conform to the following
+   For maximum safety, header fields SHOULD conform to the following
    syntax rather than that in Section 9.7.

-     header = header-name ":" SP [header-content] CRLF
-     header-content = [WS] token *( [CRLF] WS token )
+     header-field = header-field-name ":" SP [header-field-body] CRLF
+     header-field-body = [WS] token *( [CRLF] WS token )

 A.2.  Message-IDs
@@ -5220,10 +5230,10 @@
    compatible with this one, the server SHOULD use those message-ids.  A
    common approach, and one that SHOULD be used for email and Netnews
    articles, is to extract the message-id from the contents of a header
-   with name "Message-ID".  This may not be as simple as copying the
-   entire header contents; it may be necessary to strip off comments and
-   undo quoting, or to reduce "equivalent" message-ids to a canonical
-   form.
+   field with name "Message-ID".  This may not be as simple as copying
+   the entire header field body; it may be necessary to strip off
+   comments and undo quoting, or to reduce "equivalent" message-ids to a
+   canonical form.
 
    If an article is obtained through the IHAVE command, there will be a
    message-id provided with the command.  The server MAY either use it
@@ -5235,10 +5245,11 @@
    identify, it MUST synthesize one.  This could, for example, be a
    simple sequence number or based on the date and time that the article
    arrived.  When handling email or Netnews articles, a Message-ID
-   header SHOULD be added to ensure global consistency and uniqueness.
+   header field SHOULD be added to ensure global consistency and
+   uniqueness.
 
    Note that, because the message-id might not have been derived from
-   the Message-ID header in the article, the following example is
+   the Message-ID header field in the article, the following example is
    legitimate (though unusual):
 
       [C] HEAD <[email-masked]>
@@ -5282,11 +5293,11 @@
    is allocated to both attempts so that the server, or other servers,
    can recognize the two articles as being duplicates.  In the case of
    email or Netnews articles, therefore, the posted article SHOULD
-   contain a header with name "Message-ID" and the contents of this
-   header SHOULD be identical on each attempt.  The server SHOULD ensure
-   that two POSTed articles with the same contents for this header are
-   recognized as identical and the same message-id allocated, whether or
-   not those contents are suitable for use as the message-id.
+   contain a header field with name "Message-ID" and the body of this
+   header field SHOULD be identical on each attempt.  The server SHOULD
+   ensure that two POSTed articles with the same body for this header
+   field are recognized as identical and the same message-id allocated,
+   whether or not that body is suitable for use as the message-id.

 Appendix B.  Summary of Commands
@@ -5418,7 +5429,7 @@
    Response code 221 (multi-line)
       Generated by: HEAD
       2 arguments: n message-id
-      Meaning: article headers follow.
+      Meaning: article header follows.
 
    Response code 222 (multi-line)
       Generated by: BODY
@@ -5436,7 +5447,7 @@
 
    Response code 225 (multi-line)
       Generated by: HDR
-      Meaning: headers follow.
+      Meaning: header fields follow.
 
    Response code 230 (multi-line)
       Generated by: NEWNEWS
@@ -5640,7 +5651,8 @@
       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.
+      allowing the Bytes and Lines pseudo-header fields 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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 28 Jun 2005 16:07:00 GMT

>Russ, this feels rather big to be "editorial".

Indeed. USEFOR is currently discussing this, and I would suggest waiting
to see what they decide. It looks like we have to wait a few weeks anyway
for the TLS etc drafts to clear, so no time will be lost if Usefor can
make up its mind by then.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 28 Jun 2005 18:47:00 -0400

> Full diffs can be found following my signature.

Just out of curiosity, instead of the two parts of an article being the 
"header" and "body", why not make it "head" and "body", which mirrors 
the two commands for retrieving the parts?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 29 Jun 2005 09:02:42 +0100

> the two commands for retrieving the parts?

Consistency with RFC 2822, which was the point of the exercise.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 29 Jun 2005 14:46:56 -0700

> Russ, this feels rather big to be "editorial".

Yeah, I agree.  Scott, Ned, do you think this is worth looking at at this
point, or should we just say we'll revisit it when we go to draft status?

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 30 Jun 2005 13:11:23 GMT

>Consistency with RFC 2822, which was the point of the exercise.

Though "head" does have the benefit of being different from "header",
which is frequently used to mean "header field". So that might be a useful
change to make in RFC 2822bis (if and when).