Oughtification of Section 5

New Message Reply About this list Date view Thread view Subject view Author view

From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Jan 09 2001 - 13:55:52 CST


Here are the affected pieces. There were only two places where I thought
there should be an Ought, though I have also drawn attention to a few
SHOULDs that some poeple might want to change (I don't). There are also
a couple of other changes that you need to look at.

5. Mandatory Headers

5.2. From

   Any mailbox in the From-content MUST belong to one of the poster(s)
   of the article, or be a mailbox which he is authorized by its owner
   to use, or be an address which ends in the top level domain of
   ".invalid" [RFC 2606].
[Alternative Dave Barr wording:
The 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 Sender). When, for political or other reasons
the poster wishes to indicate that the address is not a valid email
address, the From-content SHOULD be an address which ends in the top
level domain of ".invalid" [RFC 2606].
NOTE: The use of ".invalid" is to provide an aid to mail systems so that
addresses deliberately intended to be malformed can be identified and
delivery aborted. User agents MUST identify such addresses and require
the user to alter the address when attempting a personal email reply.
Injecting agents that have authentication information MAY choose to
enforce the From-content based on the poster's authenticated identity.
]
[Y1 it is my intention to adopt that wording.]

5.4. Subject

   The Subject header contains a short string identifying the topic of
   the message. This is an inheritable header (4.2.2.2) to be copied
   into the Subject header of any followup, in which case the new
   header-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 the pure-subject MUST be stripped.
[Y2 I hope nobody want to put any Oughts in there.]

5.5. Newsgroups

   The Newsgroups header's content specifies which newsgroup(s) the
   article is posted to. It is an inheritable header (4.2.2.2) which
   SHOULD then become the default Newsgroups header of any followup,
   unless a Followup-To header is present to prescribe otherwise.
[Y3 I hope nobody want to put any Oughts in there.]

   The inclusion of folding white space within a Newsgroups-content is a
   newly introduced feature in this standard. It MUST be accepted by all
   conforming implementations (relaying agents, serving agents and
   reading agents). Posting agents should be aware that such postings
   may be rejected by overly-critical old-style relaying agents. When a
   sufficient number of relaying agents are in conformance, posting
   agents SHOULD generate such whitespace in the form of <CRLF WS> 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.
[Y4 I hope nobody want to put any Oughts in there.]

   Whilst there is no longer any technical reason to limit the length of
   a component (formerly, it was limited to 14 characters) nor to limit
   the total length of a newsgroup-name, it should be noted that these
   names are also used in the newsgroups line (7.1.2) where an overall
   policy limit applies, and moreover excessively long names can be
   exceedingly inconvenient in practical use. Agencies responsible for
   individual hierarchies Ought therefore, as a matter of policy, to set
   reasonable limits for the length of a component and of a newsgroup-
   name. In the absence of such explicit policies, the default limits
   are 30 characters and 71 characters respectively.
[Y5 Ought was SHOULD]
[If the checkpolicies proposal is included in the Standard, there should
be a reference to it here.]

   Posters SHOULD use only the names of existing newsgroups in the
   Newsgroups header. 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 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
   unrecognised newsgroup-name occurs in a Newsgroups header (see 7.1
   for the correct method of newsgroup creation).
[Y6 Ought was SHOULD. I hope nobody wants to change any of the other
SHOULDs.]

5.6.3. The tail-entry

   For historical reasons, the tail-entry (i.e. the rightmost entry in
   the Path-content) is regarded as a "user name", and therefore MUST
   NOT be interpreted as a site through which the article has already
   passed. Moreover, the Path-content is not an E-mail address and MUST
   NOT be used to contact the poster. Posting and/or injecting agents
   MAY place any string here. When it is not an actual user name, the
   string "not-for-mail" is often used, but in fact a simple "x" would
   be sufficient.

   Often this field will be the only entry in the region (known as the
   pre-injection region) after the '%', although there may be entries
   corresponding to machines traversed between the posting agent and the
   injecting agent proper. In particular, injecting agents that receive
   articles from many sources SHOULD include the identity of the source
   machine connecting to do the injection, and possibly other
   information enabling them to establish the circumstances of the
   injection (provided it does not conflict with any genuine site
   identifier). The '!' delimiter may be used freely within the pre-
   injection region, although '/' and '?' are also appropriate if used
   correctly.
[Y7 The above paragraph is to be rewritten as follows, now that we have
the Injector-Info header.]

   Often this field will be the only entry in the region (known as the
   pre-injection region) after the '%', although there may be entries
   corresponding to machines traversed between the posting agent and the
   injecting agent proper. In particular, injecting agents that receive
   articles from many sources MAY include the identity of the source
   machine connecting to do the injection, (or other information to
   establish the circumstances of the injection) and SHOULD do so if no
   Injector-Info header (6.19) has been added. Any such inclusion SHOULD
   NOT conflict with any genuine site identifier. The '!' delimiter may
   be used freely within the pre-injection region, although '/' and '?'
   are also appropriate if used correctly.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131 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


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.