Du bon usage de...

Son-of-RFC 1036
News Article Format and Transmission

5. Mandatory Headers

An article MUST have one, and only one, of each of the fol- lowing headers: Date, From, Message-ID, Subject, Newsgroups, Path.

NOTE: MAIL specifies (if read most carefully) that there must be exactly one Date header and exactly one From header, but otherwise does not restrict multiple appearances of headers. (Notably, it permits multiple Message-ID headers!) This appears singularly useless, or even harmful, in the context of news, and much current news soft- ware will not tolerate multiple appearances of mandatory headers.

Note also that there are situations, discussed in the rele- vant parts of section 6, where References, Sender, or Approved headers are mandatory.

In the discussions of the individual headers, the content of each is specified using the syntax notation. The convention used is that the content of, for example, the Subject header is defined as <Subject-content>.

5.1. Date

The Date header contains the date and time when the article was submitted for transmission:

     Date-content  = [ weekday "," space ] date space time
     weekday       = "Mon" / "Tue" / "Wed" / "Thu"
                   / "Fri" / "Sat" / "Sun"
     date          = day space month space year
     day           = 1*2digit
     month         = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun"
                   / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
     year          = 4digit / 2digit
     time          = hh ":" mm [ ":" ss ] space timezone
     timezone      = "UT" / "GMT"
                   / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
     hh            = 2digit
     mm            = 2digit
     ss            = 2digit
     zone-name     = 1*( <ASCII printable character except ()\> / space )

This is a restricted subset of the MAIL date format.

If a weekday is given, it MUST be consistent with the date. The modern Gregorian calendar is used, and dates MUST be consistent with its usual conventions; for example, if the month is May, the day must be between 1 and 31 inclusive. The year SHOULD be given as four digits, and posting agents SHOULD enforce this; however, relayers MUST accept the two- digit form, and MUST interpret it as having the implicit prefix "19".

NOTE: Two-digit year numbers can, should, and must be phased out by 1999.

The time is given on the 24-hour clock, e.g. two hours before midnight is "22:00" or "22:00:00". The hh must be between 00 and 23 inclusive, the mm between 0 and 59 inclu- sive, and the ss between 0 and 61 inclusive.

NOTE: Leap seconds very occasionally result in minutes that are 61 or 62 seconds long.

The date and time SHOULD be given in the poster's local timezone, including a specification of that timezone as a numeric offset (which SHOULD include the timezone name, e.g. "EST", supplied in parentheses like a MAIL comment). If not, they MUST be given in Universal Time (abbreviated "UT"; "GMT" is a historical synonym for "UT"). The timezone name in parentheses, if present, is a comment; software MUST ignore it, except that reading agents might wish to display it to the reader. Timezone names other than "UT" and "GMT" MUST appear only in the comment.

NOTE: Attempts to deal with a full set of timezone names have all foundered on the vast number of such names in use and the duplications (for exam- ple, there are at least FIVE different timezones called "EST" by somebody). Even the limited set of North American zone names authorized by MAIL is subject to confusion and misinterpretation. Hence the flat ban on non-UT timezone names except as comments.

