From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Mon May 12 2003 - 17:02:26 CDT
See http://www.landfield.com/usefor/drafts/useage_5.-1.00
http://www.landfield.com/usefor/drafts/section_5.10.01
Full diffs are below, and the whole useage text will be found as an attachment.
Note that the changes reported in the Syntactic Bits thread (notably
the move of the revised msg-id syntax to section 2.4.2) also show up in
these diffs.
The changes to Date, From and Path were pretty straightforward. Subject
and Newsgroups, however, need some explanation.
Subject:
--------
There has been some recent discussion about "Re: ". Note that even RFC
2822 makes a mention of it, as a thing that you MAY do when replying,
and suggesting that there should never be more than one "Re: " in a
Subject. However, Subject headers are not even required in an email
message. They are much more prominent in Netnews where Followups are a
prominent feature of the protocol. Therefore what we say should be at
least as strong as RFC 2822, and probably stronger.
Anyway, I have provided two texts for your consideration. One treats
"Re: " syntactically, and is essentially what is in the present
draft, apart from bits moved into USEAGE. The other is weaker, and
non-syntactic. However, it may still be too strong for some tastes (in
which case please speak up). You may even like to mix-and-match pieces
from the two texts. So can we have some discussion, please?
Here are the two texts, in full:
5.4. Subject
[Two texts are offered for your consideration. The first follows the
present draft closely, and includes an explicit syntax for the back-
reference "Re: ".]
The Subject-header contains a short string identifying the topic of
the message. This is an inheritable header (4.2.5.2), normally to be
copied into the Subject-header of any followup, in which case the new
Subject-content SHOULD then default to the string "Re: " (a "back-
reference") followed by the contents of the pure-subject of the
precursor. Any leading "Re: " in that pure-subject MUST be stripped.
header =/ Subject-header
Subject-header = "Subject" ":" SP Subject-content
Subject-content = [ [FWS] back-reference ] pure-subject
pure-subject = unstructured
back-reference = %x52.65.3A.20
; which is a case-sensitive "Re: "
The pure-subject MUST NOT begin with "Re: ".
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).
Followup agents MUST NOT use any other string except "Re: " as a
back-reference. Specifically, a translation of "Re: " into a local
language or usage MUST NOT be used.
NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
the matter of", and not an abbreviation of "Reference" as is
sometimes erroneously supposed.
[The alternative text is weaker, though correct usage of "Re " is still
a requirement.]
The Subject-header contains a short string identifying the topic of
the message. This is an inheritable header (4.2.5.2), normally to be
copied into the Subject-header of any followup.
header =/ Subject-header
Subject-header = "Subject" ":" SP Subject-content
Subject-content = unstructured
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).
Unless the poster has deliberately changed it, the Subject-content of
a followup consists of the back-reference "Re: " (which is case
sensitive) followed by the Subject-content of the precursor (unless
that precursor is itself a followup with "Re: " already present in
its Subject-content).
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.
NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
the matter of", and not an abbreviation of "Reference" as is
sometimes erroneously supposed. Reading agents often take note
of a single "Re: " at the beginning of a Subject-content (for
example, in order to display a list of articles sorted by
Subject). These restrictions ensure that reading agents have no
need to recognize more than a single occurrence of "Re: ".
Newsgroups
----------
The main issue here is what to do about the "policy restrictions" regarding
using only lowercase in newsgroup-names, all-digit components, length of
components, and so on. Note that, in the previous drafts, there were loads more
restrictions, all related to the UTF-8 newsgroup-names, and there was still some
baggage around from that in the present texts, and which I have now weeded out.
The approach I have taken now is to state that newsgroup-names are ultimately
determines by those responsible for creating new groups, but that some
restrictions are necessary. And I then give the three basic rules as a default,
or starting point, and then refer the read to USEAGE for a full discussion. So
their status in USEFOR is "advisory, but you better think twice before exceeding
them".
So here is the full text of the relevant part of the Newsgroup header:
The format of newsgroup-names is ultimately determined by the
policies of those administrative agencies which have the
responsibility for creating new newsgroups within the various
hierarchies of Usenet. There are traditional, social and technical
arguments why there should be restrictions on these formats (and the
force of the technical ones changes over time with developments in
computers and operating systems).
These issues are discussed more fully in [USEAGE]. The following
policy restrictions represent what is considered safe and appropriate
at the present time. Although purely advisory, hierarcy
administrators should consider the consequences carefully before
allowing them to be exceeded.
1. Uppercase letters are forbidden.
2. A component name is forbidden to consist entirely of digits.
3. A component is limited to 30 component-graphemes and a newsgroup-
name to 71 component-graphemes (counting also the '.'s separating
the components).
Serving and relaying agents MUST accept any syntactially correct
newsgroup-name even if it would violate one of more of these policy
restrictions. Posting and injecting agents MAY enforce them (but only
with the explicit agreement of the poster).
Again, discussion is welcomed.
Finally, here are the full diffs for section_5:
*** /tmp/d8oaihs Mon May 12 22:19:02 2003
--- landfield/drafts/section_5.10.01 Mon May 12 22:17:27 2003
***************
*** 17,21 ****
prepared by the poster ready for transmission and SHOULD express the
poster's local time. The content syntax makes use of syntax defined
! in [RFC 2822], subject to the following revised definition of zone.
header =/ Date-header
--- 17,22 ----
prepared by the poster ready for transmission and SHOULD express the
poster's local time. The content syntax makes use of syntax defined
! in [RFC 2822] (but see the revised definition of zone in section
! 2.4.2).
header =/ Date-header
***************
*** 22,42 ****
Date-header = "Date" ":" SP Date-content
Date-content = date-time
- zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
! The forms "UT" and "GMT" (indicating universal time) are to be
! regarded as obsolete synonyms for "+0000". They MUST be accepted, and
! passed on unchanged, by all agents, but they MUST NOT be generated as
! part of new articles by posting and injecting agents. The date-time
! MUST be semantically valid as required by [RFC 2822]. Although
! folding white space is permitted throughout the date-time syntax, it
! is RECOMMENDED that a single space be used in each place that FWS
! appears (whether it is required or optional).
- NOTE: A convention that is sometimes followed is to add a
- comment, after the date-time, containing the time zone in
- human-readable form, but many of the abbreviations commonly used
- for this purpose are ambiguous. The value given by the <zone> is
- the only definitive form.
-
In order to prevent the reinjection of expired articles into the news
stream, relaying and serving agents MUST refuse "stale" articles
--- 23,32 ----
Date-header = "Date" ":" SP Date-content
Date-content = date-time
! The date-time MUST be semantically valid as required by [RFC 2822].
! Although folding white space is permitted throughout the date-time
! syntax, it is RECOMMENDED that a single space be used in each place
! that FWS appears (whether it is required or optional).
In order to prevent the reinjection of expired articles into the news
stream, relaying and serving agents MUST refuse "stale" articles
***************
*** 55,60 ****
The From-header contains the email address(es), possibly including
! the full name(s), of the article's poster(s). The content syntax
! makes use of syntax defined in [RFC 2822].
header =/ From-header
From-header = "From" ":" SP From-content
--- 45,52 ----
The From-header contains the email address(es), possibly including
! the full name(s), of the article's poster(s), or of the person or
! agent on whose behalf the article is posted (see the Sender-header,
! 6.2). The content syntax makes use of syntax defined in [RFC 2822].
!
header =/ From-header
From-header = "From" ":" SP From-content
***************
*** 61,90 ****
From-content = mailbox-list
! 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
- to the poster(s) of the article, or person or agent on whose behalf
- the post is being sent (see the Sender-header, 6.2). When, for
- whatever reason, the poster does not wish to include such an address,
- the From-content SHOULD then be an address which ends in the top
- level domain of ".invalid" [RFC 2606].
-
- NOTE: Since such addresses ending in ".invalid" are
- undeliverable, user agents Ought to warn any user attempting to
- reply to them and Ought Not, in any case, to attempt to deliver
- to them (since that would be pointless anyway). Whether or not
- a valid address can subsequently be extracted from such an
- address falls outside the scope of this standard (obviously,
- posters wishing to disguise their address need to do more than
- just add ".invalid" to it).
-
- Be warned, however, that some injecting agents which are unable
- to detect that the address belongs to the poster may choose to
- insert a Sender-header (but see 8.2.2) or some entry in an
- Injector-Info-header (6.19) which discloses some valid address
- for the poster.
-
5.2.1. Examples:
--- 53,63 ----
From-content = mailbox-list
! NOTE: 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). When, for whatever reason,
! a poster does not wish to use a valid address, the mailbox
! concerned SHOULD end in the top level domain ".invalid" [RFC
! 2606].
5.2.1. Examples:
***************
*** 107,113 ****
The Message-ID-header contains the article's message identifier, a
unique identifier distinguishing the article from every other
! article. The content syntax makes use of syntax defined in [RFC
! 2822], subject to the following revised definitions of msg-id, no-
! fold-quote and no-fold-literal.
header =/ Message-ID-header
--- 80,85 ----
The Message-ID-header contains the article's message identifier, a
unique identifier distinguishing the article from every other
! 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).
header =/ Message-ID-header
***************
*** 114,155 ****
Message-ID-header = "Message-ID" ":" SP Message-ID-content
Message-ID-content = [FWS] msg-id [FWS]
- msg-id = "<" id-left "@" id-right ">"
- id-left = dot-atom-text / no-fold-quote
- id-right = dot-atom-text / no-fold-literal
- no-fold-quote = DQUOTE
- *( qtext / "\\" / "\" DQUOTE )
- qspecial
- *( qtext / "\\" / "\" DQUOTE )
- DQUOTE
- qspecial = "(" / ")" / ; same as specials except
- "<" / ">" / ; "\" and DQUOTE quoted
- "[" / "]" /
- ":" / ";" /
- "@" / "\\" /
- "," / "." /
- "\" DQUOTE
- no-fold-literal = "[" *( dtext / "\[" / "\]" / "\\" ) "]"
- [I think we need to ensure that '<' and '>' are excluded from id-left
- and id-right.]
The msg-id MUST NOT be more than 250 octets in length.
! NOTE: Observe that, in contrast to the corresponding header in
! [RFC 2822], the syntax does not allow comments within the
! Message-ID-header; this is to simplify processing by relaying
! and serving agents and to ensure interoperability with existing
! implementations.
!
! Msg-ids as defined here are a "normalized" subset of those
! defined by [RFC 2822], ensuring that no string of characters is
! quoted unless strictly necessary (it must contain at least one
! qspecial) and no single character is prefixed by a "\" in the
! form of a quoted-pair unless strictly necessary, and moreover
! there is no possibility for WSP to occur, whether quoted or not.
! The length restriction ensures that systems which accept message
! identifiers as a parameter when retrieving an article (e.g.
! [NNTP]) can rely on a bounded length. Observe that 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
--- 86,103 ----
Message-ID-header = "Message-ID" ":" SP Message-ID-content
Message-ID-content = [FWS] msg-id [FWS]
The msg-id MUST NOT be more than 250 octets in length.
! NOTE: The length restriction ensures that systems which accept
! message identifiers as a parameter when retrieving an article
! (e.g. [NNTP]) can rely on a bounded length. Observe that msg-id
includes the '<' and '>'.
+ Observe that, in contrast to the corresponding header in [RFC
+ 2822], the syntax does not allow comments within the Message-
+ ID-header; this is to simplify processing by relaying and
+ serving agents and to ensure interoperability with existing
+ implementations.
+
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
***************
*** 180,187 ****
5.4. Subject
The Subject-header contains a short string identifying the topic of
! the message. This is an inheritable header (4.2.5.2) to be copied
! into the Subject-header of any followup, in which case the new
! Subject-content SHOULD then default to the string "Re: " (a "back
reference") followed by the contents of the pure-subject of the
precursor. Any leading "Re: " in that pure-subject MUST be stripped.
--- 128,139 ----
5.4. Subject
+ [Two texts are offered for your consideration. The first follows the
+ present draft closely, and includes an explicit syntax for the back-
+ reference "Re: ".]
+
The Subject-header contains a short string identifying the topic of
! the message. This is an inheritable header (4.2.5.2), normally to be
! copied into the Subject-header of any followup, in which case the new
! Subject-content SHOULD then default to the string "Re: " (a "back-
reference") followed by the contents of the pure-subject of the
precursor. Any leading "Re: " in that pure-subject MUST be stripped.
***************
*** 201,215 ****
remarks in 4.2.6 concerning undesirable headers).
! Followup agents MAY remove strings that are known to be used
! erroneously as back-reference (such as "Re(2): ", "Re:", "RE: ", or
! "Sv: ") from the Subject-content when composing the subject of a
! followup, and add a correct back-reference in front of the result.
!
! NOTE: that would be "SHOULD remove instances" except that we
! cannot find a sufficiently robust and simple algorithm to do the
! necessary natural language processing.
!
! Followup agents MUST NOT use any other string except "Re: " as a back
! reference. Specifically, a translation of "Re: " into a local
language or usage MUST NOT be used.
--- 153,158 ----
remarks in 4.2.6 concerning undesirable headers).
! Followup agents MUST NOT use any other string except "Re: " as a
! back-reference. Specifically, a translation of "Re: " into a local
language or usage MUST NOT be used.
***************
*** 218,243 ****
sometimes erroneously supposed.
! 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
- In the following examples, please note that only "Re: " is mandated
- 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.
! Subject: Film at 11
! Subject: Re: Film at 11
! Subject: Godwin's law considered harmful (was: Film at 11)
! Subject: Godwin's law (was: Film at 11)
! Subject: Re: Godwin's law (was: Film at 11)
! Subject: Re: Godwin's law
5.5. Newsgroups
--- 161,200 ----
sometimes erroneously supposed.
! [The alternative text is weaker, though correct usage of "Re " is still
! a requirement.]
! The Subject-header contains a short string identifying the topic of
! the message. This is an inheritable header (4.2.5.2), normally to be
! copied into the Subject-header of any followup.
! header =/ Subject-header
! Subject-header = "Subject" ":" SP Subject-content
! Subject-content = unstructured
! 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).
+ Unless the poster has deliberately changed it, the Subject-content of
+ a followup consists of the back-reference "Re: " (which is case
+ sensitive) followed by the Subject-content of the precursor (unless
+ that precursor is itself a followup with "Re: " already present in
+ its Subject-content).
+
+ 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.
+
+ NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
+ the matter of", and not an abbreviation of "Reference" as is
+ sometimes erroneously supposed. Reading agents often take note
+ of a single "Re: " at the beginning of a Subject-content (for
+ example, in order to display a list of articles sorted by
+ Subject). These restrictions ensure that reading agents have no
+ need to recognize more than a single occurrence of "Re: ".
+
5.5. Newsgroups
***************
*** 262,265 ****
--- 219,227 ----
component-grapheme = DIGIT / ALPHA / "+" / "-" / "_"
+ NOTE: Observe that the syntax does not allow comments within the
+ Newsgroups-header; this is to simplify processing by relaying
+ and serving agents which have a requirement to process this
+ header extremely rapidly.
+
Components beginning with underline ("_") are reserved for use by
future versions of this standard and MUST NOT occur in newsgroup-
***************
*** 277,337 ****
a newsgroup-name.
! Agencies responsible for the administration of particular hierarchies
! MAY place additional restrictions on the newsgroup-names they allow
! within those hierarchies. Where there is no such specific policy, the
! following restrictions SHOULD be applied to newsgroup-names.
! NOTE: These restrictions are intended to reflect existing
! practice, with some additions to accommodate foreseeable
! enhancements, and are intended both to avoid certain technical
! difficulties and to avoid unnecessary confusion. It may well be
! that experience will allow future extensions to this standard to
! relax some or all of these restrictions.
! The specific restrictions (to be applied in the absence of
! established policies to the contrary) are:
- 1. Uppercase letters are forbidden. Traditionally, newsgroup-names
- have been written in lowercase. Posting agents Ought Not to
- convert uppercase characters to the corresponding lowercase forms
- except under the explicit instructions of the poster.
-
2. A component name is forbidden to consist entirely of digits.
- NOTE: This requirement was in [RFC 1036] but nevertheless
- several such groups have appeared in practice and implementors
- should be prepared for them. A common implementation technique
- uses each component as the name of a directory and uses numeric
- filenames for each article within a group. Such an
- implementation needs to be careful when this could cause a clash
- (e.g. between article 123 of group xxx.yyy and the directory for
- group xxx.yyy.123).
-
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.
! Serving and relaying agents MUST accept any newsgroup-name that meets
! the above requirements, even if it violates one or more of the policy
! restrictions. Posting and injecting agents MAY reject articles
! containing newsgroup-names that do not meet these restrictions, and
! posting agents MAY attempt to correct them (but only with the
! explicit agreement of the poster).
- Since future extensions to this standard plus any relaxations of the
- default restrictions introduced by specific hierarchies might
- invalidate some such checks, warnings, and adjustments,
- implementations MUST incorporate means to disable them.
-
- NOTE: Observe that the syntax does not allow comments within the
- Newsgroups-header; this is to simplify processing by relaying and
- serving agents which have a requirement to process this header
- extremely rapidly.
-
The inclusion of folding white space within a Newsgroups-content is a
newly introduced feature in this standard. It MUST be accepted by all
--- 241,271 ----
a newsgroup-name.
! The format of newsgroup-names is ultimately determined by the
! policies of those administrative agencies which have the
! responsibility for creating new newsgroups within the various
! hierarchies of Usenet. There are traditional, social and technical
! arguments why there should be restrictions on these formats (and the
! force of the technical ones changes over time with developments in
! computers and operating systems).
! These issues are discussed more fully in [USEAGE]. The following
! policy restrictions represent what is considered safe and appropriate
! at the present time. Although purely advisory, hierarcy
! administrators should consider the consequences carefully before
! allowing them to be exceeded.
! 1. Uppercase letters are forbidden.
2. A component name is forbidden to consist entirely of digits.
3. A component is limited to 30 component-graphemes and a newsgroup-
name to 71 component-graphemes (counting also the '.'s separating
! the components).
! Serving and relaying agents MUST accept any syntactially correct
! newsgroup-name even if it would violate one of more of these policy
! restrictions. Posting and injecting agents MAY enforce them (but only
! with the explicit agreement of the poster).
The inclusion of folding white space within a Newsgroups-content is a
newly introduced feature in this standard. It MUST be accepted by all
***************
*** 342,350 ****
agents SHOULD generate such whitespace in the form of <CRLF WSP> so
as to keep the length of lines in the relevant headers (notably
! Newsgroups and Followup-To) to no more than than 79 characters (or
! other agreed policy limit - see 4.5). Before such critical mass
! occurs, injecting agents MAY reformat such headers by removing
! whitespace inserted by the posting agent, but relaying agents MUST
! NOT do so.
Posters SHOULD use only the names of existing newsgroups in the
--- 276,284 ----
agents SHOULD generate such whitespace in the form of <CRLF WSP> so
as to keep the length of lines in the relevant headers (notably
! Newsgroups and Followup-To) to a reasonable length (such as 79
! characters, which is likely to be displayed satisfactorily by most
! current reading agents). Before such critical mass occurs, injecting
! agents MAY reformat such headers by removing whitespace inserted by
! the posting agent, but relaying agents MUST NOT do so.
Posters SHOULD use only the names of existing newsgroups in the
***************
*** 351,362 ****
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
! agents SHOULD accept this (posting agents MAY accept it, but Ought at
! least to alert the poster to the situation and request confirmation).
! Relaying agents MUST NOT rewrite Newsgroups-headers in any way, even
! if some or all of the newsgroups do not exist on the relaying agent's
! host. Serving agents MUST NOT create new newsgroups simply because an
! unrecognized newsgroup-name occurs in a Newsgroups-header (see 7.2.1
! for the correct method of newsgroup creation).
The Newsgroups-header is intended for use in Netnews articles rather
--- 285,294 ----
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. Relaying agents
! MUST NOT rewrite Newsgroups-headers in any way, even if some or all
! of the newsgroups do not exist on the relaying agent's host. Serving
! agents MUST NOT create new newsgroups simply because an unrecognized
! newsgroup-name occurs in a Newsgroups-header (see 7.2.1 for the
! correct method of newsgroup creation).
The Newsgroups-header is intended for use in Netnews articles rather
***************
*** 583,608 ****
5.6.5. Suggested Verification Methods
! It is preferable to verify the claimed path-identity against the
! source than to make routine use of the '?' path-delimiter, with
! consequential wasteful double-entry Path additions.
- If the incoming article arrives through some TCP/IP protocol such as
- NNTP, the IP address of the source will be known, and will likely
- already have been checked against a list of known FQDNs, IP
- addresses, or other registered aliases that the receiving site has
- agreed to peer with.
- Since the source host may have several IP addresses, checking the
- claimed FQDN or IP address against the source IP, or finding a
- suitable FQDN to report with a '?' path-delimiter, may involve
- several DNS lookups, following CNAME chains as required. Note that
- any reverse DNS lookup that is involved needs to be confirmed by a
- forward one.
- If the incoming article arrives through some other protocol, such as
- UUCP, that protocol MUST include a means of verifying the source
- site. In UUCP implementations, commonly each incoming connection has
- a unique login name and password, and that login name (or some alias
- registered for it) would be expected as the path-identity.
5.6.6. Example
--- 516,523 ----
5.6.5. Suggested Verification Methods
! [Section now omitted.]
5.6.6. Example
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
5. Mandatory Headers
5.1. Date
NOTE: A convention that is sometimes followed is to add a
comment, after the date-time, containing the time zone in
human-readable form, but many of the abbreviations commonly used
for this purpose are ambiguous. The value given by the <zone> is
the only definitive form.
5.1.1. Examples
5.2. From
Each mailbox in the From-content SHOULD be a valid address, belonging
to the poster(s) of the article, or the person or agent on whose
behalf the article is posted. When, for whatever reason, a poster
does not wish ro use a valid address, the mailbox concerned SHOULD,
to comply with [USEFOR], end in the top level domain ".invalid" [RFC
2606].
NOTE: Since such addresses ending in ".invalid" are
undeliverable, user agents Ought to warn any user attempting to
reply to them and Ought Not, in any case, to attempt to deliver
to them (since that would be pointless anyway). Whether or not
a valid address can subsequently be extracted from such an
address falls outside the scope of this document (obviously,
posters wishing to disguise their address need to do more than
just add ".invalid" to it).
Be warned, however, that some injecting agents which are unable
to detect that a mailbox belongs to the poster may choose to
insert a Sender-header or some entry in an Injector-Info-header
which discloses some valid address for the poster.
5.2.1. Examples:
5.3. Message-ID
[This might be a good place to discuss sensible means of generating
message identifiers to satisfy the "NEVER" requirement. Recall that we
have a draft on www.landfield.com/usefor that was written in the early
days of Usefor.]
5.4. Subject
Followup agents MAY remove strings that are known to be used
erroneously as back-references (such as "Re(2): ", "Re:", "RE: ", or
"Sv: ") from the Subject-content when composing the subject of a
followup, and add a correct back-reference in front of the result.
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.
[Is that MUST NOT a little too strong nowadays? Do there really still
exist servers or other agents that will recognize and act upon "cmsg" in
a Subject-header? And if so, maybe that MUST NOT should be moved back
into [USEFOR].]
5.4.1. Examples
In the following examples, please note that only "Re: " is mandated
by [USEFOR]. "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.
Subject: Film at 11
Subject: Re: Film at 11
Subject: Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law
5.5. Newsgroups
Agencies responsible for the administration of particular hierarchies
SHOULD place restrictions on the newsgroup-names they allow within
those hierarchies. [USEFOR] provides the following default
restrictions upon which hierarchy administrators can build, and which
SHOULD otherwise be applied in hierarchies not subject to such
management.
NOTE: These restrictions are intended to reflect existing
practice and are intended both to avoid certain technical
difficulties and to avoid unnecessary confusion. They may well
change over time in the light of future experience.
1. Uppercase letters are forbidden.
NOTE: Traditionally, newsgroup-names have been written in
lowercase. However, posting agents Ought Not to convert
uppercase characters to the corresponding lowercase forms except
under the explicit instructions of the poster.
2. A component name is forbidden to consist entirely of digits.
NOTE: This requirement was in [RFC 1036] but nevertheless
several such groups have appeared in practice and implementors
should be prepared for them. A common implementation technique
uses each component as the name of a directory and uses numeric
filenames for each article within a group. Such an
implementation needs to be careful when this could cause a clash
(e.g. between article 123 of group xxx.yyy and the directory for
group xxx.yyy.123).
3. A component is limited to 30 component-graphemes and a newsgroup-
name to 71 component-graphemes (counting also the '.'s separating
the components).
NOTE: 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 where an overall
policy limit applies and, moreover, excessively long names can
be exceedingly inconvenient in practical use.
Nevertheless, [USEFOR] requires serving and relaying agents to accept
any syntactially correct newsgroup-name, even if it would violate one
or more of these policy restrictions. Posting and injecting agents
MAY attempt to enforce them but, because of the possibility that
hierarchy policies or future standards may relax them, it SHOULD be
possible for posters to override such checks, and software MUST be so
written that they can be disabled altogether.
[But here we should add that hierarchy administrators need to go much
further that these three rules. They need to ensure that newsgroup-names
make good sense in the languages used in their hierarchies, that
frivolous names are avoided, and that sensible hierarchical principles
are applies (David Wright has a FAQ on hierarchical naming which might
give us some help). Moreover, we should mention the possibililty that
there will in future be internationalized newsgroup-names, in which case
there are lots more issues to consider in order to avoid unsuitable
characters (see draft-ietf-usefor-article-08.txt for some of these).]
Posting agents MAY, and followup agents SHOULD, accept articles
crossposted to newsgroups which do not exist on their local hosts,
though posting agents Ought at least to alert the poster to the
situation and request confirmation.
5.5.1. Forbidden newsgroup-names
5.6. Path
5.6.1. Format
5.6.2. Adding a path-identity to the Path-header
5.6.3. The tail-entry
5.6.4. Path-Delimiter Summary
5.6.5. Suggested Verification Methods
It is preferable to verify the claimed path-identity against the
source than to make routine use of the '?' path-delimiter, with
consequential wasteful double-entry Path additions.
If the incoming article arrives through some TCP/IP protocol such as
NNTP, the IP address of the source will be known, and will likely
already have been checked against a list of known FQDNs, IP
addresses, or other registered aliases that the receiving site has
agreed to peer with.
Since the source host may have several IP addresses, checking the
claimed FQDN or IP address against the source IP, or finding a
suitable FQDN to report with a '?' path-delimiter, may involve
several DNS lookups, following CNAME chains as required. Note that
any reverse DNS lookup that is involved needs to be confirmed by a
forward one.
If the incoming article arrives through some other protocol, such as
UUCP, that protocol MUST include a means of verifying the source
site. In UUCP implementations, commonly each incoming connection has
a unique login name and password, and that login name (or some alias
registered for it) would be expected as the path-identity.
[RFC 1036] M. Horton and R. Adams, "Standard for Interchange of
USENET Messages", RFC 1036, December 1987.
[RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names",
RFC 2606, June 1999.
[USEFOR] Charles H. Lindsey, "News Article Format", draft-ietf-
usefor-article-format-*.txt.