From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Tue Nov 25 2003 - 15:23:10 CST
There is a new draft available:
<http://www.landfield.com/usefor/drafts/draft-ietf-usefor-article-12.txt>
<http://www.landfield.com/usefor/drafts/draft-ietf-usefor-article-12.unpaged>
and it is also on its way to the Drafts Editor.
Substantive changes
-------------------
There were a few oustanding issues, already recorded by meta-comments in
the texts, about which no comments had been received, or which were
awaiting decisions from our Chair as to how to resolve them. In the
absence of any ruling from the Chair, and in order to make progress, I
have therefore made some arbitrary choices. If you don't like them, then
speak up, and if the Chair instructs me to change them, then so be it.
1. The title of the document has been changed to
News Article Format and Transmission
(which was the title of Son-of-1036). If we now decide to split the
document in two, then the title will be changed back again.
2. Section 5.5. The maximum recommended length of a newsgroup-name is now
66 characters instead of 71. This is so that a Followup-To-header can
always be written (possibly with folding) in at most 79 characters. USEAGE
has been changed to match.
3. Section 4.5. A suggested default line limit of 79 has been
re-introduced, in a NOTE and with reference to [USEAGE]. This is simply to
justify the existing mention of 79 at a couple of other places in the
document.
4. Section 8.6. If "RE: " is used in a followup (its use is only a MAY -
see USEAGE for stronger wording) then it SHOULD NOT be contained within an
encoded-word (i.e. if you followup to an article with RFC 2047 stuff in
its Subject, then the prepended "Re: " is simply stuck on the front
without any re-encoding). This means that any reading agents which rely on
the presence of "Re: " don't need to worry about such encoding.
I have demoted the MUST NOTs for translating "Re: " into "Sw: " and the
like and for having more than one "Re: " to SHOULD NOTs. The reasons are:
a) it is nearer the middle ground of the options that various WG
members wanted.
b) it is as close as I can get to RFC 2822, whilst sticking with RFC
2119 wording.
c) it is consistent with the use of SHOULD rather than MUST elsewhere
in the duties of followup agents.
I have also demoted a MUST NOT to a SHOULD NOT for mailing to an address
ending in ".invalid", since the worst that happens is wasted DNS lookups -
nothing actually breaks.
Cosmetic changes.
-----------------
1. Now that we have a more complete USEAGE draft, the manner of referring
to it has changed.
2. Sections 2.4.2 (Syntax adapted from Email and MIME) and 2.4.3 (Syntax
copied from other standards) have been interchanged. The reason is that
the (old) 2.4.2 relied on syntax defined in the (old) 2.4.3. Also, some
paragraphs in the (new) 2.4.2 have been shifted around so as to fit the
syntax better.
3. The movement of large chunks of text into USEAGE has left a few
sections in section 4 high and dry, with hardly any remaining content.
Sections 4.2.6 (Undesirable Headers) and 4.3.2 (Body Conventions) have
therefore been abolished and the content (if still relevant) moved to more
fitting places (in particular, all discussion of SP (trailing or not) and
empty content in headers is now in one place in 4.2.3). Section 4.4 has
been renamed "Octets, Characters and Character Sets", and various
redundant texts within it have been removed and/or consolidated.
4. Several sentences that said nothing that was not already obvious have
been removed.
5. There are numerous minor corrections, typos, and consequential changes.
6. The whole document now amounts to 95 pages (it was 96 pages before).
Those who think this is still too long might care to contemplate the fact
that the NNTP draft, which is on the verge of Last Call, currently runs to
107 pages.
Here are the full diffs, for those who want the gory details:
*** landfield/drafts/draft-ietf-usefor-article-11.unpaged Thu Jun 26
19:46:23 2003
--- landfield/drafts/draft-ietf-usefor-article-12.unpaged Mon Nov 24
21:11:53 2003
***************
*** 3,8 ****
Usenet Format Working Group University of Manchester
! June 2003
! News Article Format
! <draft-ietf-usefor-article-11.txt>
--- 3,8 ----
Usenet Format Working Group University of Manchester
! November 2003
! News Article Format and Transmission
! <draft-ietf-usefor-article-12.txt>
***************
*** 53,59 ****
! This present draft is derived from draft-10 by removing many
! requirements which were present for Social rather than Normative reasons
! (and in particular the word "Ought" with its specially defined meaning
! is no longer used). These former requirements will now appear in a
! companion Informational document/*(us.
--- 53,57 ----
! A companion Current Best Practice document [USEAGE], addressing
! requirements which are present for Social rather than Normative reasons
! is in preparation.
***************
*** 76,79 ****
ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
! the time this document is published. Likewise, if may be possible to
! replace references to [RFC 2279] by references to [RFC 2279bis].]
--- 75,77 ----
ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
! the time this document is published.]
***************
*** 93,96 ****
2.4.1. Syntax Notation ....................................... 0
! 2.4.2. Syntax adapted from Email and MIME .................... 0
! 2.4.3. Syntax copied from other standards .................... 0
2.5. Language .................................................. 0
--- 91,94 ----
2.4.1. Syntax Notation ....................................... 0
! 2.4.2. Syntax copied from other standards .................... 0
! 2.4.3. Syntax adapted from Email and MIME .................... 0
2.5. Language .................................................. 0
***************
*** 110,116 ****
4.2.5.3. Variant Headers ................................... 0
- 4.2.6. Undesirable Headers ................................... 0
4.3. Body ...................................................... 0
! 4.3.1. Body Format Issues .................................... 0
! 4.3.2. Body Conventions ...................................... 0
! 4.4. Characters and Character Sets ............................. 0
4.4.1. Character Sets within Article Headers ................. 0
--- 108,111 ----
4.2.5.3. Variant Headers ................................... 0
4.3. Body ...................................................... 0
! 4.4. Octets, Characters and Character Sets ..................... 0
4.4.1. Character Sets within Article Headers ................. 0
***************
*** 133,136 ****
5.6.4. Path-Delimiter Summary ................................ 0
! 5.6.5. Suggested Verification Methods ........................ 0
! 5.6.6. Example ............................................... 0
6. Optional Headers .............................................. 0
--- 128,130 ----
5.6.4. Path-Delimiter Summary ................................ 0
! 5.6.5. Example ............................................... 0
6. Optional Headers .............................................. 0
***************
*** 170,176 ****
6.21.3. Content-Transfer-Encoding ............................ 0
! 6.21.4. Character Sets ....................................... 0
! 6.21.5. Content Disposition .................................. 0
! 6.21.6. Definition of some new Content-Types ................. 0
! 6.21.6.1. Application/news-transmission .................... 0
! 6.21.6.2. Message/news obsoleted ........................... 0
6.22. Obsolete Headers ......................................... 0
--- 164,168 ----
6.21.3. Content-Transfer-Encoding ............................ 0
! 6.21.4. Definition of some new Content-Types ................. 0
! 6.21.4.1. Application/news-transmission .................... 0
! 6.21.4.2. Message/news obsoleted ........................... 0
6.22. Obsolete Headers ......................................... 0
***************
*** 258,260 ****
to negotiate an exchange of articles with one or more other
! participating hosts)
--- 251,253 ----
to negotiate an exchange of articles with one or more other
! participating hosts).
***************
*** 281,283 ****
the various parts of Usenet is established. For these purposes, a
! separate informational document [USEAGE] is being provided.
--- 274,276 ----
the various parts of Usenet is established. For these purposes, a
! separate Best Current Practice document [USEAGE] is being provided.
***************
*** 357,359 ****
possibly compliant article to a "posting agent". The poster is
! analogous to [RFC 2822]'s author(s).
--- 350,352 ----
possibly compliant article to a "posting agent". The poster is
! analogous to [RFC 2822]'s author.
***************
*** 509,611 ****
-------------------------------------------------------------------------
Since sections 2.4.2 and 2.4.3 have swapped positions (with renumbering),
it is preferable to show the diffs as it they had not been swapped, so
that the few actual changes can be exposed:
-------------------------------------------------------------------------
*** /tmp/old Mon Nov 24 21:46:45 2003
--- /tmp/new Mon Nov 24 21:44:13 2003
***************
*** 1,2 ****
! 2.4.2. Syntax adapted from Email and MIME
--- 1,2 ----
! 2.4.3. Syntax adapted from Email and MIME
***************
*** 15,19 ****
! However, there are some differences arising from some special
! requirements of Netnews, and the following syntactic rules therefore
! supersede the corresponding rules given in [RFC 2822].
--- 15,19 ----
! However, there are differences arising from some special requirements
! of Netnews, and the following syntactic rules therefore supersede the
! corresponding rules given in [RFC 2822].
***************
*** 24,27 ****
In contradistinction to [RFC 2822], an unstructured header (e.g. a
! Subject-header) MUST contain at least one non-whitespace character
! (see also remarks about empty headers in 4.2.6).
--- 24,26 ----
In contradistinction to [RFC 2822], an unstructured header (e.g. a
! Subject-header) MUST contain at least one non-whitespace character.
***************
*** 41,45 ****
[CFWS] "." [CFWS] )
- [ [RFC 2822] had
- obs-phrase = word *( word / "." / CFWS )
- Please can Pete check that what I have is equivalent?]
--- 40,41 ----
***************
*** 95,101 ****
! 2.4.3. Syntax copied from other standards
! The following syntactic forms, taken from [RFC 2234] or from [RFC
! 2822] and adapted to incorporate variations introduced in [RFC 2047],
! are repeated here for convenience only:
--- 92,99 ----
! 2.4.2. Syntax copied from other standards
! The following syntactic forms for characters, atoms and folding,
! taken from [RFC 2234] or from [RFC 2822] and adapted to incorporate
! variations introduced in [RFC 2047], are repeated here for
! convenience only:
***************
*** 148,177 ****
- The following are taken from [RFC 2045] and [RFC 2231] adapted to use
- the folding syntax from [RFC 2822]:
-
- charset = <registered character set name>
- ; [RFC 2978]
- language = <registered language tag>
- ; [RFC 3066]
- encoded-word = "=?" charset ["*" language] "?" encoding
- "?" encoded-text "?="
- parameter = regular-parameter / extended-parameter
- regular-parameter = [CFWS] regular-parameter-name [CFWS]
- "=" value
- regular-parameter-name = attribute [section]
- attribute = 1*attribute-char
- attribute-char= <any (US-ASCII) CHAR except SPACE, CTLs,
- "*", "'", "%", or tspecials>
- tspecials = "(" / ")" / "<" / ">" / "@" /
- "," / ";" / ":" / "\" / DQUOTE /
- "/" / "[" / "]" / "?" / "="
- extended-parameter
- = ( [CFWS] extended-initial-name [CFWS]
- "=" extended-initial-value ) /
- ( [CFWS] extended-other-names [CFWS]
- "=" extended-other-values )
- value = [CFWS] token [CFWS] / quoted-string
- token = 1*<any (US-ASCII) CHAR except SP, CTLs,
- or tspecials>
-
NOTE: Following [RFC 2234], literal text included in the syntax
--- 146,147 ----
***************
*** 205,206 ****
--- 173,203 ----
+ The following basic forms are taken from [RFC 2045] and [RFC 2231]
+ (having regard to [RFC Errata]), adapted to use the folding syntax
+ from [RFC 2822]:
+
+ charset = <registered character set name>
+ ; [RFC 2978]
+ language = <registered language tag>
+ ; [RFC 3066]
+ encoded-word = "=?" charset ["*" language] "?" encoding
+ "?" encoded-text "?="
+ parameter = regular-parameter / extended-parameter
+ regular-parameter = [CFWS] regular-parameter-name [CFWS]
+ "=" value
+ regular-parameter-name = attribute [section]
+ attribute = 1*attribute-char
+ attribute-char= <any (US-ASCII) CHAR except SPACE, CTLs,
+ "*", "'", "%", or tspecials>
+ tspecials = "(" / ")" / "<" / ">" / "@" /
+ "," / ";" / ":" / "\" / DQUOTE /
+ "/" / "[" / "]" / "?" / "="
+ extended-parameter
+ = ( [CFWS] extended-initial-name [CFWS]
+ "=" extended-initial-value ) /
+ ( [CFWS] extended-other-names [CFWS]
+ "=" extended-other-values )
+ value = [CFWS] token [CFWS] / quoted-string
+ token = 1*<any (US-ASCII) CHAR except SP, CTLs,
+ or tspecials>
+
For the purposes of section 5 of [RFC 2047] all headers (4.1) defined
***************
----------------------------------------
End of special diffs for 2.4.2 and 2.4.3
----------------------------------------
*** 869,874 ****
where the Usenet-parameter, which MUST always be of the same
! syntactic form as a parameter, is not provided in all headers, and
! even the extension-parameter is omitted in some cases (see 4.2.2).
! Observe that "Usenet" is (and MUST be) of the syntactic form of a
! header-name.
--- 862,867 ----
where the Usenet-parameter, which MUST always be of the same
! syntactic form as a parameter, is only provided for certain headers,
! and even the extension-parameter is omitted in some cases (see
! 4.2.2). Observe that "Usenet" is (and MUST be) of the syntactic form
! of a header-name.
***************
*** 879,885 ****
An article consists of some headers followed by a body. An empty line
! separates the two. The headers contain structured information about
! the article and its transmission. A header begins with a header-name
! identifying it, and can be continued onto subsequent lines as
! described in section 4.2.3. The body is largely unstructured text
! significant only to the poster and the readers.
--- 872,877 ----
An article consists of some headers followed by a body. An empty line
! separates the two. A header begins with a header-name identifying it,
! and can be continued onto subsequent lines as described in section
! 4.2.3. The body is largely unstructured text significant only to the
! poster and the readers.
***************
*** 895,899 ****
article as a sequence of lines each terminated by CRLF. This
! does not prevent serving agents or transport agents from storing
! or handling the article in other formats (e.g. using a single LF
! in place of CRLF) so long as the overall effects achieved are as
defined by this standard when operating on the canonical form.
--- 887,891 ----
article as a sequence of lines each terminated by CRLF. This
! does not prevent serving or relaying agents from storing or
! handling the article in other formats (e.g. using a single LF in
! place of CRLF) so long as the overall effects achieved are as
defined by this standard when operating on the canonical form.
***************
*** 946,952 ****
A few header-specific MIME-style parameters are defined in this
! standard, but there is also provision for generic extension-
! parameters to appear in most headers for the purpose of allowing
! future extensions to those headers. Observe that such parameters do
! not, in general, occur in headers defined in other standards, except
! for the MIME standards [RFC 2045] et seq. and their extensions.
--- 938,945 ----
A few header-specific MIME-style parameters are defined in this
! standard (see 6.12 and 6.19), but there is also provision for generic
! extension-parameters to appear in most headers for the purpose of
! allowing future extensions to those headers. Observe that such
! parameters do not, in general, occur in headers defined in other
! standards, except for the MIME standards [RFC 2045] et seq. and their
! extensions.
***************
*** 989,993 ****
is not encoded as an extended-value, it is necessary to
! encapsulate it within a quoted-string (see 2.4.3). Observe that
! the syntax of a parameter also allows additional WSP, folding
! and comments.
--- 982,986 ----
is not encoded as an extended-value, it is necessary to
! encapsulate it within a quoted-string (2.4.2). Observe that the
! syntax of a parameter also allows additional WSP, folding and
! comments.
***************
*** 995,997 ****
with the object represented by the token, or the semantic value
! (2.4.3) of the quoted-string, contained in its value.
--- 988,990 ----
with the object represented by the token, or the semantic value
! (2.4.2) of the quoted-string, contained in its value.
***************
*** 1014,1017 ****
be "folded" into a multiple line representation by inserting a CRLF
! before any WSP contained within any FWS or CFWS (but not any other SP
! or HTAB) allowed by this standard. For example, the header:
Approved: modname@modsite.example (Moderator of example.foo.bar)
--- 1007,1011 ----
be "folded" into a multiple line representation by inserting a CRLF
! before any WSP contained within any FWS (or CFWS), but not any other
! SP or HTAB, allowed by this standard (see 2.4.2). For example, the
! header:
Approved: modname@modsite.example (Moderator of example.foo.bar)
***************
*** 1023,1033 ****
order to allow the inclusion of comments, whitespace and folding. The
! syntax is in fact ambiguous insofar as it sometimes allows two
! consecutive instantiations of FWS (as least one of which is always
! optional), or of an optional FWS followed by an explicit CRLF.
! However, all such cases MUST be treated as if the optional
! instantiation (or one of them) had not been allowed. It is thus
! precluded that any line of a header should be made up of whitespace
! characters and nothing else (for such a line might otherwise have
! been interpreted by a non-compliant agent as the separator between
! the headers and the body of the article).
--- 1017,1027 ----
order to allow the inclusion of comments, whitespace and folding. The
! syntax is in fact ambiguous insofar as it sometimes allows for two
! consecutive FWS (as least one of which is always optional), or for an
! optional FWS followed by an explicit CRLF. In the first case, (one
! of) the optional FWS MUST NOT be instantiated; in the second case,
! the [*WSP CRLF] within the optional FWS MUST NOT be instantiated.
! Thus it is thus precluded that any line of a header should be made up
! of whitespace characters and nothing else (for such a line might
! otherwise have been interpreted by a non-compliant agent as the
! separator between the headers and the body of the article).
***************
*** 1047,1056 ****
! In accordance with the syntax, the header-name on the first line MUST
! be followed by a SP (even if the rest of the header is empty, but see
! 4.2.6). Even though the syntax allows otherwise, at least some of
! the content MUST appear on that first line (to avoid the possibility
! of harm by any non-compliant agent that might eliminate a trailing
! WSP). Although posting agents are REQUIRED to enforce these
! restrictions, relaying and serving agents SHOULD accept articles that
! violate them.
--- 1040,1052 ----
! In accordance with the syntax, the header-name and colon on the first
! line MUST be followed by a SP (even if the rest of the header is
! empty, which in fact cannot occur because this standard defines no
! headers with empty content and extensions MUST NOT do so). Even
! though the syntax allows otherwise, at least some visible content
! MUST appear on that first line (to avoid the possibility of harm by
! any non-compliant agent that might eliminate a trailing WSP). Posting
! and injecting agents are REQUIRED to enforce these restrictions,
! deleting any headers with empty content that are encountered, but
! relaying and serving agents MUST accept and pass on untouched
! articles that violate them.
***************
***************
*** 1125,1128 ****
Followup-To-header.
! o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
! copied from the precursor.
o References (6.10) - copied from the precursor, with the addition
--- 1123,1126 ----
Followup-To-header.
! o Subject (5.4) - often modified by prefixing with "Re: ", but
! otherwise copied from the precursor.
o References (6.10) - copied from the precursor, with the addition
***************
*** 1139,1141 ****
relayed throughout a Netnews system. The manner of the difference (or
! absence) MUST be as specified in this (or any future) standard.
Typically, these headers are modified as articles are propagated, or
--- 1137,1139 ----
relayed throughout a Netnews system. The manner of the difference (or
! absence) MUST be as specified in this (or some future) standard.
Typically, these headers are modified as articles are propagated, or
***************
*** 1148,1162 ****
o Xref (6.16) - used to keep track of the article locators of
! crossposted articles so that newsreaders serviced by a particular
! serving agent can mark such articles as read.
- 4.2.6. Undesirable Headers
- A header whose content is empty is said to be an empty header (in
- fact, no such headers are defined by this standard). Relaying and
- reading agents SHOULD NOT consider presence or absence of an empty
- header to alter the semantics of an article (although syntactic
- rules, such as requirements that certain header-names appear at most
- once, MUST still be satisfied). Posting and injecting agents SHOULD
- delete empty headers from articles before posting them; relaying
- agents MUST pass them untouched.
--- 1146,1151 ----
o Xref (6.16) - used to keep track of the article locators of
! crossposted articles so that reading agents serviced by a
! particular serving agent can mark such articles as read.
***************
*** 1164,1167 ****
- 4.3.1. Body Format Issues
-
The body of an article SHOULD NOT be empty. A posting or injecting
--- 1153,1154 ----
***************
*** 1179,1197 ****
Note that an article body is a sequence of lines terminated by CRLFs,
! not arbitrary binary data, and in particular it MUST end with a CRLF.
! However, relaying and serving agents SHOULD treat the body of an
! article as an uninterpreted sequence of octets (except as mandated by
! changes of CRLF representation and by control message processing, as
! in 7.2.4) and SHOULD avoid imposing constraints on it. See also
! section 4.5.
! 4.3.2. Body Conventions
- A body is by default an uninterpreted sequence of octets for most of
- the purposes of this standard. However, a MIME Content-Type-header
- may impose some structure or intended interpretation upon it, and may
- also specify the character set in accordance with which the octets
- are to be interpreted.
-
- 4.4. Characters and Character Sets
-
Transmission paths for news articles MUST treat news articles as
--- 1166,1173 ----
Note that an article body is a sequence of lines terminated by CRLFs,
! not arbitrary binary data, although a MIME Content-Type-header may
! impose some structure or intended interpretation upon it. In
! particular the body MUST end with a CRLF.
! 4.4. Octets, Characters and Character Sets
Transmission paths for news articles MUST treat news articles as
***************
*** 1216,1221 ****
- Character data is represented by octets in accordance with some
- encoding scheme (US-ASCII for headers, and determined by the
- Content-Type- and Content-Transfer-Encoding-headers for bodies).
-
If it comes to a relaying agent's attention that it is being asked to
--- 1192,1193 ----
***************
*** 1234,1238 ****
! Where the use of non-ASCII characters is required, they MUST be
! encoded using the MIME mechanisms defined in [RFC 2047] and [RFC
! 2231].
--- 1206,1210 ----
! The character set for headers is US-ASCII. Where the use of non-
! ASCII characters is required, they MUST be encoded using the MIME
! mechanisms defined in [RFC 2047] and [RFC 2231].
***************
*** 1290,1298 ****
length, not including the CRLF. All software compliant with this
! standard MUST support lines of at least that length, both in headers
! and in bodies, and all such software SHOULD support lines of
! arbitrary length. In particular, relaying agents MUST transmit lines
! of arbitrary length without truncation or any other modification.
NOTE: The limit of 998 octets is consistent with the
! corresponding limit in [RFC 2822].
--- 1261,1273 ----
length, not including the CRLF. All software compliant with this
! standard MUST support body lines of at least that length, and all
! such software SHOULD support lines of arbitrary length. In
! particular, relaying agents MUST transmit lines of arbitrary length
! without truncation or any other modification.
NOTE: The limit of 998 octets is consistent with the
! corresponding limit in [RFC 2822]. In practice, lines will be
! much shorter, and [USEAGE] suggests a default limit of 79
! characters to be used where there are no pressing needs to do
! otherwise.
***************
*** 1329,1333 ****
Just a quick announcement that a new standard example article has
! been released; it is in the new USEFOR standard obtainable from
ftp.ietf.org.
Ann.
--- 1304,1307 ----
Just a quick announcement that a new standard example article has
! been released; it is in the new [USEFOR] standard obtainable from
ftp.ietf.org.
Ann.
***************
*** 1347,1354 ****
of section 6, where References-, Sender-, or Approved-headers are
! mandatory. In control messages, specific values are required for
! certain headers.
- A proto-article (see 8.2.1) may lack some of these mandatory headers,
- but they MUST then be supplied by the injecting agent.
5.1. Date
--- 1321,1329 ----
of section 6, where References-, Sender-, or Approved-headers are
! mandatory.
+ A proto-article (8.2.1) may lack some of these mandatory headers, but
+ they MUST then be supplied by the injecting agent.
+
5.1. Date
***************
*** 1359,1361 ****
in [RFC 2822] (but see the revised definition of zone in section
! 2.4.2).
--- 1334,1336 ----
in [RFC 2822] (but see the revised definition of zone in section
! 2.4.3).
***************
*** 1414,1417 ****
rather than in a phrase at the start of it. Observe also the use
! of the quoted-string "John D. Smith" which is required on
! account of presence of the '.' character.
--- 1389,1393 ----
rather than in a phrase at the start of it. Observe also the use
! of the quoted-string "John D. Smith" which SHOULD still be used
! on account of presence of the '.' character, even though
! software is now REQUIRED to operate without it (see 2.4.3).
***************
*** 1422,1424 ****
article. The content syntax makes use of syntax defined in [RFC 2822]
! (but see the revised definition of msg-id in section 2.4.2).
--- 1398,1400 ----
article. The content syntax makes use of syntax defined in [RFC 2822]
! (but see the revised definition of msg-id in section 2.4.3).
***************
*** 1480,1483 ****
[RFC 2822], so ensuring that the Subject-content is not
! permitted to be completely empty, or to consist of WSP only (see
! remarks in 4.2.6 concerning undesirable headers).
--- 1456,1458 ----
[RFC 2822], so ensuring that the Subject-content is not
! permitted to be completely empty, or to consist of WSP only.
***************
*** 1534,1536 ****
force of the technical ones changes over time with developments in
! computers and operating systems) Therefore, such administrative
agencies SHOULD establish and promulgate the restrictions they intend
--- 1509,1511 ----
force of the technical ones changes over time with developments in
! computers and operating systems). Therefore, such administrative
agencies SHOULD establish and promulgate the restrictions they intend
***************
*** 1550,1556 ****
3. A component is limited to 30 component-graphemes and a
! newsgroup-name to 71 component-graphemes (counting also the
'.'s separating the components).
- [There was a suggestion to reduce that 71 to 66 in order to allow such a
- newsgoup-name to fit in the on the first line of a Followup-To-header
- without exceeding 79 characters.]
--- 1525,1528 ----
3. A component is limited to 30 component-graphemes and a
! newsgroup-name to 66 component-graphemes (counting also the
'.'s separating the components).
***************
***************
*** 1730,1733 ****
Any method of establishing the identity of the source may be used
! (but see 5.6.5 below), with the consideration that, in the event of
! problems, the agent concerned may be called upon to justify it.
--- 1700,1703 ----
Any method of establishing the identity of the source may be used
! with the consideration that, in the event of problems, the agent
! concerned may be called upon to justify it.
***************
*** 1749,1752 ****
agents MAY place any string here. When it is not an actual user
! name, the string "not-for-mail" is often used, but in fact a simple
! "x" would be sufficient.
--- 1719,1721 ----
agents MAY place any string here. When it is not an actual user
! name, the string "not-for-mail" is often used.
***************
*** 1807,1814 ****
! 5.6.5. Suggested Verification Methods
- [Section now omitted.]
-
- 5.6.6. Example
-
Path: foo.isp.example/
--- 1776,1779 ----
! 5.6.5. Example
Path: foo.isp.example/
***************
*** 2081,2083 ****
section 5.5. All other headers defined in this standard (excluding
! variant headers) MUST be identical in both the posted and mailed
versions of the article. The bodies MUST be identical in both, apart
--- 2049,2051 ----
section 5.5. All other headers defined in this standard (excluding
! variant headers) MUST be identical in both the posted and emailed
versions of the article. The bodies MUST be identical in both, apart
***************
*** 2097,2099 ****
in [RFC 2822] (but see the revised definition of msg-id in section
! 2.4.2).
--- 2064,2066 ----
in [RFC 2822] (but see the revised definition of msg-id in section
! 2.4.3).
***************
*** 2257,2262 ****
doubt). The content syntax makes use of syntax defined in [RFC 2822]
! (but see the revised definition of msg-id in section 2.4.2).
header =/ Supersedes-header
--- 2226,2229 ----
doubt). The content syntax makes use of syntax defined in [RFC 2822]
! (but see the revised definition of msg-id in section 2.4.3).
header =/ Supersedes-header
***************
*** 2473,2476 ****
parameters, any value containing an IPv6address, a date-time, a
! mailbox, any UTF8-xtra-char, or any CFWS MUST be quoted using
! <DQUOTE>s (the quoting is optional in other cases).
--- 2437,2440 ----
parameters, any value containing an IPv6address, a date-time, a
! mailbox, or any CFWS MUST be quoted using <DQUOTE>s (the quoting
! is optional in other cases).
***************
*** 2491,2494 ****
unless it has positive evidence of its correctness. An injecting
! agent MAY also include extension-parameters with x-attributes which
! will assist in identifying the origin of the article.
--- 2455,2458 ----
unless it has positive evidence of its correctness. An injecting
! agent MAY also include further extension-parameters with x-attributes
! which will assist in identifying the origin of the article.
***************
*** 2649,2651 ****
of the recipient, and do not constitute a request to repost them
! (refer to 6.21.6.2 for the now obsolete "message/news" formerly
intended for this purpose).
--- 2616,2618 ----
of the recipient, and do not constitute a request to repost them
! (refer to 6.21.4.2 for the now obsolete "message/news" formerly
intended for this purpose).
***************
*** 2687,2698 ****
! 6.21.4. Character Sets
- [This section to be removed]
-
- 6.21.5. Content Disposition
-
- [This section to be removed]
-
- 6.21.6. Definition of some new Content-Types
-
This standard defines (or redefines) several new Content-Types, which
--- 2654,2657 ----
! 6.21.4. Definition of some new Content-Types
This standard defines (or redefines) several new Content-Types, which
***************
*** 2703,2705 ****
! 6.21.6.1. Application/news-transmission
--- 2662,2664 ----
! 6.21.4.1. Application/news-transmission
***************
*** 2773,2775 ****
! 6.21.6.2. Message/news obsoleted
--- 2733,2735 ----
! 6.21.4.2. Message/news obsoleted
***************
*** 3068,3071 ****
- Plain "rmgroup":
-
From: "example.all Administrator" <admin@noc.example>
--- 3031,3032 ----
***************
*** 3378,3384 ****
relatively infrequently and SHOULD contain reasonable numbers of
! message IDs. If ihave and sendme are being used to implement a backup
! feed, it may be desirable to insert a delay between reception of an
! ihave and generation of a sendme, so that a slightly slow primary
! feed will not cause large numbers of articles to be requested
! unnecessarily via sendme.
--- 3338,3344 ----
relatively infrequently and SHOULD contain reasonable numbers of
! message identifiers. If ihave and sendme are being used to implement
! a backup feed, it may be desirable to insert a delay between
! reception of an ihave and generation of a sendme, so that a slightly
! slow primary feed will not cause large numbers of articles to be
! requested unnecessarily via sendme.
***************
*** 3544,3546 ****
the email, preferably using the Content-Type
! "application/news-transmission" (6.21.6.1) with any usage
parameter set to "moderate". Moreover, there SHOULD NOT be
--- 3506,3508 ----
the email, preferably using the Content-Type
! "application/news-transmission" (6.21.4.1) with any usage
parameter set to "moderate". Moreover, there SHOULD NOT be
***************
*** 3641,3643 ****
indexed by newsgroup with articles in each newsgroup identified by an
! article-locater (usually in the form of a decimal number - see 6.16).
--- 3603,3605 ----
indexed by newsgroup with articles in each newsgroup identified by an
! article-locator (usually in the form of a decimal number - see 6.16).
***************
*** 3703,3707 ****
1. The Newsgroups-header (5.5) SHOULD be initialized from the
! precursor's Followup-To-header, if present, when preparing a
! followup; however posters MAY then change this before posting if
! they wish.
--- 3667,3671 ----
1. The Newsgroups-header (5.5) SHOULD be initialized from the
! precursor's Followup-To-header, if present and otherwise from the
! precursor's Newsgroups-header, when preparing a followup; however
! posters MAY then change this before posting if they wish.
***************
*** 3711,3717 ****
already present in its Subject-content; however posters MAY then
! change this before posting if they wish.
! Followup agents MUST NOT use any other string except "Re: " as a
back-reference, and specifically NOT a translation of "Re: " into
! a local language, and they MUST NOT prepend a "Re: " if one is
already present.
--- 3675,3683 ----
already present in its Subject-content; however posters MAY then
! change this before posting if they wish. The prepended "Re: "
! SHOULD NOT be contained within any encoded-word in the new
! Subject-content.
! Followup agents SHOULD NOT use any other string except "Re: " as a
back-reference, and specifically NOT a translation of "Re: " into
! a local language, and they SHOULD NOT prepend a "Re: " if one is
already present.
***************
*** 3718,3722 ****
[The provision of back-references and their allowed forms are still
! under discussion in the Usefor Working Group.
! The matter of a "Re: " occurring within an encoded-word needs to be
! clarified.]
--- 3684,3686 ----
[The provision of back-references and their allowed forms are still
! under discussion in the Usefor Working Group.]
***************
*** 3768,3770 ****
! Followup agents MUST NOT attempt to send email to any address
ending in ".invalid".
--- 3732,3734 ----
! Followup agents SHOULD NOT attempt to send email to any address
ending in ".invalid".
***************
*** 4300,4302 ****
! application/news-transmission (6.21.6.1)
application/news-groupinfo (7.2.1.2)
--- 4257,4259 ----
! application/news-transmission (6.21.4.1)
application/news-groupinfo (7.2.1.2)
***************
*** 4307,4309 ****
! message/news (6.21.6.2)
--- 4264,4266 ----
! message/news (6.21.4.2)
***************
*** 4383,4390 ****
- [RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
- RFC 2279, January 1998.
-
- [RFC 2279bis] F. Yergeau, "UTF-8, a transformation format of ISO
- 10646", draft-yergeau-rfc2279bis-00.txt, April 2002.
-
[RFC 2298] R. Fajman, "An Extensible Message Format for Message
--- 4340,4341 ----
***************
*** 4430,4431 ****
--- 4381,4385 ----
+ [RFC Errata] RFC Editor, "RFC Errata", <http"//www/rfc-
+ editor.org/errata.html>.
+
[Son-of-1036] Henry Spencer, "News article format and transmission",
***************
*** 4515,4517 ****
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Dec 2003).
--- 4471,4473 ----
This draft expires six months after the date of publication (see Page
! 1) (i.e. in May 2004).
***************
*** 4532,4536 ****
The first line consisted of an "A" followed by an article ID
! (analogous to a message ID and used for similar purposes). The
! second line was the list of newsgroups. The third line was the path.
! The fourth was the date, in the format above (all fields fixed
width), resembling an Internet date but not quite the same. The fifth
--- 4488,4492 ----
The first line consisted of an "A" followed by an article ID
! (analogous to a message identifier and used for similar purposes).
! The second line was the list of newsgroups. The third line was the
! path. The fourth was the date, in the format above (all fields fixed
width), resembling an Internet date but not quite the same. The fifth
***************
*** 4565,4571 ****
Article-I.D.-header contained an article ID, analogous to a message
! ID and used for similar purposes. The Newsgroups- and Expires-headers
! were approximately as now. The Received-header contained the date
! when the latest relaying agent to process the article first saw it.
! All dates were in the above format, with all fields fixed width,
! resembling an Internet date but not quite the same.
--- 4521,4528 ----
Article-I.D.-header contained an article ID, analogous to a message
! identifier and used for similar purposes. The Newsgroups- and
! Expires-headers were approximately as now. The Received-header
! contained the date when the latest relaying agent to process the
! article first saw it. All dates were in the above format, with all
! fields fixed width, resembling an Internet date but not quite the
! same.
***************
*** 4649,4651 ****
indicate rules taken from other documents, specifically:
! 1 from [RFC 2231];
2 from [RFC 2822] with the exception of those elements described
--- 4605,4608 ----
indicate rules taken from other documents, specifically:
! 1 from [RFC 2231] having regard to errata contained in [RFC
! Errata];
2 from [RFC 2822] with the exception of those elements described
***************
*** 4732,4735 ****
DQUOTE
! 2 text = %d1-9 / ; all UTF-8 characters except
! %d11-12 / ; US-ASCII NUL, CR and LF
%d14-127
--- 4696,4699 ----
DQUOTE
! 2 text = %d1-9 / ; all US-ASCII characters except
! %d11-12 / ; NUL, CR and LF
%d14-127
***************
*** 4768,4771 ****
extended-other-values
! 1 extended-other-names = attribute other-section "*"
! 1* extended-other-value = *( "%" 2HEXDIG / attribute-char )
1* extended-parameter = ( [CFWS] extended-initial-name [CFWS]
--- 4732,4735 ----
extended-other-values
! 1 extended-other-names = attribute other-sections "*"
! 1* extended-other-values= *( "%" 2HEXDIG / attribute-char )
1* extended-parameter = ( [CFWS] extended-initial-name [CFWS]
***************
*** 5090,5092 ****
! Copyright (C) The Internet Society (2002). All Rights Reserved
--- 5052,5054 ----
! Copyright (C) The Internet Society (2003). All Rights Reserved
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: chl@clerew.man.ac.uk 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