[NNTP] Header terminology
Clive D.W. Feather
clive at demon.net
Tue Jun 28 01:35:06 PDT 2005
Russ Allbery said:
> > 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.
>
> 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.
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".
--
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 | |
--- 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: <45223423 at example.com>
[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 <45223423 at example.com>
@@ -2297,13 +2299,13 @@
[S] Message-ID: <45223423 at example.com>
[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 <i.am.not.there at example.com>
[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 <i.am.an.article.you.will.want at example.com>
@@ -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 @@
<45223423 at to.to>|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 <i.am.a.test.article at example.com>
- [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 <i.am.not.there at example.com>
[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 <45223423 at example.com>
@@ -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
More information about the ietf-nntp
mailing list