NOTE: RFC 1036 specified that use of GMT (aka UT, UTC) was preferred. However, the local time (in the poster's timezone) is arguably information of possible interest to the reader, and this requires some indication of the poster's timezone. Numeric offsets are an unambiguous way of doing this, and their use was indeed sanctioned by RFC 1036 (that is, this is a change of preference only).

NOTE: There is frequent confusion, including errors in some news software, regarding the sign of numeric timezones. Zones west of Greenwich have negative offsets. For example, North Ameri- can Eastern Standard Time is zone -0500 and North American Eastern Daylight Time is zone -0400.

NOTE: Implementors are warned that the hh in a timezone can go up to about 14; it is not limited to 12. This is because the International Date Line does not run exactly along the boundary between zone -1200 and zone +1200.

NOTE: The comments in section 2.6 regarding trans- lation to other languages are relevant here. The Date-content format, and the spellings of its com- ponents, as found in articles themselves, are always as defined in this Draft, regardless of the language used to interact with readers and posters. Reading and posting agents should trans- late as appropriate. Actually, even English- language reading and posting agents will probably want to do some degree of translation on dates, if only to abbreviate the lengthy format and (perhaps) translate to and from the reader's time- zone.

5.2. From

The From header contains the electronic address, and possi- bly the full name, of the article's author:

     From-content  = address [ space "(" paren-phrase ")" ]
                   /  [ plain-phrase space ] "<" address ">"
     paren-phrase  = 1*( paren-char / space / encoded-word )
     paren-char    = <ASCII printable character except ()<>\>
     plain-phrase  = plain-word *( space plain-word )
     plain-word    = unquoted-word / quoted-word / encoded-word
     unquoted-word = 1*unquoted-char
     unquoted-char = <ASCII printable character except !()<>@,;:\".[]>
     quoted-word   = quote 1*( quoted-char / space ) quote
     quote         = <" (ASCII 34)>
     quoted-char   = <ASCII printable character except "()<>\>
     address       = local-part "@" domain
     local-part    = unquoted-word *( "." unquoted-word )
     domain        = unquoted-word *( "." unquoted-word )

(Encoded words are described in section 4.5.) The full name is distinguished from the electronic address either by enclosing the former in parentheses (making it resemble a MAIL comment, after the address) or by enclosing the latter in angle brackets. The second form is preferred. In the first form, encoded words inside the full name MUST be com- posed entirely of <paren-char>s. In the second form, encoded words inside the full name may not contain charac- ters other than letters (of either case), digits, and the characters "!", "*", "+", "-", "/", "=", and "_". The local part is case-sensitive (except that all case counterparts of "postmaster" are deemed equivalent), the domain is case- insensitive, and all other parts of the From content are comments which MUST be ignored by news software (except insofar as reading agents may wish to display them to the reader). Posters and posting agents MUST restrict them- selves to this subset of the MAIL From syntax; relayers MAY accept a broader subset, but see the discussion in section 9.1.

NOTE: The syntax here is a restricted subset of the MAIL From syntax, with quoting particularly restricted, for simple parsing. In particular, the presence of "<" in the From content indicates that the second form is being used, otherwise the first form is being used. The major restrictions here are those already de-facto imposed by exist- ing software.

NOTE: Overly-lenient posting agents sometimes per- mit the second form with a full name containing "(" or ")", but it is extremely rare for a full name to contain "<" or ">" even in mail. Accord- ingly, reading agents wishing to robustly deter- mine which form is in use in a particular article should key on the presence or absence of "<", not the presence or absence of "(".

The address SHOULD be a valid and complete Internet domain address, capable of being successfully mailed to by an Internet host (possibly via an MX record and a forwarder). The pseudo-domain ".uucp" MAY be used for hosts registered in the UUCP maps (e.g. name "xyz.uucp" for registered site "xyz"), but such hosts SHOULD discontinue this usage (either by arranging a proper Internet address and forwarder, or by using the "% hack" (see below)), as soon as possible. Bit- net hosts SHOULD use Internet addresses, avoiding the obso- lescent ".bitnet" pseudo-domain. Other forms of address MUST not be used.

NOTE: "Other forms" specifically include UK-style "backward" domains ("uk.oxbridge.cs" is in the Czech Republic, not the UK), pure-UUCP addressing ("knee!shin!foot" instead of "foot%shin@knee.uucp"), and abbreviated domains ("zebra.zoo" instead of "zebra.zoo.toronto.edu").

If it is necessary to use the local part to specify a rout- ing relative to the nearest Internet host, this MUST be done using the "% hack", using "%" as a secondary "@". For exam- ple, to specify that mail to the address should go to Inter- net host "foo.bar.edu", then to non-Internet host "ein", then to non-Internet host "deux", for delivery there to mailbox "fred", a suitable address would be:

     fred%deux%ein@foo.bar.edu

Analogous forms using "!" in the local part MUST not be used, as they are ambiguous; they should be expressed in the "%" form.

NOTE: "a!b@c" can be interpreted as either "b%c@a" or "b%a@c", and there is no consistency in which choice is made. Such addresses consequently are unreliable. The "%" form does not suffer from this problem, and although its use is officially discouraged, it is a de-facto standard, to the point that MAIL recognizes it.

Relayers MUST not, repeat MUST not, repeat MUST not, rewrite From lines, in any way, however minor or innocent-seeming. Trying to "fix" a non-conforming address has a very high probability of making things worse. Either pass it along unchanged, or reject the article.

NOTE: An additional reason for banning the use of "!" addressing is that it has a much higher proba- bility of being rewritten into mangled unrecogniz- ability by old relayers.

Posters and posting agents SHOULD avoid use of the charac- ters "!" and "@" in full names, as they may trigger unwanted header rewriting by old, simple-minded news software.

NOTE: Also, the characters "." and ",", not infre- quently found in names (e.g., "John W. Campbell, Jr."), are NOT, repeat NOT, allowed in an unquoted word. A From header like the following MUST not be written without the quotation marks:

          From: "John W. Campbell, Jr." <editor@analog.com>

5.3. Message-ID

The Message-ID header contains the article's message ID, a unique identifier distinguishing the article from every other article:

     Message-ID-content  = message-id
     message-id          = "<" local-part "@" domain ">"

As with From addresses, a message ID's local part is case- sensitive and its domain is case-insensitive. The "<" and ">" are parts of the message ID, not peculiarities of the Message-ID header.

NOTE: News message IDs are a restricted subset of MAIL message IDs. In particular, no existing news software copes properly with MAIL quoting conven- tions within the local part, so they are forbid- den. This is unfortunate, particularly for X.400 gateways that often wish to include characters which are not legal in unquoted message IDs, but it is impossible to fix net-wide. See the notes on gatewaying in section 10.

The domain in the message ID SHOULD be the full Internet domain name of the posting agent's host. Use of the ".uucp" pseudo-domain (for hosts registered in the UUCP maps) or the ".bitnet" pseudo-domain (for Bitnet hosts) is permissible, but SHOULD be avoided.

Posters and posting agents MUST generate the local part of a message ID using an algorithm which obeys the specified syn- tax (words separated by ".", with certain characters not permitted) (see section 5.2 for details), and will not repeat itself (ever). The algorithm SHOULD not generate message IDs which differ only in case of letters. Note the specification in section 6.5 of a recommended convention for indicating subject changes. Otherwise the algorithm is up to the implementor.

NOTE: The crucial use of message IDs is to distin- guish circulating articles from each other and from articles circulated recently. They are also potentially useful as permanent indexing keys, hence the requirement for permanent uniqueness... but indexers cannot absolutely rely on this because the earlier RFCs urged it but did not demand it. All major implementations have always generated permanently-unique message IDs by design, but in some cases this is sensitive to proper administration, and duplicates may have occurred by accident.

NOTE: The most popular method of generating local parts is to use the date and time, plus some way of distinguishing between simultaneous postings on the same host (e.g. a process number), and encode them in a suitably-restricted alphabet. An older but now less-popular alternative is to use a sequence number, incremented each time the host generates a new message ID; this is workable, but requires careful design to cope properly with simultaneous posting attempts, and is not as robust in the presence of crashes and other mal- functions.

NOTE: Some buggy news software considers message IDs completely case-insensitive, hence the advice to avoid relying on case distinctions. The restrictions placed on the "alphabet" of local parts and domains in section 5.2 have the useful side effect of making it unnecessary to parse mes- sage IDs in complex ways to break them into case- sensitive and case-insensitive portions.

The local part of a message ID MUST not be "postmaster" or any other string that would compare equal to "postmaster" in a case-insensitive comparison. Message IDs MUST be no longer than 250 octets, including the "<" and ">".

NOTE: "Postmaster" is an irksome exception to case-sensitivity in local parts, inherited from MAIL, and simply avoiding it is the best way to deal with it (not that it's likely, but the issue needs to be dealt with). The length limit is undesirable, but is present in widely-used exist- ing software. The limit is actually 255, but a small safety margin is wise.

5.4. Subject

The Subject header's content (the "subject" of the article) is a short phrase describing the topic of the article:

     Subject-content  = [ "Re: " ] nonblank-text

Encoded words MAY appear in this header.

If the article is a followup, the subject SHOULD begin with "Re: " (a "back reference"). If the article is not a fol- lowup, the subject MUST not begin with a back reference. Back references are case-insensitive, although "Re: " is the preferred form. A followup agent assisting a poster in preparing a followup SHOULD prepend a back reference, UNLESS the subject already begins with one. If the poster deter- mines that the topic of the followup differs significantly from what is described in the subject, a new, more descrip- tive, subject SHOULD be substituted (with no back refer- ence). An article whose subject begins with a back refer- ence MUST have a References header referencing the precur- sor.

NOTE: A back reference is FOUR characters, the fourth being a blank. RFC 1036 was confused about this. Observe also that only ONE back reference should be present.

NOTE: There is a semi-standard convention, often used, in which a subject change is flagged by mak- ing the new Subject-content of the form:

          new topic (was: old topic)

possibly with "old topic" somewhat truncated. Posters wishing to do something like this are urged to use this exact form, to simplify auto- mated analysis.

For historical reasons, the subject MUST not begin with "cmsg " (note that this sequence ends with a blank).

NOTE: Some old news software takes a subject beginning with "cmsg " as an indication that the article is a control message (see sections 6.6 and 7). This mechanism is obsolete and undesirable, but accidental triggering of it is still possible.

The subject SHOULD be terse. Posters SHOULD avoid trying to cram their entire article into the headers; even the sim- plest query usually benefits from a sentence or two of elaboration and context, and the details of header display vary widely among reading agents.

NOTE: All-in-the-subject articles are sometimes the result of misunderstandings over the interac- tion protocol of a posting agent. Posting agents might wish to give special attention to the possi- bility that a poster specifying a very long sub- ject might have thought he was typing the body of the article.

5.5. Newsgroups

The Newsgroups header's content specifies which newsgroup(s) the article is posted to:

     Newsgroups-content  = newsgroup-name *( ng-delim newsgroup-name )
     newsgroup-name      = plain-component *( "." component )
     component           = plain-component / encoded-word
     plain-component     = component-start *13component-rest
     component-start     = lowercase / digit
     lowercase           = <letter a-z>
     component-rest      = component-start / "+" / "-" / "_"
     ng-delim            = ","

Encoded words used in newsgroup names MUST not contain char- acters other than letters, digits, "+", "-", "/", "_", "=", and "?" (although they may encode them).

A newsgroup name consists of one or more components, which may be plain components or (except for the first) encoded words. A plain component MUST contain at least one letter, MUST begin with a letter or digit, and MUST not be longer than 14 characters. The first component MUST begin with a letter; subsequent components SHOULD begin with a letter. Newsgroup names MUST not contain uppercase letters, except where required by encodings in encoded words. The sequences "all" and "ctl" MUST not be used as components.

NOTE: The alphabet and syntax specified encom- passes all existing names of widespread news- groups, while avoiding various forms that are known to cause problems. Important existing soft- ware uses various non-alphanumeric characters as punctuation adjacent to newsgroup names. (It would, in fact, be preferable to ban "+" from newsgroup names, were it not that several widespread newsgroups related to the C++ program- ming language already use it.)

NOTE: Much existing software converts the news- group name into a directory path and stores the articles themselves using numeric filenames, so all-digit name components can be troublesome; the "Great Renaming" early in the history of Usenet included revisions of several newsgroup names to eliminate such components.

NOTE: The same storage technique is the reason for the 14-character limit. The limit is now largely historical, since most modern systems have much larger limits on the length of a directory entry's name, but many old systems are still in use. Sys- tems with shorter limits also exist, but news software on such systems has had to deal with the problem already, since there are several widespread newsgroups with 14-character components in their names. Implementors are warned that it is intended that the successor to this Draft will increase the 14-character limit, and are urged to fix their software to handle longer names grace- fully (if such fixes are necessary, given the intended domain of application of the particular software).

NOTE: The requirement that the first character of a name be a letter accommodates existing software which assumes it can tell the difference between a newsgroup name and other possible syntactic enti- ties by inspecting the first character. Similar considerations motivate excluding "+", "-", and "_" from coming first in a component, and the preference for components that do not begin with digits. The "all" sequence is used as a wildcard symbol in much existing software, and the "ctl" sequence was involved in an obsolete historical mechanism for marking control messages, so they are best avoided.

NOTE: Possibly newsgroup names should have been case-insensitive, but all existing software treats them as case-sensitive. (RFC 977 [rrr] claims that they are case-insensitive in NNTP, but exist- ing implementations are believed to ignore this.) The simplest solution is just to ban use of upper- case letters, since no widespread newsgroup name uses them anyway; this avoids any possibility of confusion.

NOTE: The syntax has the disadvantage of contain- ing no white space, making it impossible to con- tinue a Newsgroups header across several lines. Implementors of relayers and reading agents are warned that it is intended that the successor to this Draft will change the definition of ng-delim to:

          ng-delim = "," [ space ]

and are urged to fix their software to handle (i.e., ignore) white space following the commas. Meanwhile, posters must avoid inserting such space (despite the natural-language convention which permits it) and posting agents should strip it out.

NOTE: Encoded words as components are somewhat problematic, but are clearly desirable for use in non-English-speaking nations. They are not sub- ject to the 14-character limit, and this (plus the possibility of "/" within them) may require spe- cial handling in news software.

Encoded words are allowed in newsgroup names ONLY where non- ASCII characters are necessary to the name, and must use the "b" encoding [rrr] and the first suitable character set in the MIME order of preferred character sets [rrr].

NOTE: Since the newsgroup name is the encoded form, NOT the underlying non-ASCII form, there is room for terrible confusion here if the choice of encoding for a particular name is not fully stan- dardized.

Posters SHOULD use only the names of existing newsgroups in the Newsgroups header, because newsgroups are NOT created simply by being posted to. However, it is legitimate to cross-post to 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 agents MUST accept this (posting agents MAY accept it, but SHOULD at least alert the poster to the situation and request confirmation). Relayers MUST not rewrite Newsgroups headers in any way, even if some or all of the newsgroups do not exist on the relayer's host.

NOTE: Early experience with news software that created newsgroups when they were mentioned in a Newsgroups header was thoroughly negative: posters frequently mistype newsgroup names.

NOTE: While it is legitimate for some of an arti- cle's newsgroups not to exist on the host where it is posted, this IS a rather unusual situation except in followups (which should go to all news- groups the precursor was posted to, even if not all of them reach the site where the followup is being posted).

NOTE: Rewriting Newsgroups headers to strip locally-unknown newsgroups is superficially attractive. However, early experience with exactly that policy was thoroughly negative: news propagation is more redundant and much less orderly than many people imagine, and in particu- lar it is not unheard-of for the (sometimes) fastest path between two (say) U of Toronto sites to pass outside U of Toronto... in which case newsgroup stripping can cause incomplete propaga- tion. Having an article's set of newsgroups change as it propagates can also result in fol- lowups not achieving the same propagation as the original. It's been tried; it's more trouble than it's worth; don't do it.

NOTE: In particular, newsgroup stripping superfi- cially looks like a solution to the problem of duplicate regional newsgroup names. For example, both University of Toronto and University of Texas have "ut.general" newsgroups, and material cross- posted to that name and a global newsgroup appears in both universities' local newsgroups. However, the side effects of stripping are sufficiently unacceptable to disqualify it for this purpose. Don't do it.

Cross-posting an article to several relevant newsgroups is far superior to posting separate articles with duplicated content to each newsgroup, because reading agents can detect the situation and show the article to a reader only once. Posters SHOULD cross-post rather than duplicate-post.

NOTE: On the other hand, cross-posting to a large number of newsgroups usually indicates that the poster has not thought about his audience; arti- cles are rarely pertinent to more than (say) half a dozen newsgroups. Posting agents might wish to request confirmation when the number of newsgroups exceeds (say) five in the presence of a Followup- To header, or (say) two in the absence of such a header.

NOTE: One problem with cross-postings is what to do with an article cross-posted to a set of news- groups including both moderated and unmoderated ones. Posters tend to expect such an article to show up immediately in the unmoderated newsgroups, especially if they do not realize that one or more of the newsgroups is moderated. However, since it is not possible for a moderator to retroactively add an already-posted article to a moderated news- group, the only correct action is to mail such an article to one (and only one) of the moderators for action. It is probably best for the posting agent to detect this situation and ask the poster what action is preferred. The acceptable choices are to alter the newsgroup list or to mail to a moderator of the poster's choice; the posting agent should NOT offer duplicate-posting as an easy-to-request option (if only because many mod- erators will reject a submission that has already been posted to unmoderated newsgroups).

NOTE: An article cross-posted to multiple moder- ated newsgroups really should have approval from all the moderators involved. In practice, the only straightforward way to do this is to send the article to one of them and have him consult the others.

A newsgroup SHOULD not appear more than once in the News- groups header.

Newsgroup names having only one component are reserved for newsgroups whose propagation is restricted to a single host (or the administrative equivalent). It is inadvisable to name a newsgroup "poster" because that word has special meaning in the Followup-To header (see section 6.1). The names "control" and "junk" are frequently used for pseudo- newsgroups internal to relayer implementations, and hence are also best avoided.

NOTE: Beware of the duplicate-regional-newsgroup- names problem mentioned above. In particular, there are many, many hosts with a newsgroup named "general", and some surprising things show up in such newsgroups when people cross-post. It is probably better to use multi-component names, which are less likely to be duplicated. Fred's Widget House should use "fwh.general" rather than just "general" as its in-house general-topics newsgroup.

It is conventional to reserve newsgroup names beginning with "to." for test messages sent on an essentially point-to- point basis (see also the ihave/sendme protocol described in section 7.2); newsgroup names beginning with "to." SHOULD not be used for any other purpose. The second (and possibly later) components of such a name should, together, comprise the relayer name (see section 5.6) of a relayer. The news- group exists only at the named relayer and its neighbors. The neighbors all pass that newsgroup to the named relayer, while the named relayer does not pass it to anyone.

The order of newsgroup names in the Newsgroups header is not significant.

5.6. Path

The Path header's content indicates which relayers the arti- cle has already visited, so that unnecessary redundant transmission can be avoided:

     Path-content    = [ path-list path-delimiter ] local-part
     path-list       = relayer-name *( path-delimiter relayer-name )
     relayer-name    = 1*rn-char
     rn-char         = letter / digit / "." / "-" / "_"
     path-delimiter  = "!"

The Path content is a list of relayer names, separated by path delimiters, followed (after a final delimiter) by the local part of a mailing address. Each relayer MUST prepend its name, and a delimiter, to the Path content in all arti- cles it processes. A relayer MUST not pass an article to a neighboring relayer whose name is already mentioned in an article's path list, unless this is explicitly requested by the neighbor in some way. The Path content is case- sensitive.

NOTE: The Path header supplied by a posting agent should normally contain only the local part. The relayer that the posting agent passes the article to for posting will prepend its relayer name to get the path list started.

NOTE: Observe that the trailing local part is NOT part of the path list. This Path header:

          Path: fee!fie!foe!fum

contains three relayer names: "fee", "fie", and "foe". A relayer named "fum" is still eligible to be sent this article.

NOTE: This syntax has the disadvantage of contain- ing no white space, making it impossible to con- tinue a Path header across several lines. Imple- mentors of relayers and reading agents are warned that it is intended that the successor to this Draft will change the definition of path delimiter to:

          path-delimiter = "!" [ space ]

and are urged to fix their software to handle (i.e., ignore) white space following the exclama- tion points. They are urged to hurry; some ill- behaved systems reportedly already feel free to add such white space.

NOTE: RFC 1036 allows considerably more flexibil- ity in choice of delimiter, in theory, but this flexibility has never been used and most news software does not implement it properly. The grammar reflects the current reality. Note, in particular, that RFC 1036 treats "_" as a delim- iter, but in fact it is known to appear in relayer names occasionally.

Because an article will not propagate to a relayer already mentioned in its path list, the path list MUST not contain any names other than those of relayers the article has passed through AS NEWS. This is trivially obvious for nor- mal news articles, but requires attention from the modera- tors of moderated newsgroups and the implementors and main- tainers of gateways.

NOTE: For the same reason, a relayer and its neighbors need to agree on the choice of relayer name, and names should not be changed without notifying neighbors.

Relayer names need to be unique among all relayers which will ever see the articles using them. A relayer name is normally either an "official" name for the host the relayer runs on, or some other "official" name controlled by the same organization. Except in cooperating subnets that agree to some other convention, and don't let articles using it escape beyond the subnet, a relayer name MUST be either a UUCP name registered in the UUCP maps (without any domain suffix such as ".UUCP"), or a complete Internet domain name. Use of a (registered) UUCP name is recommended, where prac- tical, to keep the length of the path list down.

The use of Internet domain names in the path list presents one problem: domain names are case-insensitive, but the path list is case-sensitive. Relayers using domain names as their relayer names MUST pick a standard form for the name, and use that form consistently to the exclusion of all oth- ers. The preferred form for this purpose, which relayers SHOULD use, is the all-lowercase form.

NOTE: It is arguably unfortunate that the path list is case-sensitive, but it is much too late to change this. Most Internet sites do, in any event, use one standardized form of their name almost everywhere.

In the ordinary case, where the poster is the author of the article, the local part following the path list SHOULD be the local part of the poster's full Internet domain mailing address.

NOTE: It should be just the local part, not the full address. The character "@" does not appear in a Path header.

The Path content somewhat resembles a mailing address, par- ticularly in the UUCP world with its manual routing and "!" address syntax. Historically, this resemblance was impor- tant, and the Path content was often used as a reply address. This practice has always been somewhat unreliable, since news paths are not always mail paths and news relayer names are not always recognized by mail handlers, and its reliability has generally worsened in recent times. The widespread use of and recognition of Internet domain addresses, even outside the actual Internet, has largely eliminated the problem. Readers SHOULD not use the Path content as a reply address. On the other hand, relayer administrators are urged not to break this usage without good reason; where practical, paths followed by news SHOULD be traversable by mail, and mail handlers SHOULD recognize relayer names as host names.

It will typically be difficult or impractical for gateways and moderators to supply a Path content that is useful as a reply address for the author, bearing in mind that the path list they supply will normally be empty. (To reiterate: the path list MUST not contain any names other than those of relayers the article has passed through AS NEWS.) They SHOULD supply a local part that will result in replies to a Path-derived address being returned to the sender with a brief explanation. Software permitting, the local part "not-for-mail" is recommended.

NOTE: A moderator or gateway administrator who supplies a local part that delivers such mail to an administrative mailbox will quickly discover why it should be bounced automatically! It is best, however, for the returned message to include an explanation of what has probably happened, rather than just a mysterious "undeliverable mail" complaint, since the sender may not be aware that his/her software is unwisely using the Path con- tent as a reply address. Reply software might wish to question attempts to reply to a Path- derived address ending in "not-for-mail" (which is why a specific name is being recommended here).

6. Optional Headers

Many MAIL headers, and many of those specified in present and future MAIL extensions, are potentially applicable to news. Headers specific to MAIL's point-to-point transmis- sion paradigm, e.g. To and Cc, SHOULD not appear in news articles. (Gateways wishing to preserve such information for debugging probably SHOULD hide it under different names; prefixing "X-" to the original headers, resulting in e.g. "X-To", is suggested.)

The following optional headers are either specific to news or of particular note in news articles; an article MAY con- tain some or all of them. (Note that there are some circum- stances in which some of them are mandatory; these are explained under the individual headers.) An article MUST not contain two or more headers with any one of these header names.

NOTE: The ban on duplicate header names does not apply to headers not specified in this Draft at all, such as "X-" headers. Software should not assume that all header names in a given article are unique.

6.1. Followup-To

The Followup-To header contents specify which newsgroup(s) followups should be posted to:

     Followup-To-content = Newsgroups-content / "poster"

The syntax is the same as that of the Newsgroups content, with the exception that the magic word "poster" means that followups should be mailed to the article's reply address rather than posted. In the absence of Followup-To, the default newsgroup(s) for a followup are those in the News- groups header.

NOTE: The way to request that followups be mailed to a specific address other than that in the From line is to supply "Followup-To: poster" and a Reply-To header. Putting a mailing address in the Followup-To line is incorrect; posting agents should reject or rewrite such headers.

NOTE: There is no syntax for "no followups allowed" because "Followup-To: poster" accom- plishes this effect without extra machinery.

Although it is generally desirable to limit followups to the smallest reasonable set of newsgroups, especially when the precursor was cross-posted widely, posting agents SHOULD not supply a Followup-To header except at the poster's explicit request.

NOTE: In particular, it is incorrect for the post- ing agent to assume that followups to a cross- posted article should be directed to the first newsgroup only. Trimming the list of newsgroups should be the poster's decision, not the posting agent's. However, when an article is to be cross- posted to a considerable number of newsgroups, a posting agent might wish to SUGGEST to the poster that followups go to a shorter list.

6.2. Expires

The Expires header content specifies a date and time when the article is deemed to be no longer useful and should be removed ("expired"):

     Expires-content = Date-content

The content syntax is the same as that of the Date content. In the absence of Expires, the default is decided by the administrators of each host the article reaches, who MAY also restrict the extent to which the Expires header is hon- ored.

The Expires header has two main applications: removing arti- cles whose utility ends on a specific date (e.g., event announcements which can be removed once the day of the event is past) and preserving articles expected to be of prolonged usefulness (e.g., information aimed at new readers of a newsgroup). The latter application is sometimes abused. Since individual hosts have local policies for expiration of news (depending on available disk space, for instance), posters SHOULD not provide Expires headers for articles unless there is a natural expiration date associated with the topic. Posting agents MUST not provide a default Expires header. Leave it out and allow local policies to be used unless there is a good reason not to. Expiry dates are properly the decision of individual host administrators; posters and moderators SHOULD set only expiry dates that most administrators would agree with.

NOTE: A poster preparing an Expires header for an article whose utility ends on a specific day should typically specify the NEXT day as the expiry date. A meeting on July 7th remains of interest on the 7th.

6.3. Reply-To

The Reply-To header content specifies a reply address dif- ferent from the author's address given in the From header:

     Reply-To-content = From-content

In the absence of Reply-To, the reply address is the address in the From header.
Use of a Reply-To header is preferable to including a simi- lar request in the article body, because reply-preparation software can take account of Reply-To automatically.

6.4. Sender

The Sender header identifies the poster, in the event that this differs from the author identified in the From header:

     Sender-content = From-content

In the absence of Sender, the default poster is the author (named in the From header).

NOTE: The intent is that the Sender header have a fairly high probability of identifying the person who really posted the article. The ability to specify a From header naming someone other than the poster is useful but can be abused.

If the poster supplies a From header, the posting agent MUST ensure that a Sender header is present, unless it can verify that the mailing address in the From header is a valid mail- ing address for the poster. A poster-supplied Sender header MAY be used, if its mailing address is verifiably a valid mailing address for the poster; otherwise the posting agent MUST supply a Sender header and delete (or rename, e.g. to X-Unverifiable-Sender) any poster-supplied Sender header.

NOTE: It might be useful to preserve a poster- supplied Sender header so that the poster can sup- ply the full-name part of the content. The mail- ing address, however, must be right. Hence, the posting agent must generate the Sender header if it is unable to verify the mailing address of a poster-supplied one.

NOTE: NNTP implementors, in particular, are urged to note this requirement (which would eliminate the need for ad hoc headers like NNTP-Posting- Host), although there are admittedly some imple- mentation difficulties. A user name from an RFC 1413 server and a host name from an inverse map- ping of the address, perhaps with a "full name" comment noting the origin of the information, would be at least a first approximation:

          Sender: fred@zoo.toronto.edu (RFC-1413@reverse-lookup; not verified)

While this does not completely meet the specs, it comes a lot closer than not having a Sender header at all. Even just supplying a placeholder for the user name:

          Sender: somebody@zoo.toronto.edu (user name unknown)

would be better than nothing.

6.5. References

The References header content lists message IDs of precur- sors:

     References-content = message-id *( space message-id )

A followup MUST have a References header, and an article which is not a followup MUST not have a References header. In a followup, if the precursor had a References header, the message ID of the precursor is appended to the end of the precursor's References-content to form the followup's Refer- ences-content. a References header containing the precur- sor's message ID. A followup to an article which had a Ref- erences header MUST have a References header containing the precursor's References content, plus the precursor's message ID appended to the end of the list.

NOTE: Use the See-Also header (section 6.16) for interconnection of articles which are not in a followup relationship to each other.

NOTE: In retrospect, RFCs 850 and 1036, and the implementations whose practice they represented, erred here. The proper MAIL header to use for references to precursors is In-Reply-To, and the References header is meant to be used for the pur- poses here ascribed to See-Also. This incompati- bility is far too solidly established to be fixed, unfortunately. The best that can be done is to provide a clear mapping between the two, and urge gateways to do the transformation. The news usage is (now) a deliberate violation of the MAIL speci- fications; articles containing news References headers are technically not valid MAIL messages, although it is unlikely that much MAIL software will notice because the incompatibility is at a subtle semantic level that does not affect the syntax.

UNRESOLVED ISSUE: Would it be better to just give up and admit that news uses References for both purposes?

UNRESOLVED ISSUE: Should the syntax be generalized to include URLs as alternatives to message IDs? Perhaps not; too many things know about References already. And non-articles can't be precursors of articles, not really.

Followup agents SHOULD not shorten References headers. If it is absolutely necessary to shorten the header, as a des- perate last resort, a followup agent MAY do this by deleting some of the message IDs. However, it MUST not delete the first message ID, the last three message IDs (including that of the immediate precursor), or any message ID mentioned in the body of the followup. If it is possible for the fol- lowup agent to determine the Subject content of the articles identified in the References header, it MUST not delete the message ID of any article where the Subject content changed (other than by prepending of a back reference). The fol- lowup agent MUST not delete any message ID whose local part ends with "_-_" (underscore (ASCII 95), hyphen (ASCII 45), underscore); followup agents are urged to use this form to mark subject changes, and to avoid using it otherwise.

NOTE: As software capable of exploiting References chains has grown more common, the random shorten- ing permitted by RFC 1036 has become increasingly troublesome. ANY shortening is undesirable, and software should do it only in cases of dire neces- sity. In such cases, these rules attempt to limit the damage.

NOTE: The first message ID is very important as the starting point of the "thread" of discussion, and absolutely should not be deleted. Keeping the last three message IDs gives thread-following software a fighting chance to reconstruct a full thread even if an article or two is missing. Keeping message IDs mentioned in the body is obvi- ously desirable.

NOTE: Subject changes are difficult to determine, but they are significant as possible beginnings of new threads. The "_-_" convention is provided so that posting agents (which have more information about subjects) can flag articles containing a subject change in a way that followup agents can detect without access to the articles themselves. The sequence is chosen as one that is fairly unlikely to occur by accident.

NOTE: Is "_-_" really worth having?

When a References header is shortened, at least three blanks SHOULD be left between adjacent message IDs at each point where deletions were made. Software preparing new Refer- ences headers SHOULD preserve multiple blanks in older Ref- erences content.

NOTE: It's desirable to have some marker of where deletions occurred, but the restricted syntax of the header makes this difficult. Extra white space is not a very good marker, since it may be deleted by software that ill-advisedly rewrites headers, but at least it doesn't break existing software.

To repeat: followup agents SHOULD not shorten References headers.

NOTE: Unfortunately, reading agents and other software analyzing References patterns have to be prepared for the worst anyway. The worst includes random deletions and the possibility of circular References chains (when References is misused in place of See-Also, section 6.16).

6.6. Control

The Control header content marks the article as a control message, and specifies the desired actions (other than the usual ones of filing and passing on the article):

     Control-content  = verb *( space argument )
     verb             = 1*( letter / digit )
     argument         = 1*<ASCII printable character>

The verb indicates what action should be taken, and the argument(s) (if any) supply details. In some cases, the body of the article may also contain details. Section 7 describes the standard verbs. See also the Also-Control header (section 6.15).

NOTE: Control messages are often processed and filed rather differently than normal articles.

NOTE: The restriction of verbs to letters and dig- its is new, but is consistent with existing prac- tice and potentially simplifies implementation by avoiding characters significant to command inter- preters. Beware that the arguments are under no such restriction in general.

NOTE: Two other conventions for distinguishing control messages from normal articles were for- merly in use: a three-component newsgroup name ending in ".ctl" or a subject beginning with "cmsg " was considered to imply that the article was a control message. These conventions are obsolete. Do not use them.

An article with a Control header MUST not have an Also- Control or Supersedes header.

6.7. Distribution

The Distribution header content specifies geographic or organizational limits on an article's propagation:

     Distribution-content  = distribution *( dist-delim distribution )
     dist-delim            = ","
     distribution          = plain-component

A distribution is syntactically identical to a one-component newsgroup name, and must satisfy the same rules and restric- tions. In the absence of Distribution, the default distri- bution is "world".

NOTE: This syntax has the disadvantage of contain- ing no white space, making it impossible to con- tinue a Distribution header across several lines. Implementors of relayers and reading agents are warned that it is intended that the successor to this Draft will change the definition of dist delimiter to:

          dist-delim = "," [ space ]

and are urged to fix their software to handle (i.e., ignore) white space following the commas.

A relayer MUST not pass an article to another relayer unless configuration information specifies transmission to that other relayer of BOTH (a) at least one of the article's newsgroup(s), and (b) at least one of the article's distri- bution(s). In effect, the only role of distributions is to limit propagation, by preventing transmission of articles that would have been transmitted had the decision been based solely on newsgroups.

A posting agent might wish to present a menu of possible distributions, or suggest a default, but normally SHOULD not supply a default without giving the poster a chance to over- ride it. A followup agent SHOULD initially supply the same Distribution header as found in the precursor, although the poster MAY alter this if appropriate.

Despite the syntactic similarity and some historical confu- sion, distributions are NOT newsgroup names. The whole point of putting a distribution on an article is that it is DIFFERENT from the newsgroup(s). In general, a meaningful distribution corresponds to some sort of region of propaga- tion: a geographical area, an organization, or a cooperating subnet.

NOTE: Distributions have historically suffered from the completely uncontrolled nature of their name space, the lack of feedback to posters on incomplete propagation resulting from use of ran- dom trash in Distribution headers, and confusion with newsgroups (arising partly because many regions and organizations DO have internal news- groups with names resembling their internal dis- tributions). This has resulted in much garbage in Distribution headers, notably the pointless prac- tice of automatically supplying the first compo- nent of the newsgroup name as a distribution (which is MOST unlikely to restrict propagation!). Many sites have opted to maximize propagation of such ill-formed articles by essentially ignoring distributions. This unfortunately interferes with legitimate uses. The situation is bad enough that distributions must be considered largely useless except within cooperating subnets that make an organized effort to restrain propagation of their internal distributions.

NOTE: The distributions "world" and "local" have no standard magic meaning (except that the former is the default distribution if none is given). Some pieces of software do assign such meanings to them.

6.8. Keywords

The Keywords header content is one or more phrases intended to describe some aspect of the content of the article:

     Keywords-content = plain-phrase *( "," [ space ] plain-phrase )

Keywords, separated by commas, each follow the <plain- phrase> syntax defined in section 5.2. Encoded words in keywords MUST not contain characters other than letters (of either case), digits, and the characters "!", "*", "+", "-", "/", "=", and "_".

NOTE: Posters and posting agents are asked to take note that keywords are separated by commas, not by white space. The following Keywords header con- tains only one keyword (a rather unlikely and improbable one):

          Keywords: Thompson Ritchie Multics Linux

and should probably have been written:

          Keywords: Thompson, Ritchie, Multics, Linux

This particular error is unfortunately rather widespread.

NOTE: Reading agents and archivers preparing indexes of articles should bear in mind that user- chosen keywords are notoriously poor for indexing purposes unless the keywords are picked from a predefined set (which they are not in this case). Also, some followup agents unwisely propagate the Keywords header from the precursor into the fol- lowup by default. At least one news-based experi- ment has found the contents of Keywords headers to be completely valueless for indexing.

6.9. Summary

The Summary header content is a short phrase summarizing the article's content:

     Summary-content = nonblank-text

As with the subject, no restriction is placed on the content since it is intended solely for display to humans.

NOTE: Reading agents should be aware that the Sum- mary header is often used as a sort of secondary Subject header, and (if present) its contents should perhaps be displayed when the subject is displayed.

The summary SHOULD be terse. Posters SHOULD avoid trying to cram their entire article into the headers; even the sim- plest query usually benefits from a sentence or two of elab- oration and context, and not all reading agents display all headers.

6.10. Approved

The Approved header content indicates the mailing addresses (and possibly the full names) of the persons or entities approving the article for posting:

     Approved-content = From-content *( "," [ space ] From-content )

An Approved header is required in all postings to moderated newsgroups; the presence or absence of this header allows a posting agent to distinguish between articles posted by the moderator (which are normal articles to be posted normally) and attempted contributions by others (which should be mailed to the moderator for approval). An Approved header is also required in certain control messages, to reduce the probability of accidental posting of same; see the relevant parts of section 7.

NOTE: There is, at present, no way to authenticate Approved headers to ensure that the claimed approval really was bestowed. Nor is there an established mechanism for even maintaining a list of legitimate approvers (such a list would quickly become out of date if it had to be maintained by hand). Such mechanisms, presumably relying on cryptographic authentication, would be a worth- while extension to this Draft, and experimental work in this area is encouraged. (The problem is harder than it sounds because news is used on many systems which do not have real-time access to key servers.)

NOTE: Relayer implementors, please note well: it is the POSTING AGENT that is authorized to distin- guish between moderator postings and attempted contributions, and to mail the latter to the mod- erator. As discussed in section 9.1, relayers MUST not, repeat MUST not, send such mail; on receipt of an unApproved article in a moderated newsgroup, they should discard the article, NOT transform it into a mail message (except perhaps to a local administrator).

NOTE: RFC 1036 restricted Approved to a single From-content. However, multiple moderation is no longer rare, and multi-moderator Approved headers are already in use.

6.11. Lines

The Lines header content indicates the number of lines in the body of the article:

     Lines-content = 1*digit

The line count includes all body lines, including the signa- ture if any, including empty lines (if any) at beginning or end of the body. (The single empty separator line between the headers and the body is not part of the body.) The "body" here is the body as found in the posted article, AFTER all transformations such as MIME encodings.

Reading agents SHOULD not rely on the presence of this header, since it is optional (and some posting agents do not supply it). They MUST not rely on it being precise, since it frequently is not.

NOTE: The average line length in article bodies is surprisingly consistent at about 40 characters, and since the line count typically is used only for approximate judgements ("is this too long to read quickly?"), dividing the byte count of the body by 40 gives an estimate of the body line count that is adequate for normal use. This esti- mate is NOT adequate if the body has been MIME encoded... but neither is the Lines header, since at least one major relayer will supply a Lines header for an article that lacks one, and will not consider the possibility of MIME encodings when computing the line count.

NOTE: It would be better to have a Content-Size header as part of MIME, so that body parts could have their own sizes, and so that the units used could be appropriate to the data type (line count is not a useful measure of the size of an encoded image, for example). Doing this is preferable to trying to fix Lines.

UNRESOLVED ISSUE: Update on Content-Size?

Relayers SHOULD discard this header if they find it neces- sary to re-encode the article in such a way that the origi- nal Lines header would be rendered incorrect.

6.12. Xref

The Xref header content indicates where an article was filed by the last relayer to process it:

     Xref-content     = relayer 1*( space location )
     relayer          = relayer-name
     location         = newsgroup-name ":" article-locator
     article-locator  = 1*<ASCII printable character>

The relayer's name is included so that software can deter- mine which relayer generated the header (and specifically, whether it really was the one that filed the copy being examined). The locations specify what newsgroups the arti- cle was filed under (which may differ from those in the Newsgroups header) and where it was filed under them. The exact form of an article locator is implementation-specific.

NOTE: Reading agents can exploit this information to avoid presenting the same article to a reader several times. The information is sometimes available in system databases, but having it in the article is convenient. Relayers traditionally generate an Xref header only if the article is cross-posted, but this is not mandatory, and there is at least one new application ("mirroring": keeping news databases on two hosts identical) where the header is useful in all articles.

NOTE: The traditional form of an article locator is a decimal number, with articles in each news- group numbered consecutively starting from 1. NNTP [rrr] demands that such a model be provided, and there may be other software which expects it, but it seems desirable to permit flexibility for unorthodox implementations.

A relayer inserting an Xref header into an article MUST delete any previous Xref header. A relayer which is not inserting its own Xref header SHOULD delete any previous Xref header. A relayer MAY delete the Xref header when passing an article on to another relayer.

NOTE: RFC 1036 specified that the Xref header was not transmitted when an article was passed to another relayer, but the major news implementa- tions have never obeyed this rule, and applica- tions like mirroring depend on this disobedience.

A relayer MUST use the same name in Xref headers as it uses in Path headers. Reading agents MUST ignore an Xref header containing a relayer name that differs from the one that begins the path list.

6.13. Organization

The Organization header content is a short phrase identify- ing the poster's organization:

     Organization-content = nonblank-text

This header is typically supplied by the posting agent. The Organization content SHOULD mention geographical location (e.g. city and country) when it is not obvious from the organization's name.

NOTE: The motive here is that the organization is often difficult to guess from the mailing address, is not always supplied in a signature, and can help identify the poster to the reader.

NOTE: There is no "s" in "Organization".

The Organization content is provided for identification only, and does not imply that the poster speaks for the organization or that the article represents organization policy. Posting agents SHOULD permit the poster to override a local default Organization header.

6.14. Supersedes

The Supersedes header content specifies articles to be can- celled on arrival of this one:

     Supersedes-content = message-id *( space message-id )

Supersedes is equivalent to Also-Control (section 6.15) with an implicit verb of "cancel" (section 7.1).

NOTE: Supersedes is normally used where the arti- cle is an updated version of the one(s) being can- celled.

NOTE: Although the ability to use multiple message IDs in Supersedes is highly desirable (see section 7.1), posters are warned that existing implementa- tions often do not correctly handle more than one.

NOTE: There is no "c" in "Supersedes".

An article with a Supersedes header MUST not have an Also- Control or Control header.

6.15. Also-Control

The Also-Control header content marks the article as being a control message IN ADDITION to being a normal news article, and specifies the desired actions:

     Also-Control-content = Control-content

An article with an Also-Control header is filed and passed on normally, but the content of the Also-Control header is processed as if it were found in a Control header.

NOTE: It is sometimes desirable to piggyback con- trol actions on a normal article, so that the article will be filed normally but will also be acted on as a control message. This header is essentially a generalization of Supersedes.

NOTE: Be warned that some old relayers do not implement Also-Control.

An article with an Also-Control header MUST not have a Con- trol or Supersedes header.

6.16. See-Also

The See-Also header content lists message IDs of articles that are related to this one but are not its precursors:

     See-Also-content = message-id *( space message-id )

See-Also resembles References, but without the restrictions imposed on References by the followup rules.

NOTE: See-Also provides a way to group related articles, such as the parts of a single document that had to be split across multiple articles due to its size, or to cross-reference between paral- lel threads.

NOTE: See the discussion (in section 6.5) on MAIL compatibility issues of References and See-Also.

NOTE: In the specific case where it is desired to essentially make another article PART of the cur- rent one, e.g. for annotation of the other arti- cle, MIME's "message/external-body" convention can be used to do so without actual inclusion. "news- message-ID" was registered as a standard external- body access method, with a mandatory NAME parame- ter giving the message ID and an optional SITE parameter suggesting an NNTP site that might have the article available (if it is not available locally), by IANA 22 June 1993.

UNRESOLVED ISSUE: Could the syntax be generalized to include URLs as alternatives to message IDs? Here it makes much more sense than in References.

6.17. Article-Names

The Article-Names header content indicates any special sig- nificance the article may have in particular newsgroups:

     Article-Names-content  = 1*( name-clause space )
     name-clause            = newsgroup-name ":" article-name
     article-name           = letter 1*( letter / digit / "-" )

Each name clause specifies a newsgroup (which SHOULD be among those in the Newsgroups header) and an article name local to that newsgroup. Article names MAY be used by relayers to file the article in special ways, or they MAY just be noted for possible special attention by reading agents. Article names are case-sensitive.

NOTE: This header provides a way to mark special postings, such as introductions, frequently-asked- question lists, etc., so that reading agents have a way of finding them automatically. The news- group name is specified for each article name because the names may be newsgroup-specific; for example, many frequently-asked-question lists are posted to "news.answers" in addition to their "home" newsgroup, and they would not be known by the same name(s) in both newsgroups.

The Article-Names header SHOULD be ignored unless the arti- cle also contains an Approved header.

NOTE: This stipulation is made in anticipation of the possibility that Approved headers will be involved in cryptographic authentication.

The presence of an Article-Names header does not necessarily imply that the article will be retained unusually long before expiration, or that previous article(s) with similar Article-Names headers will be cancelled by its arrival. Posters preparing special postings SHOULD include appropri- ate other headers, such as Expires and Supersedes, to request such actions.

Different networks MAY establish different sets of article names for the special postings they deem significant; it is preferable for usage to be standardized within networks, although it might be desirable for individual newsgroups to have different naming conventions in some situations. Arti- cle names MUST be 14 characters or less. The following names are suggested but are not mandatory:

intro

Introduction to the newsgroup for newcomers.

charter

Charter, rules, organization, moderation poli- cies, etc.

background

Biographies of special participants, history of the newsgroup, notes on related newsgroups, etc.

subgroups

Descriptions of sub-newsgroups under this news- group, e.g. "sci.space.news" under "sci.space".

facts

Information relating to the purpose of the news- group, e.g. an acronym glossary in "sci.space".

references

Where to get more information: books, journals, FTP repositories, etc.

faq

Answers to frequently-asked questions.

menu

If present, a list of all the other article names local to this newsgroup, with brief descriptions of their contents.

Such articles may be divided into subsections using the MIME "multipart/mixed" conventions. If size considerations make it necessary to split such articles, names ending in a hyphen and a part number are suggested; for example, a three-part frequently-asked-questions list could have arti- cle names "faq-1", "faq-2", and "faq-3".

NOTE: It is somewhat premature to attempt to stan- dardize article names, since this is essentially a new feature with no experience behind it. How- ever, if reading agents are to attach special sig- nificance to these names, some attempt at standard conventions is imperative. This is a first attempt at providing some.

6.18. Article-Updates

The Article-Updates header content indicates what previous articles this one is deemed (by the poster) to update (i.e., replace):

     Article-Updates-content  = message-id *( space message-id )

Each message ID identifies a previous article that this one is deemed to update. This MUST not cause the previous arti- cle(s) to be cancelled or otherwise altered, unless this is implied by other headers (e.g. Supersedes); Article-Updates is merely an advisory which MAY be noted for special atten- tion by reading agents.

NOTE: This header provides a way to mark articles which are only minor updates of previous ones, containing no significant new information and not worth reading if the previous ones have been read.

NOTE: If suitable conventions using MIME multipart bodies and the "message/external-body" body-part type can be developed, a replacing article might contain only differences between the old text and the new text, rather than a complete new copy. This is the motivation for not making Article- Updates also function as Supersedes does: the replacing article might depend on the continued presence of the replaced article.