From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Thu Nov 21 2002 - 13:19:19 CST
While things are quiet, I have put together an internal draft
incorporating all the various minor things we have agreed since
draft.08. You will find it at
<http://www.landfield.com/usefor/draft-ietf-usefor-article-08.01.unpaged>.
The diffs are below.
Note that I have not yet incorporated the proposed revision of the text
introducing other-parameters (aka extension-parameters). You will find
both texts in this draft. We can decide which to use when we know the
result of the poll regarding MIME-style parameters.
*** landfield/drafts/draft-ietf-usefor-article-08.unpaged Wed Aug 14
17:38:30 2002
--- landfield/drafts/draft-ietf-usefor-article-08.01.unpaged Thu Nov 21
15:37:44 2002
***************
*** 2,9 ****
INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester
! August 2002
News Article Format
! <draft-ietf-usefor-article-08.txt>
Status of this Memo
--- 2,9 ----
INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester
! November 2002
News Article Format
! <draft-ietf-usefor-article-08.01.txt>
Status of this Memo
***************
*** 479,482 ****
--- 479,485 ----
entirely, for reasons of site policy).
+ Wherever the context permits, use of the masculine includes the
+ feminine and use of the singular includes the plural, and vice versa.
+
Throughout this standard we will give examples of various
definitions, headers and other specifications. It needs to be
***************
*** 529,534 ****
et seq, which are deemed to have been incorporated into this standard
as required. However, there are some important differences arising
! from the fact that [RFC 2822] does not recognize anything other than
! US-ASCII characters, that it does not recognize the MIME headers [RFC
2045], and that it includes much syntax described as "obsolete"
(which is excluded from this standard, as detailed below).
--- 534,539 ----
et seq, which are deemed to have been incorporated into this standard
as required. However, there are some important differences arising
! from the fact that [RFC 2822] does not recognize anything beyond US-
! ASCII characters, that it does not recognize the MIME headers [RFC
2045], and that it includes much syntax described as "obsolete"
(which is excluded from this standard, as detailed below).
***************
*** 964,967 ****
--- 974,1009 ----
structured headers wherever defined.
+
+ [alternative text, based on the use of "extension-parameters" instead of
+ "other-parameters".]
+
+ 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.
+
+ Extension-parameters MUST NOT be used unless they have first been
+ defined in an IETF-approved RFC (whether Informational, Experimental
+ or Standards-Track) or, on a provisional basis only, in relation to
+ new protocols under development which are the subject of (or intended
+ to be the subject of) some such IETF-approved RFC. They MUST ONLY be
+ defined for use in those headers where the syntax of this standard so
+ allows. They SHOULD NOT, at present, be defined for use in headers in
+ widespread use prior to the introduction of this standard (this
+ restriction is likely to be removed in a future version of this
+ standard). Nevertheless, compliant software MUST accept such
+ parameters wherever syntactically allowed in this standard (ignoring
+ them if their meaning is unknown) and SHOULD accept (and ignore) them
+ in all structured headers wherever defined.
+ [The wording about "provisional basis" is taken from the wording
+ relating to new headers in 4.2.1. Note that I have made NO provision for
+ parameters with x-tokens - do we want those?]
+ [We could go further, and establish an IANA registry for these
+ parameters, preloaded with the ones already defined in this standard. A
+ good model for setting up such a registry is to be found in RFC 2183
+ (Content-Disposition).]
+
NOTE: The syntax does not permit other-parameters in
unstructured headers (where they are unnecessary) or in certain
*** 1387,1396 ****
Where the use of non-ASCII characters is permitted as above, they MAY
! be encoded in UTF-8 and they MAY be encoded using the MIME mechanisms
! defined in [RFC 2047] and [RFC 2231], but only in those contexts
! explicitly mentioned in those documents (unstructured headers,
! phrases and comments in the one, quoted-strings within parameters in
! the other).
Encoding by other means is not compliant with this standard.
Nevertheless, encoding using other character sets (with no indication
--- 1429,1463 ----
Where the use of non-ASCII characters is permitted as above, they MAY
! be encoded in UTF-8 or they MAY be encoded using the MIME mechanisms
! defined in [RFC 2047] and [RFC 2231]. For this purpose, all headers
! defined in this standard are to be considered as "extension message
! header fields" for the purpose of section 5 of [RFC 2047] (insofar as
! they are not already covered under the existing Email standards). The
! effect of this is to permit the use of [RFC 2047] encodings within
! any unstructured header, or within any comment or phrase permitted
! within any structured header. Additionally, [RFC 2047] is
! considered to incorporate the extension to allow language tags within
! encoded-words described in [RFC 2231]. Likewise, the syntax for
! parameter (see 4.1 above) is to be considered as replaced by the
! revised syntax given in [RFC 2231], the effect of which is to allow
! the use of parameter value continuations, character sets and language
! information within the MIME-style parameters introduced in this
! standard (4.2.2).
! [We could go further and include that syntax explicitly in this
! document.]
+ Examples:
+ Organization: Technische =?iso-8859-1?Q?Universit=E4t_M=FCnchen?=
+ Approved: =?iso-8859-1?Q?Fran=E7ois_Faur=E9?= <ff@modsite.example>
+ (=?iso-8859-1?Q*fr?Mod=E9rateur_autoris=E9?=)
+ Archive: yes; filename*=iso-8859-1'es'ma=F1ana.txt
+
+ Reading agents MUST support the use of UTF-8, [RFC 2047] and [RFC
+ 2231] in all those headers defined in this standard and in the Email
+ standards, at least to the extent of their ability to display the
+ characters presented to them. Moreover, since Netnews articles are
+ regularly emailed as well as posted, Email user agents SHOULD do the
+ same in the case of the [RFC 2047] and [RFC 2231] encodings.
+
Encoding by other means is not compliant with this standard.
Nevertheless, encoding using other character sets (with no indication
***************
*** 1399,1406 ****
in some hierarchies, and such usage may be expected to continue for
some period after the introduction of this standard. Reading agents
! MUST support the use of UTF-8, [RFC 2047] and [RFC 2231] in headers
! and they MAY, when it is detected that none of these has been used,
! attempt to interpet the header according to whatever other character
! set can be deduced, or has been configued as a default by the reader.
NOTE: It is possible to determine, with a high degree of
--- 1466,1472 ----
in some hierarchies, and such usage may be expected to continue for
some period after the introduction of this standard. Reading agents
! MAY, when such usage is detected, attempt to interpet the header
! according to whatever other character set can be deduced, or has been
! configued as a default by the reader.
NOTE: It is possible to determine, with a high degree of
***************
*** 1410,1418 ****
harm could arise.
! Exceptionally, Newsgroups-headers (5.5) MUST use UTF-8 in order to
! ensure that they appear in their canonical form (in any case, a
! Newsgroups-header is not one of the acceptable contexts of [RFC
! 2047]). Certain exceptions to this rule are provided (8.7 and 8.8.1)
! for use when mailing to moderators and other gatewaying applications.
NOTE: The choice between UTF-8 and [RFC 2047] when posting
--- 1476,1486 ----
harm could arise.
! The [RFC 2047] encoding is not available within headers which contain
! a newsgroup-name, notably Newsgroups-headers and Followup-To-headers,
! because a newsgroup-name is neither a phrase nor a comment. Moreover
! such headers MUST in any case use UTF-8 in order to ensure that
! newsgroup-names appear in their canonical form. A special encoding
! for newsgroup-names is provided in section 5.5.2 for use when mailing
! to moderators and other gatewaying applications (8.7 and 8.8.1).
NOTE: The choice between UTF-8 and [RFC 2047] when posting
***************
*** 1436,1442 ****
the US-ASCII characters, though they MUST display at least those.
! NOTE: Observe that reading agents are not forbidden to "guess"
! when confronted with unannounced non-ASCII characters, and in
! particular it would be reasonable at least to test whether they
were in the form of valid UTF-8 (see also the suggestion for
such a test in 4.4.1).
--- 1505,1514 ----
the US-ASCII characters, though they MUST display at least those.
! NOTE: The use of non-ASCII characters in the absence of an
! appropriate Content-Type-header is not compliant with this
! standard. Nevertheless such usage has been seen in some
! hierarchies, and it would be reasonable for reading agents to
! make an informed "guess" when confronted with that situation,
! and in particular it would be wise at least to test whether they
were in the form of valid UTF-8 (see also the suggestion for
such a test in 4.4.1).
***************
*** 1709,1722 ****
msg-id includes the '<' and '>'.
An agent generating an article's message identifier MUST ensure that
it is unique (as also required in [RFC 2822]) and that it is chosen
! in such a way that it will NEVER recur in either Netnews or Email.
! Moreover, even though commonly derived from the domain name of the
! originating site (and domain names are case-insensitive), a message
! identifier MUST NOT be altered in any way during transport, or when
! copied (as into a References-header), and thus a simple (case-
! sensitive) comparison of octets will always suffice to recognize that
! same message identifier wherever it subsequently reappears.
NOTE: These requirements are to be contrasted with those of the
un-normalized msg-ids defined by [RFC 2822], which may perfectly
--- 1785,1806 ----
msg-id includes the '<' and '>'.
An agent generating an article's message identifier MUST ensure that
it is unique (as also required in [RFC 2822]) and that it is chosen
! in such a way that it will NEVER be applied to any other Netnews
! article or Email message. However, an article emailed (without
! encapsulation) to a moderator (8.2.2 and 8.7) or gatewayed into some
! other medium (8.8.1) SHOULD retain the same message identifier
! throughout its travels so long as it remains recognizably the same
! article.
+ Even though commonly derived from the domain name of the originating
+ site (and domain names are case-insensitive), a message identifier
+ MUST NOT be altered in any way during transport, or when copied (as
+ into a References-header), and thus a simple (case-sensitive)
+ comparison of octets will always suffice to recognize that same
+ message identifier wherever it subsequently reappears.
+
NOTE: These requirements are to be contrasted with those of the
un-normalized msg-ids defined by [RFC 2822], which may perfectly
***************
*** 1877,1881 ****
Newsgroup-names containing non-ASCII characters MUST be encoded in
! UTF-8 and not according to [RFC 2047].
Components beginning with underline ("_") are reserved for use by
--- 1962,1967 ----
Newsgroup-names containing non-ASCII characters MUST be encoded in
! UTF-8. The use of [RFC 2047] encoding is inappropriate for reasons
! explained in section 4.4.1.
Components beginning with underline ("_") are reserved for use by
***************
*** 2070,2075 ****
gatewaying it into Email (8.8.1), or when emailing it to a moderator
or constructing the submission address of the moderator (8.2.2), it
! may be necessary to encode any newsgroup-name within a Newsgroups- or
! Followup-To-header that contains any non-ASCII character. For that
purpose, the following algorithm is provided:
--- 2157,2163 ----
gatewaying it into Email (8.8.1), or when emailing it to a moderator
or constructing the submission address of the moderator (8.2.2), it
! will be necessary under the current email standards to encode any
! newsgroup-name that contains some non-ASCII character (such as one
! occurring within a Newsgroups- or Followup-To-header). For that
purpose, the following algorithm is provided:
***************
*** 2097,2108 ****
be decoded back into UTF-8.
- NOTE: Although the encoding defined by [RFC 2047] is available
- for use with other headers containing non-ASCII characters, the
- Newsgroups-header, being a structured header, is not one of the
- contexts permitted for its use (and moreover it would not
- produce a unique encoding nor cope well with newsgroup-names of
- excessive length). Therefore it SHOULD NOT be used within the
- Newsgroups-header.
-
5.6. Path
--- 2185,2188 ----
***************
*** 2406,2410 ****
appear in an article unless the sender is different from the poster.
This header is appropriate for use by automatic article posters. The
! content syntax makes use of syntax defined in [RFC 2822].
header =/ Sender-header
--- 2482,2487 ----
appear in an article unless the sender is different from the poster.
This header is appropriate for use by automatic article posters. The
! content syntax makes use of syntax defined in [RFC 2822], subject to
! the revised definition of local-part given in section 5.2.
header =/ Sender-header
***************
*** 2633,2641 ****
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, except that headers containing UTF8-xtra-
! chars in the posted version MAY be encoded according to [RFC 2047] or
! [RFC 2231], or (in the case of a Newsgroups-header) to section 5.5.2,
! in the emailed version. In particular, the Message-ID-headers MUST be
! identical. The bodies MUST be identical in both, apart from a
possible change of Content-Transfer-Encoding.
--- 2717,2725 ----
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, except that where they contain UTF8-xtra-
! chars which, in the mailed version, are encoded according to [RFC
! 2047] or [RFC 2231], or (in the case of headers containing a
! newsgroup-name) to section 5.5.2, they MAY, in the posted version,
! remain in UTF-8. The bodies MUST be identical in both, apart from a
possible change of Content-Transfer-Encoding.
***************
*** 2922,2926 ****
purposes and tracing of standards violations to specific software
needing correction. Although not one of the mandatory headers,
! posting agents SHOULD normally include it.
header =/ User-Agent-header
--- 3012,3017 ----
purposes and tracing of standards violations to specific software
needing correction. Although not one of the mandatory headers,
! posting agents SHOULD normally include it. It is also intended that
! this header be suitable for use in Email.
header =/ User-Agent-header
***************
*** 2927,2933 ****
User-Agent-header = "User-Agent" ":" SP User-Agent-content
*( ";" other-parameter )
! User-Agent-content = product-token *( CFWS product-token )
! product-token = value [ "/" product-version ] ; see 4.1
! product-version = value
This header MAY contain multiple product-tokens identifying the agent
--- 3018,3024 ----
User-Agent-header = "User-Agent" ":" SP User-Agent-content
*( ";" other-parameter )
! User-Agent-content = product *( CFWS product )
! product = [CFWS] token [CFWS] [ "/" product-version ]
! product-version = [CFWS] token [CFWS]
This header MAY contain multiple product-tokens identifying the agent
***************
*** 2941,2960 ****
themselves.
! NOTE: Variations from [RFC 2616] which describes a similar
facility for the HTTP protocol:
! 1. use of arbitrary text or octets from character sets other
! than US-ASCII in a product-token may require the use of a
! quoted-string,
! 2. "{" and "}" are allowed in a value (product-token and
! product-version) in Netnews,
- 3. UTF-8 replaces ISO-8859-1 as charset assumption.
-
NOTE: Comments should be restricted to information regarding the
! product named to their left such as platform information and
! should be concise. Use as an advertising medium (in the mundane
! sense) is discouraged.
6.18.1. Examples
--- 3032,3054 ----
themselves.
! NOTE: A product, being composed of a token, can contain only
! US-ASCII characters. Where the full name of an agent is
! expressed in a language requiring non-ASCII characters, it is
! suggested that an arbitrary (but easily recognizable) US_ASCII
! token be provided, followed by the full name in the form of a
! comment.
!
! NOTE: Minor variations from [RFC 2616] which describes a similar
facility for the HTTP protocol:
! 1. "{" and "}" are allowed in a token (product and product-
! version) in Netnews,
! 2. Comments are permitted wherever whitespace is allowed.
NOTE: Comments should be restricted to information regarding the
! product named to their left, such as its full name or platform
! information, and should be concise. Use as an advertising medium
! (in the mundane sense) is discouraged.
6.18.1. Examples
***************
*** 2974,2982 ****
experimental headers such as X-Newsreader, X-Mailer, X-Posting-
Agent, X-Http-User-Agent, and other headers previously used on
! Usenet for this purpose. Use of these experimental headers
! SHOULD be discontinued in favor of the single, standard User-
! Agent-header which can be used freely both in Netnews and Email
! (except that non-ASCII characters would be inappropriate in
! email).
6.19. Injector-Info
--- 3068,3074 ----
experimental headers such as X-Newsreader, X-Mailer, X-Posting-
Agent, X-Http-User-Agent, and other headers previously used on
! Usenet and in Email for this purpose. Use of these experimental
! headers SHOULD be discontinued in favor of the single, standard
! User-Agent-header.
6.19. Injector-Info
***************
*** 3208,3211 ****
--- 3302,3306 ----
Content-Disposition: [RFC 2183]
Content-Location: [RFC 2557]
+ Content-Language: [RFC 3282]
Content-MD5: [RFC 1864]
***************
*** 3230,3237 ****
6.21.2. Content-Type
! The Content-Type: "text/plain" is the default type for any news
! article, but the recommendations and limits on line lengths set out
! in section 4.5 Ought to be observed.
The acceptability of other subtypes of Content-Type: "text" (such as
"text/html") is a matter of policy (see 1.1), and posters Ought Not
--- 3325,3335 ----
6.21.2. Content-Type
! If the contents of an article is something other than plain text in
! the US-ASCII charset (these being the default assumptions), an
! appropriate Content-Type-header MUST be included.
+ When the Content-Type is "text/plain", the recommendations and limits
+ on line lengths set out in section 4.5 Ought to be observed.
+
The acceptability of other subtypes of Content-Type: "text" (such as
"text/html") is a matter of policy (see 1.1), and posters Ought Not
***************
*** 4206,4210 ****
The following section sets out the duties of various agents involved
! in the creation, relaying and serving of Usenet articles.
In this section, the word "trusted", as applied to the source of some
--- 4302,4310 ----
The following section sets out the duties of various agents involved
! in the creation, relaying and serving of Usenet articles. Insofar as
! these duties are described as sequences of steps to be followed, it
! should be understood that it is the effect of these sequences that is
! important, and implementations may use any method that gives rise to
! that same effect.
In this section, the word "trusted", as applied to the source of some
***************
*** 4237,4240 ****
--- 4337,4342 ----
amplified by the actions of thousands of hosts within a few minutes.
In the case of gateways, the primary corollary to this is:
***************
*** 4307,4317 ****
4. It MUST reject any article that does not have the correct
mandatory headers for a proto-article (5 and 8.2.1) present, or
! which contains any header that does not have legal contents. In
! particular, it MUST reject any article whose Newsgroups-header or
! Followup-To-header contains an encoded newsgroup-name (5.5.2);
! alternatively, it MAY decode those newsgroup-names and continue
! (this being a useful service for moderators using that injecting
! agent, see 8.7). It SHOULD reject any article which contains any
! header deprecated for Netnews (4.2.1).
5. If the article is rejected (for reasons given above, or for other
--- 4409,4419 ----
4. It MUST reject any article that does not have the correct
mandatory headers for a proto-article (5 and 8.2.1) present, or
! which contains any header that does not have syntactically legal
! contents. In particular, it MUST either reject any article whose
! Newsgroups-header or Followup-To-header contains an encoded
! newsgroup-name (5.5.2) or, alternatively, decode those newsgroup-
! names and continue (this being a useful service for moderators
! using that injecting agent, see 8.7). It SHOULD reject any
! article which contains any header deprecated for Netnews (4.2.1).
5. If the article is rejected (for reasons given above, or for other
***************
*** 4334,4342 ****
9 An Injector-Info-header (6.19) SHOULD be added, identifying the
trusted source of the article, and a suitable Complaints-To-header
! (6.20) MAY be added (except that these two headers SHOULD NOT be
added if the article is to be forwarded to a moderator).
10.The injecting agent MUST NOT alter the body of the article in any
way. It MAY add other headers not already provided by the poster,
--- 4436,4442 ----
9 An Injector-Info-header (6.19) SHOULD be added, identifying the
trusted source of the article, and a suitable Complaints-To-header
! (6.20) MAY be added (except that these two headers MUST NOT be
added if the article is to be forwarded to a moderator).
10.The injecting agent MUST NOT alter the body of the article in any
way. It MAY add other headers not already provided by the poster,
***************
*** 4380,4386 ****
being gatewayed into Email, the provisions of section 8.8.1
apply. In particular, if the headers contain any UTF8-xtra-
! chars, it may be necessary to apply encodings, specifically
! the encoding defined in section 5.5.2 in the case of the
! article's Newsgroups- and Followup-To-headers.
Although both of these methods have seen use in the past, the
--- 4482,4489 ----
being gatewayed into Email, the provisions of section 8.8.1
apply. In particular, if the headers contain any UTF8-xtra-
! chars, it will be necessary under the current email standards
! to apply encodings, including the encoding defined in section
! 5.5.2 in the case of the any header containing a newsgroup-
! name.
Although both of these methods have seen use in the past, the
***************
*** 4554,4557 ****
--- 4661,4671 ----
forwards them to further moderators.
+ Articles will be received by the moderator either encapsulated as an
+ object of Content-Type application/news-transmission (or possibly
+ encapsulated but without an explicit Content-Type-header), or else
+ directly as an email already containing all the headers appropriate
+ for a Netnews article (see 8.2.2). Moderators SHOULD be prepared to
+ accept articles in either format.
+
A moderator processes an article, as submitted to any newsgroup that
he moderates, as follows:
***************
*** 4563,4604 ****
the article if that is in accordance with the applicable
moderation policy (and in particular he MAY remove redundant
! headers and add Comments and other informational headers). He MAY
! inform the poster as to whether the article has been accepted or
! rejected.
! If the article is rejected, then it fails for all the newsgroups
! for which it was intended (in particular the moderator SHOULD NOT
! resubmit the article, with a reduced Newsgroups-header, to any
! remaining groups, especially if this will break any authentication
! checks present in the article). If the article is accepted, the
! moderator proceeds with the following steps.
! 2. The Date-header SHOULD be retained, except that if it is stale
(5.1) for reasons understood by the moderator (e.g. delays in the
moderation process) he MAY substitute the current date (but must
! then take responsibility for any loops that ensue). Any variant
! headers (4.2.5.3) MUST be removed, except that a Path-header MAY
! be truncated to only its pre-injection region (5.6.3). Any
! Injector-Info-header (6.19) or Complaints-To-header (6.20) MUST be
! removed.
! 3. He adds an Approved-header (6.14) containing a mailbox identifying
! himself (or, if the article already contains an Approved-header
! from another moderator, he adds that identifying information to
! it). He MAY also include that Approved-header within some digital
! signature scheme (see 7.1).
! 4. If the Newsgroups-header contains further moderated newsgroups for
! which approval has not already been given, he forwards the article
! to the moderator of the leftmost such group (which, if this
! standard has been followed correctly, will always be the group
! immediately to the right of the group(s) for which he is
! responsible). However, he MUST NOT alter the order in which the
! newsgroups are listed in the Newsgroups-header.
! 5. Otherwise, he causes the article to be injected, having first
! decoded any encoded newsgroup-name (5.5.2), unless his injecting
! agent offers that service (8.2.2), and having observed all the
! duties of a posting agent (8.5).
NOTE: This standard does not prescribe how the moderator or
--- 4677,4753 ----
the article if that is in accordance with the applicable
moderation policy (and in particular he MAY remove redundant
! headers and add Comments and other informational headers). He
! also needs to be aware if any change he makes to the article will
! invalidate some authentication check provided by the poster or by
! an earlier moderator.
! He MAY inform the poster if the article is accepted, and he Ought
! to inform the poster if it is rejected. If it is rejected, then
! it normally fails for all the newsgroups for which it was
! intended. If it is accepted, the moderator proceeds with the
! following steps.
! 2. If the Newsgroups-header contains further moderated newsgroups for
! which approval has not already been given, he adds an indication
! (identifying both himself and the name of the group) that he
! approves the article, and then forwards it to the moderator of the
! leftmost unapproved group (which, if this standard has been
! followed correctly, will generally be the next moderated group to
! the right of his own). There are two ways to do this:
!
! (a) He emails it to the submission address of the next moderator
! (see section 8.2.2 for the proper method of doing this), or
!
! (b) he rotates the the newsgroup-names in the Newsgroups-header
! to the left so that the targeted group is the leftmost
! moderated group in that header, and injects it as below (thus
! causing the injecting agent to email it to the correct
! moderator). However, he MUST first ensure that the article
! contains no Approved-header.
!
! NOTE: This standard does not prescribe how a moderator's
! approval is to be indicated (though a future standard may do
! so). Possible methods include adding an Approved header (or a
! similar but differently named header if method (b) is being
! used) listing all the approvals made so far, or adding a
! separate header for each individual approval (the header X-Auth
! is sometimes used for this purpose). The approval may also be
! confirmed with some form of digital signature (7.1).
!
! 3. If the Newsgroups-header contains no further unapproved moderated
! groups, he adds an Approved-header (6.14) identifying himself and,
! insofar as is possible, all the other moderators who have approved
! the article. He thus assumes responsibility for having ensured
! that the article was acceptable to the moderators of all the
! moderated groups involved.
!
! 4. A moderator Ought Not (absent any established and widely
! promulgated policy to the contrary) to remove any newsgroup-name
! from the Newsgroups-header, nor split an article into two versions
! with disjoint Newsgroups-headers. These are matters more usually
! within the prerogative of the poster; moreover splitting can lead
! to fragmentation of threads.
!
! 5. The Date-header SHOULD be retained, except that if it is stale
(5.1) for reasons understood by the moderator (e.g. delays in the
moderation process) he MAY substitute the current date (but must
! then take responsibility for any loops that ensue). The Message-
! ID-header SHOULD also be retained unless it is obviously non-
! compliant with this standard.
! NOTE: A message identifier created by a conforming posting or
! injecting agent, or even by a mail user agent conforming to [RFC
! 2822], may reasonably be supposed to be conformant (and will, in
! any case, be caught by the injecting agent if it is not).
! 6. Any variant headers (4.2.5.3) MUST be removed, except that a
! Path-header MAY be truncated to only its pre-injection region
! (5.6.3). Any Injector-Info-header (6.19) or Complaints-To-header
! (6.20) MUST be removed.
! 7. He then causes the article to be injected, having first decoded
! any encoded newsgroup-name (5.5.2), unless his injecting agent
! offers that service (8.2.2), and having observed all the duties of
! a posting agent.
NOTE: This standard does not prescribe how the moderator or
***************
*** 4608,4621 ****
arrangements in that regard.
- Articles will be received by the moderator either encapsulated as an
- object of Content-Type application/news-transmission (8.2.2) (or
- possibly encapsulated but without an explicit Content-Type-header),
- or else directly as an email already containing all the headers
- appropriate for a Netnews article (see 8.2.2) in which case he needs
- to be aware of the Duties of an Incoming Gateway (8.8.2) (and, in
- particular, he SHOULD adopt the Message-ID- and Date-headers of the
- email message, though he SHOULD NOT add any Sender-header).
- Moderators SHOULD be prepared to accept articles in either format.
-
8.8. Duties of a Gateway
--- 4757,4760 ----
***************
*** 4730,4741 ****
on.
o To ensure full compliance with the Email standards it is necessary
! to encode words containing UTF8-xtra-chars according to [RFC 2047]
! (but only where permitted by that standard, i.e. within phrases
! and unstructured headers, although many user agents will display
! this encoding correctly in other contexts also). Likewise, within
! parameters the proper encoding is that defined in [RFC 2231]. In
! both cases, it is preferable to encode using the charset UTF-8,
! although it might be wise first to confirm that that is indeed the
! charset which had been used (see 4.4.1).
o In the case of newsgroup-names, as found in Newsgroups-headers,
Followup-To-headers and some Control-headers, [RFC 2047] is not
--- 4867,4875 ----
on.
o To ensure full compliance with the Email standards it is necessary
! to encode unstructured headers, phrases, comments and parameters
! containing UTF8-xtra-chars according to [RFC 2047] or [RFC 2231],
! as set out in section 4.4.1. It is preferable to encode using the
! charset UTF-8, although it might be wise first to confirm that
! that is indeed the charset which had been used (see 4.4.1).
o In the case of newsgroup-names, as found in Newsgroups-headers,
Followup-To-headers and some Control-headers, [RFC 2047] is not
***************
*** 4747,4750 ****
--- 4881,4885 ----
such encoded newsgroup-names MUST be restored to their canonical
form before reinjection into any Netnews system.
+ [We need a paragraph on MIME-style parameters here]
In general, the following practices are recommended for all outgoing
***************
*** 5240,5243 ****
--- 5373,5379 ----
Security with OpenPGP", RFC 3156, August 2001.
+ [RFC 3282] H. Alvestrand, "Content Language Headers", RFC 3282, May
+ 2002.
+
[RFC 822] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages.", STD 11, RFC 822, August 1982.
***************
*** 5746,5750 ****
Supersedes-header = "Supersedes" ":" SP Supersedes-content
*( ";" other-parameter )
! User-Agent-content = product-token *( CFWS product-token )
User-Agent-header = "User-Agent" ":" SP User-Agent-content
*( ";" other-parameter )
--- 5887,5891 ----
Supersedes-header = "Supersedes" ":" SP Supersedes-content
*( ";" other-parameter )
! User-Agent-content = product *( CFWS product )
User-Agent-header = "User-Agent" ":" SP User-Agent-content
*( ";" other-parameter )
***************
*** 5864,5869 ****
= <a parameter with attribute "sender"
and value some sender-value>
! product-token = value [ "/" product-version ]
! product-version = value
pure-subject = unstructured
qspecial = "(" / ")" / ; same as specials except
--- 6005,6010 ----
= <a parameter with attribute "sender"
and value some sender-value>
! product = [CFWS] token [CFWS] [ "/" product-version ]
! product-version = [CFWS] token [CFWS]
pure-subject = unstructured
qspecial = "(" / ")" / ; same as specials except
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