From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri May 31 2002 - 06:21:16 CDT
I have put up another working draft
http://www.landfield.com/usefor/drafts/draft-ietf-usefor-article-07.01.unpaged
Changes are
1. Numerous typos, nitpicks and clarifications.
2. Various consequential changes resulting from other recent changes
3. Various recent changes discussed and announced to this list (these are
the only substantive ones).
The intention is that this is to be the final draft. So if I hear no
objections by the next Friday, I shall put it up as an Internet Draft and
ask the IESG to put it to Last Call. Then it will be up to the IESG.
OTOH, if problems, nitpicks, objections, etc. are posted here before then,
then I shall deal with them (heck, I might even find some more typos
myself :-( ).
Here are the full diffs since draft-07.
*** landfield/drafts/draft-ietf-usefor-article-07.unpaged Fri May 3 17:48:07 2002
--- landfield/drafts/draft-ietf-usefor-article-07.01.unpaged Fri May 31 11:47:53 2002
***************
*** 3,5 ****
Usenet Format Working Group University of Manchester
! May 2002
--- 3,5 ----
Usenet Format Working Group University of Manchester
! June 2002
***************
*** 62,69 ****
ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
! the time this document is published.]
- [Please note that this Draft is now close to Last Call, and the material
- included here is unlikely to change in any major way.]
-
Table of Contents
--- 62,67 ----
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].]
Table of Contents
***************
*** 314,317 ****
written in 1994 by Henry Spencer. That document formed the original
! basis for this standard. Much is taken directly from Son of 1036, and
! it is hoped that we have followed its spirit and intentions.
--- 312,319 ----
written in 1994 by Henry Spencer. That document formed the original
! basis for this standard, and its author has endorsed this standard as
! its successor. Much is taken directly from Son of 1036, and it is
! hoped that we have followed its spirit and intentions. It is
! anticipated that [Son-of-1036] will be published as an Historic RFC,
! in a suitably relabelled form, following the publication of this
! standard.
***************
*** 592,594 ****
MAY be passed on untouched by other agents, but they MUST NOT ever be
! interpreted as valid characters.
--- 601,603 ----
MAY be passed on untouched by other agents, but they MUST NOT ever be
! decoded or otherwise interpreted as meaningful characters.
***************
*** 595,598 ****
Observe, in contradistinction to [RFC 2822], that an unstructured
! MUST contain at least one non-whitespace character (see also remarks
! about empty headers in 4.2.6).
--- 604,607 ----
Observe, in contradistinction to [RFC 2822], that an unstructured
! header MUST contain at least one non-whitespace character (see also
! remarks about empty headers in 4.2.6).
***************
*** 636,639 ****
DQUOTE
! WSP = SP / HTAB ; Whitespace characters
! FWS = ([*WSP CRLF] 1*WSP); Folding whitespace
ccontent = ctext / quoted-pair / comment
--- 641,644 ----
DQUOTE
! WSP = SP / HTAB ; whitespace characters
! FWS = ([*WSP CRLF] 1*WSP); folding whitespace
ccontent = ctext / quoted-pair / comment
***************
*** 640,642 ****
comment = "(" *([FWS] ccontent) [FWS] ")"
! CFWS = *([FWS] comment) (([FWS] comment) / FWS )
DQUOTE = %d34 ; quote mark
--- 645,647 ----
comment = "(" *([FWS] ccontent) [FWS] ")"
! CFWS = *([FWS] comment) ( ([FWS] comment) / FWS )
DQUOTE = %d34 ; quote mark
***************
*** 734,736 ****
extension of those headers in future standards.
! o Certain headers and Control messages (AppendixA.3 and Appendix
A.4) have been made obsolete.
--- 739,741 ----
extension of those headers in future standards.
! o Certain headers and Control messages (Appendix A.3 and Appendix
A.4) have been made obsolete.
***************
*** 940,942 ****
! The possibility of allowing Mime-style parameters (whether header-
specific ones or generic other-parameters) to appear in virtually all
--- 938,940 ----
! The possibility of allowing MIME-style parameters (whether header-
specific ones or generic other-parameters) to appear in virtually all
***************
*** 969,972 ****
! Each header-specific parameter introduced in this standard is
! described by specifying
(a) the token to be used in its attribute, and
--- 967,970 ----
! Each header-specific MIME-style parameter introduced in this standard
! is described by specifying
(a) the token to be used in its attribute, and
***************
*** 988,990 ****
A valid posting-sender-parameter would be
! sender = "\"Joe D. Bloggs\" <jdbloggs@example.com>" (authinfo)
The comment (syntactically part of the quoted-string) is irrelevant.
--- 986,988 ----
A valid posting-sender-parameter would be
! sender = "\"Joe D. Bloggs\" <jdbloggs@bloggs.example>" (authinfo)
The comment (syntactically part of the quoted-string) is irrelevant.
***************
*** 992,994 ****
to the sender) is
! "Joe D. Bloggs" <jdbloggs@example.com>
--- 990,992 ----
to the sender) is
! "Joe D. Bloggs" <jdbloggs@bloggs.example>
***************
*** 1011,1019 ****
consecutive instantiations of FWS (as least one of which is always
! optional), or of 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 present. 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).
--- 1009,1017 ----
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).
***************
*** 1027,1030 ****
NOTE: It may be observed that the content part of every header
! begins and ends with an optional CFWS (or FWS in the case of
! certain headers). Moreover, every parameter also begins and ends
with an optional CFWS.
--- 1025,1028 ----
NOTE: It may be observed that the content part of every header
! begins and ends with an optional CFWS (or FWS in the case of a
! few headers). Moreover, every parameter also begins and ends
with an optional CFWS.
***************
*** 1031,1040 ****
! NOTE: Though contents are defined in such a way that folding can
! take place between many of the lexical tokens (and even within
! some of them), folding should be limited to placing the CRLF at
! higher-level syntactic breaks, and should also avoid leaving
! trailing WSP on the preceding line. For instance, if a header-
! content is defined as comma-separated values, it is recommended
! that folding occur after the comma separating the structured
! items, even if it is allowed elsewhere.
--- 1029,1038 ----
! NOTE: Although contents are defined in such a way that folding
! can take place between many of the lexical tokens (and even
! within some of them), folding should be limited to placing the
! CRLF at higher-level syntactic breaks, and should also avoid
! leaving trailing WSP on the preceding line. For instance, if a
! header-content is defined as comma-separated values, it is
! recommended that folding occur after the comma separating the
! values, even if it is allowed elsewhere.
***************
*** 1144,1146 ****
anywhere within the headers (though placing it first is recommended).
! The principle examples are:
o Path (5.6) - augmented at each relaying agent that an article
--- 1142,1144 ----
anywhere within the headers (though placing it first is recommended).
! The principal examples are:
o Path (5.6) - augmented at each relaying agent that an article
***************
*** 1166,1168 ****
state information that reading agents can typically determine easily
! themselves (e.g. the length of the body in octets) are redundant and
posters and posting agents Ought Not to include them.
--- 1164,1166 ----
state information that reading agents can typically determine easily
! themselves (e.g. the length of the body in octets) are redundant and
posters and posting agents Ought Not to include them.
***************
*** 1228,1230 ****
correct usage, and the use of the words "MUST", "SHOULD", etc. is to
! be understood accordingly.
--- 1226,1228 ----
correct usage, and the use of the words "MUST", "SHOULD", etc. is to
! be understood in that context.
***************
*** 1248,1251 ****
automatic recognition and processing by sophisticated reading agents.
! The attribution SHOULD contain the name or the email address of the
! precursor's poster, as in
Joe D. Bloggs <jdbloggs@foo.example> wrote:
--- 1246,1249 ----
automatic recognition and processing by sophisticated reading agents.
! The attribution SHOULD contain the name and/or the email address of
! the precursor's poster, as in
Joe D. Bloggs <jdbloggs@foo.example> wrote:
***************
*** 1329,1331 ****
according to the UTF-8 encoding scheme [RFC 2279] or [ISO/IEC 10646],
! and hence all the characters in Unicode [UNICODE 3.1] or in the
Universal Multiple-Octet Coded Character Set (UCS) [ISO/IEC 10646]
--- 1327,1329 ----
according to the UTF-8 encoding scheme [RFC 2279] or [ISO/IEC 10646],
! and hence all the characters in Unicode [UNICODE 3.2] or in the
Universal Multiple-Octet Coded Character Set (UCS) [ISO/IEC 10646]
***************
*** 1336,1350 ****
! NOTE: UTF-8 is an encoding for 16bit (and even 32bit) character
! sets with the property that any octet less than 128 immediately
! represents the corresponding US-ASCII character, thus ensuring
! upwards compatibility with previous practice. Non-ASCII
! characters from Unicode are represented by sequences of octets
! satisfying the syntax of a UTF8-xtra-char (2.4.2), which
! excludes certain octet sequences not explicitly permitted by
! [RFC 2279]. Unicode includes all characters from the ISO-8859
! series of characters sets [ISO 8859] (which includes all
! Cyrillic, Greek and Arabic characters) together with the more
! elaborate characters used in Asian countries. See the following
! section for the appropriate treatment of Unicode characters by
! reading agents.
--- 1334,1350 ----
! NOTE: UTF-8 is an encoding for the [ISO/IEC 10646] character set
! (in both its 16 and 32 bit forms) with the property that any
! octet less than 128 immediately represents the corresponding
! US-ASCII character, thus ensuring upwards compatibility with
! previous practice. Non-ASCII characters from Unicode are
! represented by sequences of octets satisfying the syntax of a
! UTF8-xtra-char (2.4.2), which excludes certain octet sequences
! not explicitly permitted by [RFC 2279]. Unicode includes all
! characters from the ISO-8859 series of characters sets [ISO
! 8859] (which includes all Cyrillic, Greek and Arabic characters)
! together with the more elaborate characters used in Asian
! countries. See the following section for the appropriate
! treatment of Unicode characters by reading agents.
! [The sentence mentioning [RFC 2279] could be simplified if [RFC 2279bis]
! has been accepted by the time this standard is published.]
***************
*** 1360,1362 ****
characters, but SHOULD nevertheless be invariant under Unicode
! normalization NFC [UNICODE 3.1].
--- 1360,1362 ----
characters, but SHOULD nevertheless be invariant under Unicode
! normalization NFC [UNICODE 3.2].
***************
*** 1368,1376 ****
it could be written in more than one way, only one particular
! one is allowed (for example, the single character E-acute is
! preferred over E followed by a non-spacing acute accent, and A-
! ring is preferred over the Angstrom symbol). At least for the
! main European languages, for which all the needed composites are
! already available as single characters, it is unlikely that
! posting agents will need to take any special steps to ensure
! normalization.
--- 1368,1376 ----
it could be written in more than one way, only one particular
! one of those ways is allowed (for example, the single character
! E-acute is preferred over E followed by a non-spacing acute
! accent, and A-ring is preferred over the Angstrom symbol). At
! least for the main European languages, for which all the needed
! composites are already available as single characters, it is
! unlikely that posting agents will need to take any special steps
! to ensure normalization.
***************
*** 1584,1585 ****
--- 1583,1588 ----
+ Observe that there is no provision for parameters in this
+ header, or in other headers containing addresses likely to be
+ used for sending email (see 4.2.2).
+
Each mailbox in the From-content SHOULD be a valid address, belonging
***************
*** 1640,1642 ****
*( strict-qtext / "\\" / "\" DQUOTE )
! DQUOTE
qspecial = "(" / ")" / ; same as specials except
--- 1642,1644 ----
*( strict-qtext / "\\" / "\" DQUOTE )
! DQUOTE
qspecial = "(" / ")" / ; same as specials except
***************
*** 1691,1693 ****
reference") followed by the contents of the pure-subject of the
! precursor. Any leading "Re: " in the pure-subject MUST be stripped.
--- 1693,1695 ----
reference") followed by the contents of the pure-subject of the
! precursor. Any leading "Re: " in that pure-subject MUST be stripped.
***************
*** 1702,1707 ****
! NOTE: The given syntax differs from that prescribed in [RFC
! 2822] insofar as it does not permit a header content to be
! completely empty, or to consist of WSP only (see remarks in
! 4.2.6 concerning undesirable headers).
--- 1704,1709 ----
! NOTE: The syntax of unstructured differs from that prescribed in
! [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).
***************
*** 1710,1712 ****
"Sv: ") from the Subject-content when composing the subject of a
! followup and add a correct back-reference in front of the result.
--- 1712,1714 ----
"Sv: ") from the Subject-content when composing the subject of a
! followup, and add a correct back-reference in front of the result.
***************
*** 1725,1732 ****
Agents SHOULD NOT depend on nor enforce the use of back references by
! followup agents. For compatibility with legacy news software the
! Subject-content of a control message (i.e. an article that also
! contains a Control-header) MAY start with the string "cmsg ", and
! non-control messages MUST NOT start with the string "cmsg ". See also
! section 6.13.
5.4.1. Examples
--- 1727,1735 ----
Agents SHOULD NOT depend on nor enforce the use of back references by
! followup agents.
+ For compatibility with legacy news software, the Subject-content of a
+ control message (i.e. an article that also contains a Control-header)
+ MAY start with the string "cmsg ", and non-control messages MUST NOT
+ start with the string "cmsg ". See also section 6.13.
+
5.4.1. Examples
***************
*** 1735,1738 ****
by this standard. "was: " is a convention used by many English-
! speaking posters to signal a change in subject matter. Software
! should be able to deduce this information from References-header.
--- 1738,1741 ----
by this standard. "was: " is a convention used by many English-
! speaking posters to signal a change in subject matter. Software can
! always recognize such changes from the References-header.
***************
*** 1755,1767 ****
! References to "Unicode" or "the latest version of the Unicode
! Standard" mean [UNICODE 3.1] or any standard that supersedes it. That
! document contains guarantees of strict future upwards compatibility
! (e.g. no character will be removed or change classification).
! Implementors should be aware that currently unassigned code points
! (Unicode category Cn) may become valid characters in future versions
! of Unicode. Since the poster of an article might have access to a
! newer version of that standard, relaying and serving agents MUST
! accept such characters, but posting agents (and indeed all agents)
! MUST NOT generate them (though they might well follow up to
! newsgroup-names containing them).
--- 1758,1771 ----
! In order to allow newsgroup-names containing Non-ASCII characters,
! this section relies heavily on the provisions of the Unicode
! Standard. All references to "Unicode" mean [UNICODE 3.2] or any
! standard that supersedes it. That document contains guarantees of
! strict future upwards compatibility (e.g. no character will be
! removed or change classification). Implementors should be aware that
! currently unassigned code points (Unicode category Cn) may become
! valid characters in future versions of Unicode. Since the poster of
! an article might have access to a newer version of that standard,
! relaying and serving agents MUST accept such characters, but posting
! agents (and indeed all agents) MUST NOT generate them (though they
! might well follow up to newsgroup-names containing them).
***************
*** 1774,1778 ****
newsgroup-name = component *( "." component )
! component = 1*component-glyph
ng-delim = ","
! component-glyph = combiner-base *combiner-mark
combiner-base = combiner-ASCII / combiner-extended
--- 1778,1782 ----
newsgroup-name = component *( "." component )
! component = 1*component-grapheme
ng-delim = ","
! component-grapheme = combiner-base *combiner-mark
combiner-base = combiner-ASCII / combiner-extended
***************
*** 1780,1800 ****
combiner-extended = <any character with a Unicode code value of
! 0080 or greater and a combining class of 0,
! but excluding any character in Unicode
! categories Cc, Cf, Cs, Zs, Zl, and Zp>
combiner-mark = <any character with a Unicode code value of
! 0080 or greater and a combining class other
! than 0>
-
- NOTE: the excluded characters are control characters (Cc),
- format control characters (Cf), surrogates (Cs), and separators
- (Zs, Zl, Zp). In particular, this excludes all whitespace
- characters. To all intents and purposes, a component-glyph is
- what a user might regard as a single "character" as displayed on
- his screen, though it might be transmitted as several actual
- characters (e.g. q-circumflex is two characters). Note also
- that, in some writing schemes, several component-glyphs will
- merge into one visible object of variable size.
-
Each component MUST be invariant under Unicode normalization NFKC
--- 1784,1802 ----
combiner-extended = <any character with a Unicode code value of
! 0080 or greater but excluding any character
! in Unicode categories Cc, Cf, Cs, M* and Z*>
!
combiner-mark = <any character with a Unicode code value of
! 0080 or greater and in Unicode category M*>
+ NOTE: the excluded characters in a combiner-extended are control
+ characters (Cc), format control characters (Cf), surrogates
+ (Cs), marks (M*) and separators (Z*). In particular, this
+ excludes all whitespace characters. To all intents and
+ purposes, a component-grapheme is what a user might regard as a
+ single "character" as displayed on his screen, though it might
+ be transmitted as several actual characters (e.g. q-circumflex
+ is two characters). Note also that, in some writing schemes,
+ several component-graphemes will merge into one visible object
+ of variable size.
Each component MUST be invariant under Unicode normalization NFKC
***************
*** 1916,1924 ****
! 3. A component is limited to 30 component-glyphs and a newsgroup-name
! to 71 component-glyphs. Whilst there is no longer any technical
! reason to limit the length of a component (formerly, it was
! limited to 14 octets) nor of a newsgroup-name, it should be noted
! that these names are also used in the newsgroups line (7.2.1.2)
! where an overall policy limit applies and, moreover, excessively
! long names can be exceedingly inconvenient in practical use.
--- 1917,1926 ----
! 3. A component is limited to 30 component-graphemes and a newsgroup-
! name to 71 component-graphemes (counting also the '.'s separating
! the components). Whilst there is no longer any technical reason to
! limit the length of a component (formerly, it was limited to 14
! octets) nor of a newsgroup-name, it should be noted that these
! names are also used in the newsgroups line (7.2.1.2) where an
! overall policy limit applies and, moreover, excessively long names
! can be exceedingly inconvenient in practical use.
***************
*** 1969,1972 ****
Posters SHOULD use only the names of existing newsgroups in the
! Newsgroups-header. However, it is legitimate to cross-post to a
! newsgroup(s) which do not exist on the posting agent's host, provided
that at least one of the newsgroups DOES exist there, and followup
--- 1971,1974 ----
Posters SHOULD use only the names of existing newsgroups in the
! Newsgroups-header. However, it is legitimate to cross-post to
! newsgroups which do not exist on the posting agent's host, provided
that at least one of the newsgroups DOES exist there, and followup
***************
*** 2045,2047 ****
path-delimiter = "/" / "?" / "%" / "," / "!"
! tail-entry = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
--- 2048,2050 ----
path-delimiter = "/" / "?" / "%" / "," / "!"
! tail-entry = path-identity
***************
*** 2134,2136 ****
the injecting agent in the chain. In normal circumstances there
! should therefore be only one `%` path-delimiter present, and
injecting agents MAY choose to reject proto-articles with a '%'
--- 2141,2143 ----
the injecting agent in the chain. In normal circumstances there
! should therefore be only one '%' path-delimiter present, and
injecting agents MAY choose to reject proto-articles with a '%'
***************
*** 2157,2163 ****
circumstances of the injection such as the identity of the source
! machine (especially if the Injector-Info-header (6.19) is absent).
! Any such inclusion SHOULD NOT conflict with any genuine site
! identifier. The '!' path-delimiter may be used freely within the
! pre-injection region, although '/' and '?' are also appropriate if
! used correctly.
--- 2164,2170 ----
circumstances of the injection such as the identity of the source
! machine (especially if an Injector-Info-header (6.19) is not being
! provided). Any such inclusion SHOULD NOT conflict with any genuine
! site identifier. The '!' path-delimiter may be used freely within
! the pre-injection region, although '/' and '?' are also appropriate
! if used correctly.
***************
*** 2457,2459 ****
NOTE: A poster who wishes both a personal reply and a followup
! post should include a Mail-Copies-To-header (6.8).
--- 2467,2469 ----
NOTE: A poster who wishes both a personal reply and a followup
! post should include an appropriate Mail-Copies-To-header (6.8).
***************
*** 2560,2562 ****
precursors. The content syntax makes use of syntax defined in [RFC
! 2822].
--- 2570,2572 ----
precursors. The content syntax makes use of syntax defined in [RFC
! 2822], subject to the same revisions as in section 5.3.
***************
*** 2719,2723 ****
newsgroups. If this header is not present in such postings, then
! relaying and serving agents MUST reject the article. Please see
! section 8.2.2 for how injecting agents should treat postings to
! moderated groups that do not contain this header.
--- 2725,2729 ----
newsgroups. If this header is not present in such postings, then
! serving agents MUST (and relaying agents MAY) reject the article.
! Please see section 8.2.2 for how injecting agents should treat
! postings to moderated groups that do not contain this header.
***************
*** 2743,2745 ****
honour a "cancel" message, especially if its authenticity is in
! doubt). The content syntax makes use of syntax defined in [RFC 2822].
--- 2749,2752 ----
honour a "cancel" message, especially if its authenticity is in
! doubt). The content syntax makes use of syntax defined in [RFC 2822],
! subject to the same revisions as in 5.3.
***************
*** 2758,2760 ****
! If an article contains a Supersedes-header, then the old article
mentioned SHOULD be withdrawn from circulation or access, as in a
--- 2765,2767 ----
! Thus when an article contains a Supersedes-header, the old article
mentioned SHOULD be withdrawn from circulation or access, as in a
***************
*** 2803,2806 ****
! An agent MUST use the same serving-name in Xref-headers as the path-
! identity it uses in Path-headers.
--- 2809,2814 ----
! It is convenient, though not required, for a serving agent to use the
! same server-name in Xref-headers as the path-identity it uses in
! Path-headers (just so long as reading agents can distinguish it from
! other serving agents known to them).
***************
*** 2965,2968 ****
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).
--- 2973,2976 ----
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).
***************
*** 3146,3148 ****
article, but the recommendations and limits on line lengths set out
! in section 4.5 Ought to be observed
--- 3152,3154 ----
article, but the recommendations and limits on line lengths set out
! in section 4.5 Ought to be observed.
***************
*** 3191,3194 ****
of excessive length, since reading of the individual parts on
! their own is not required and they would in any case be encoded
! in a manner that was 7bit-safe.
--- 3198,3201 ----
of excessive length, since reading of the individual parts on
! their own is not required and they would likely be encoded in a
! manner that was 7bit-safe.
***************
*** 3317,3319 ****
MUST be encoded as for 8bit-unsafe. This is most likely to arise
! in the case of 16-bit character sets such as UTF-16 ([UNICODE3.1]
or [ISO/IEC 10646]). In addition, where it is known that the
--- 3325,3327 ----
MUST be encoded as for 8bit-unsafe. This is most likely to arise
! in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2]
or [ISO/IEC 10646]). In addition, where it is known that the
***************
*** 3325,3327 ****
Encoding. In particular, the authentication protocol based on
! [Open]PGP defined in [RFC 3156] mandates the use of one of the
encodings "quoted-printable" or "base64". Whilst posters might be
--- 3333,3335 ----
Encoding. In particular, the authentication protocol based on
! OpenPGP defined in [RFC 3156] mandates the use of one of the
encodings "quoted-printable" or "base64". Whilst posters might be
***************
*** 3344,3346 ****
standard discourages (see 6.21.2.1) the use of "message/partial"
! except for binary material, which will be encoded to pass
through "7bit" in any case.
--- 3352,3354 ----
standard discourages (see 6.21.2.1) the use of "message/partial"
! except for binary material, which will likely be encoded to pass
through "7bit" in any case.
***************
*** 4119,4121 ****
! The following control message verbs are declared obsolete by this
standard:
--- 4126,4128 ----
! The following control messages are declared obsolete by this
standard:
***************
*** 4240,4242 ****
5. If the article is rejected, or is otherwise incorrectly formatted
! or unacceptable due to site policy, the posting agent MUST be
informed (such as via an NNTP 44x response code) that posting has
--- 4245,4247 ----
5. If the article is rejected, or is otherwise incorrectly formatted
! or unacceptable due to site policy, the posting agent SHOULD be
informed (such as via an NNTP 44x response code) that posting has
***************
*** 4244,4246 ****
! 6. The Message-ID and Date-headers (and their content) MUST be added
when not already present.
--- 4249,4251 ----
! 6. The Message-ID and Date-headers (and their contents) MUST be added
when not already present.
***************
*** 4292,4295 ****
"new-announce-important@forwardingagent.example".
- [If the IDNS people come up with specific proposals before this draft is
- finally submitted, we may be able to replace the following paragraph.]
--- 4298,4299 ----
***************
*** 4297,4299 ****
char, this will result in an addr-spec whose local-part is not
! consistent the present email standards ([RFC2822]). It is
anticipated that extensions to those standards currently under
--- 4301,4303 ----
char, this will result in an addr-spec whose local-part is not
! consistent with the present email standards ([RFC 2822]). It is
anticipated that extensions to those standards currently under
***************
*** 4333,4336 ****
6. It SHOULD reject any article that matches an already received
! cancel message (or an equivalent, Supersedes-header) issued by its
poster or by some other trusted entity.
--- 4337,4342 ----
+
+
6. It SHOULD reject any article that matches an already received
! cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity.
***************
*** 4343,4345 ****
8. It then passes articles which match mutually agreed criteria on to
! neighboring relaying and serving agents. However, it SHOULD NOT
forward articles to sites whose path-identity is already in the
--- 4349,4351 ----
8. It then passes articles which match mutually agreed criteria on to
! neighbouring relaying and serving agents. However, it SHOULD NOT
forward articles to sites whose path-identity is already in the
***************
*** 4398,4402 ****
-
5. It SHOULD reject any article that matches an already received
! cancel message (or an equivalent, Supersedes-header) issued by its
poster or by some other trusted entity.
--- 4405,4408 ----
5. It SHOULD reject any article that matches an already received
! cancel message (or an equivalent Supersedes-header) issued by its
poster or by some other trusted entity.
***************
*** 4506,4508 ****
! It SHOULD be the case that articles will be received by the moderator
encapsulated as an object of Content-Type application/news-
--- 4513,4515 ----
! It should be the case that articles will be received by the moderator
encapsulated as an object of Content-Type application/news-
***************
*** 4829,4831 ****
used to request articles with a given message identifier, even one
! that is not supposed to be supplied to the requester.
--- 4835,4837 ----
used to request articles with a given message identifier, even one
! that is not supposed to be supplied to the requestor.
***************
*** 4945,4947 ****
! Reading agents should be chary of acting automatically upon Mime
objects with an "application" Content-Type that could change the
--- 4953,4955 ----
! Reading agents should be chary of acting automatically upon MIME
objects with an "application" Content-Type that could change the
***************
*** 5015,5022 ****
Single-Byte Coded Graphic Character Sets. Part 1: Latin
! alphabet No. 1, ISO 8859-1, 1987 Part 2: Latin alphabet No. 2,
! ISO 8859-2, 1987 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988
! Part 4: Latin alphabet No. 4, ISO 8859-4, 1988 Part 5:
! Latin/Cyrillic alphabet, ISO 8859-5, 1988 Part 6: Latin/Arabic
! alphabet, ISO 8859-6, 1987 Part 7: Latin/Greek alphabet, ISO
! 8859-7, 1987 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988
--- 5023,5030 ----
Single-Byte Coded Graphic Character Sets. Part 1: Latin
! alphabet No. 1, ISO 8859-1, 1987. Part 2: Latin alphabet No. 2,
! ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3,
! 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5:
! Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic
! alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO
! 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
***************
*** 5078,5080 ****
[RFC 2231] N. Freed and K. Moore, "MIME Parameter Value and Encoded
! Word Extensions: Character Sets, Languages, and COntinuations",
RFC 2231, November 1997.
--- 5086,5088 ----
[RFC 2231] N. Freed and K. Moore, "MIME Parameter Value and Encoded
! Word Extensions: Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
***************
*** 5087,5088 ****
--- 5095,5099 ----
+ [RFC 2279bis] F. Yergeau, "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, April 2002.
+
[RFC 2298] R. Fajman, "An Extensible Message Format for Message
***************
*** 5116,5120 ****
- [RFC 820] J. Postel and J. Vernon, "Assigned Numbers", RFC 820,
- January 1983.
-
[RFC 822] D. Crocker, "Standard for the Format of ARPA Internet Text
--- 5127,5128 ----
***************
*** 5138,5139 ****
--- 5146,5151 ----
+ [UNICODE 3.2] The Unicode Consortium, "The Unicode Standard - Version
+ 3.2, being an amendment to [UNICODE 3.1]", Unicode Standard
+ Annex #28 <http://www.unicode.org/unicode/reports/tr28>, 2002.
+
[USEFOR] This Standard.
***************
*** 5207,5212 ****
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Nov 2002).
-
-
Appendix A.1 - A-News Article Format
--- 5222,5225 ----
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Dec 2002).
Appendix A.1 - A-News Article Format
***************
*** 5285,5287 ****
In addition, this present standard obsoletes certain headers defined
! in [Son-of-1036] (see 6.22
--- 5297,5299 ----
In addition, this present standard obsoletes certain headers defined
! in [Son-of-1036] (see 6.22):
***************
*** 5306,5308 ****
This present standard obsoletes certain control messages defined in
! [RFC 1036] (see 7.5 all of which had the effect of requesting a
description of a relaying or serving agent's software, or its peering
--- 5318,5320 ----
This present standard obsoletes certain control messages defined in
! [RFC 1036] (see 7.5), all of which had the effect of requesting a
description of a relaying or serving agent's software, or its peering
***************
*** 5347,5349 ****
therein as "obsolete";
! 3 from [RFC 2373]
4 from [RFC 2234];
--- 5356,5358 ----
therein as "obsolete";
! 3 from [RFC 2373];
4 from [RFC 2234];
***************
*** 5357,5359 ****
%x61-7A ; a-z
! 2 CFWS = *([FWS] comment) (([FWS] comment) / FWS )
4 CR = %x0D ; carriage return
--- 5366,5368 ----
%x61-7A ; a-z
! 2 CFWS = *([FWS] comment) ( ([FWS] comment) / FWS )
4 CR = %x0D ; carriage return
***************
*** 5362,5364 ****
4 DQUOTE = %d34 ; quote mark
! 2 FWS = ([*WSP CRLF] 1*WSP); Folding whitespace
4 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
--- 5371,5373 ----
4 DQUOTE = %d34 ; quote mark
! 2 FWS = ([*WSP CRLF] 1*WSP); folding whitespace
4 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
***************
*** 5372,5374 ****
4 SP = %x20 ; space
! 4 WSP = SP / HTAB ; Whitespace characters
UTF8-xtra-2-head = %xC2-DF
--- 5381,5384 ----
4 SP = %x20 ; space
! 4 WSP = SP / HTAB ; whitespace characters
!
UTF8-xtra-2-head = %xC2-DF
***************
*** 5489,5495 ****
other-header = header-name ":" 1*SP other-content
! other-content
! = <the content of a header defined by some
other standard>
! other-parameter
! = <a parameter not defined by this standard>
5 parameter = attribute "=" value
--- 5498,5503 ----
other-header = header-name ":" 1*SP other-content
!
! other-content = <the content of a header defined by some
other standard>
! other-parameter = <a parameter not defined by this standard>
5 parameter = attribute "=" value
***************
*** 5672,5681 ****
combiner-extended = <any character with a Unicode code value of
! 0080 or greater and a combining class of 0,
! but excluding any character in Unicode
! categories Cc, Cf, Cs, Zs, Zl, and Zp>
combiner-mark = <any character with a Unicode code value of
! 0080 or greater and a combining class other
! than 0>
! component = 1*component-glyph
! component-glyph = combiner-base *combiner-mark
copy-addr = address-list
--- 5680,5687 ----
combiner-extended = <any character with a Unicode code value of
! 0080 or greater but excluding any character
! in Unicode categories Cc, Cf, Cs, M* and Z*>
combiner-mark = <any character with a Unicode code value of
! 0080 or greater and in Unicode category M*>
! component = 1*component-grapheme
! component-grapheme = combiner-base *combiner-mark
copy-addr = address-list
***************
*** 5690,5692 ****
"::" [ hexseq ]
! 3 hexseq = hex4 *( ":" hex4)
host-value = dot-atom /
--- 5696,5698 ----
"::" [ hexseq ]
! 3 hexseq = hex4 *( ":" hex4 )
host-value = dot-atom /
***************
*** 5723,5725 ****
*( strict-qtext / "\\" / "\" DQUOTE )
! DQUOTE
path-delimiter = "/" / "?" / "%" / "," / "!"
--- 5729,5731 ----
*( strict-qtext / "\\" / "\" DQUOTE )
! DQUOTE
path-delimiter = "/" / "?" / "%" / "," / "!"
***************
*** 5757,5759 ****
server-name = path-identity
! tail-entry = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
valid-group = newsgroups-line
--- 5763,5765 ----
server-name = path-identity
! tail-entry = path-identity
valid-group = newsgroups-line
-- 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@clw.cs.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