Subject: Differences between RFC 2822 and Usefor

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 9 Apr 2005 20:00:42 GMT

I published a list of differences from RFC 2822 as they stood in the old
draft-13 last July (and it has been on our web site ever since). Most of
those differences were agreed years ago when this WG was first formed and
have been in the drafts ever since. I don't recall any disagreement with
the list when I published it.

There have been a few things changed since then (like the MIME-style
parameters have gone), and also things are described somewhat differently
in USEFOR, so I have updated it. The new texts follows (and it will
shortly be put on the website), and after that there are the diffs from the
previous one.

Note that many of these agreed changes have not made it into the new
USEFOR yet, and so I have marked the missing ones with "**".

                Differences between RFC 2822 and Usefor.
		----------------------------------------

08 April 2005

NOTE: Some items have been removed from the previous version, hence some
discontinuities in the listing below.

A '**' before an item indicates that the restriction in question has not yet
been incorporated into the USEFOR document.

1. Differences enforced syntactically.
--------------------------------------

1.1  There is a REQUIRED SP (not even WSP) after the ':' in each header
     (even if the header has no content).

1.2  An <unstructured> MUST have at least one character. Thus the Subject
     (for example) of an article cannot be empty.

1.3**In the References-header, there is an obligatory CFWS (currently
     restricted to FWS by 2.1.1 below) in between each msg-id.

NOTE: all the above were in RFC 1036, and the first is also required by
NNTP.

1.5**Body lines are restricted to 998 characters plus CRLF (as in RFC
     2822). However, all agents SHOULD, and relaying agents MUST, process
     lines of arbitrary length.

1.8  All the "obsolete" syntax in RFC 2822 is NOT REQUIRED (though it MAY
     be recognized). There are two small exceptions, listed below.

1.8.1  In the Date-header, the obsolete "UT" and "GMT" forms of zone MUST
       be recognized (because of their current widespread use), but MUST
       NOT be generated.

1.8.2**The (mis-named) "obsolete" syntax for phrase from RFC 2822, which
       allows for 'John D. Smith' to remain unquoted, is retained (but
       renamed as extended-phrase).

NOTE: NNTP imposes similar restrictions.

1.11 Message-ID

1.11.1 No CFWS allowed (only FWS, which in practice means only non-folded
       WSP).

1.11.2 No quoted-pairs in msg-id, except for
           '\\' and '\"' in id-left
           '\[', '\]' and '\\' in id-right

1.11.3 No quoted-strings in id-left unless they contain one of the
       "specials".

1.11.4 No '>' anywhere within a msg-id, even within a quoted-string (to
       conform with RFC 1036).

1.11.5 All these restrictions on msg-id apply also to the References- and
       Supersedes-headers.

1.11.6 No control characters in msg-id.

2. Differences enforced by verbiage.
------------------------------------

2.1  The following MUST be accepted, but SHOULD NOT be generated (yet):

2.1.1**Comments, except after a mailbox (where there is a now-deprecated
       convention for indicating the mailbox owner), or at the end of a
       date-time (which conventionally indicates the timezone). They are,
       however, freely allowed in headers that are newly defined in Usefor.

2.1.2**Extended-phrases (see 1.8.2 above).

2.2  The content of the first line of a header MUST NOT consist of WSP
     only (though such SHOULD be accepted). Observe that continuation
     lines of headers also MUST NOT consist of WSP only, as in RFC 2822.

2.3  Headers with empty content are deprecated (but if present that SP
     after the ':" is still required).

2.4  All agents MUST support header lines up to 998 octets, but there is
     no RECOMENDED limit of 78 characters as in RFC 2822. There is mention
     of a purely advisory limit of 79 (with a reference to USEAGE).

2.5  Relaying agents MUST NOT refold headers in transit.

2.6  There must not be more than one header with a given header-name,
     except where explicitly sanctioned by the appropriate standard. In
     particular, there MUST NOT be more than one Keywords-header.

2.7  The length of a msg-id MUST NOT exceed 250 octets.

2.8**The body of an article SHOULD NOT be empty.

2.9  (was 1.6) RFC 2047 and RFC 2231 are fully integrated into the Netnews.

2.10 (was 1.7) All the Content-* MIME headers are considered to be
     incorporated into Netnews and MUST be accepted in articles at, least
     to the extent required by RFC 2049.

2.11 A References header MUST be provided for followups (as opposed to SHOULD
     be provided for replies in RFC 2822).

3. Rules specific to Netnews headers.
-------------------------------------

3.2  Comments (but not FWS) are forbidden in the Newsgroups-,
     Distribution- Path- and Followup-To-headers (also see 1.11.1 above
     for Message-ID).

3.3**WSP and folding in Newsgroup- and Followup-To-headers MUST be
     accepted, but SHOULD NOT be generated (yet).

NOTE: The effect of all these differences still preserves the property
that the articles that Usefor permits to be generated form a proper subset
of the articles that are required to be acceptable to RFC 2822.

*** rfc2822-diffs.old	Thu Jul  1 23:24:57 2004
--- rfc2822-diffs.txt	Fri Apr  8 22:05:05 2005
***************
*** 3,6 ****
  
! 01 July 2004
  
  1. Differences enforced syntactically.
--- 3,12 ----
  
! 08 April 2005
  
+ NOTE: Some items have been removed from the previous version, hence some
+ discontinuities in the listing below.
+ 
+ A '**' before an item indicates that the restriction in question has not
yet
+ been incorporated into the USEFOR document.
+ 
  1. Differences enforced syntactically.
***************
*** 11,13 ****
  
! 1.2 An 'unstructured' MUST have at least one character. Thus the Subject
       (for example) of an article cannot be empty.
--- 17,19 ----
  
! 1.2 An <unstructured> MUST have at least one character. Thus the Subject
       (for example) of an article cannot be empty.
***************
*** 14,16 ****
  
! 1.3  In the References-header, there is an obligatory CFWS (currently
       restricted to FWS by 2.1.1 below) in between each msg-id.
--- 20,22 ----
  
! 1.3**In the References-header, there is an obligatory CFWS (currently
       restricted to FWS by 2.1.1 below) in between each msg-id.
***************
*** 20,26 ****
  
! 1.4  The allowed characters in a header-name are restricted to ALPHA,
! DIGIT and embedded '-'. However, agents SHOULD accept all printables
!      except SP and ':'.
! 
! 1.5  Body lines are restricted to 998 characters plus CRLF (as in RFC
       2822). However, all agents SHOULD, and relaying agents MUST,
process
--- 26,28 ----
  
! 1.5**Body lines are restricted to 998 characters plus CRLF (as in RFC
       2822). However, all agents SHOULD, and relaying agents MUST,
process
***************
*** 28,38 ****
  
- 1.6  RFC 2047 and RFC 2231 are fully integrated into the syntax. Thus
-      encoded-words are explicitly included within 'unstructured',
-      'ccontent' and 'phrase'. Moreover, it is the RFC 2231 version of
-      encoded-word that is used.
- 
- 1.7 All the Content-* MIME headers are considered to be incorporated
into
- the syntax (i.e. they are to be accepted in articles, though not all
- of them are required to have their semantic intentions implemented).
- 
  1.8 All the "obsolete" syntax in RFC 2822 is NOT REQUIRED (though it MAY
--- 30,31 ----
***************
*** 44,46 ****
  
! 1.8.2 The (mis-named) "obsolete" syntax for phrase from RFC 2822, which
         allows for 'John D. Smith' to remain unquoted, is retained (but
--- 37,39 ----
  
! 1.8.2**The (mis-named) "obsolete" syntax for phrase from RFC 2822, which
         allows for 'John D. Smith' to remain unquoted, is retained (but
***************
*** 68,70 ****
--- 61,65 ----
  
+ 1.11.6 No control characters in msg-id.
  
+ 
  2. Differences enforced by verbiage.
***************
*** 74,83 ****
  
! 2.1.1 Comments, except after a mailbox (where there is a now-deprecated
         convention for indicating the mailbox owner), or at the end of a
!        date-time (which conventionally indicates the timezone).
!        BUG: they ought to be freely allowed in headers that are newly
! defined in Usefor (and indeed the text positively encourages them
!        in some of those places).
  
! 2.1.2  Extended-phrases (see 1.8.2 above).
  
--- 69,76 ----
  
! 2.1.1**Comments, except after a mailbox (where there is a now-deprecated
         convention for indicating the mailbox owner), or at the end of a
! date-time (which conventionally indicates the timezone). They are,
! however, freely allowed in headers that are newly defined in Usefor.
  
! 2.1.2**Extended-phrases (see 1.8.2 above).
  
***************
*** 88,91 ****
  2.3  Headers with empty content are deprecated (but if present that SP
! after the ':" is still required). Injecting agents SHOULD delete such
!      headers, but other agents MUST propagate them.
  
--- 81,83 ----
  2.3  Headers with empty content are deprecated (but if present that SP
!      after the ':" is still required).
  
***************
*** 103,107 ****
  
! 2.8  The body of an article SHOULD NOT be empty.

  3. Rules specific to Netnews headers.
--- 95,107 ----
  
! 2.8**The body of an article SHOULD NOT be empty.
  
+ 2.9 (was 1.6) RFC 2047 and RFC 2231 are fully integrated into the
Netnews.
  
+ 2.10 (was 1.7) All the Content-* MIME headers are considered to be
+ incorporated into Netnews and MUST be accepted in articles at, least
+      to the extent required by RFC 2049.
+ 
+ 2.11 A References header MUST be provided for followups (as opposed to
SHOULD
+      be provided for replies in RFC 2822).
+ 
  3. Rules specific to Netnews headers.
***************
*** 109,118 ****
  
- 3.1  All structured headers have MIME-style extension-parameters, with
- x-attributes or to be defined in future standards. Some have explicit
- parameters defined in this standard. However, this does not apply to
- headers which are taken from RFC 2822 or other mail standards, nor to
-      the Mail-Copies-To, Complaints-to and Supersedes-header defined in
-      this standard. Nevertheless, such parameters SHOULD be recognized
-      (and ignored) in all headers.
- 
  3.2  Comments (but not FWS) are forbidden in the Newsgroups-,
--- 109,110 ----
***************
*** 121,128 ****
  
! 3.3  The following MUST be accepted, but SHOULD NOT be generated (yet):
  
- 3.3.1  MIME-style parameters in headers defined prior to this standard.
- 
- 3.3.2  WSP and folding in Newsgroup- and Followup-To-headers.
- 
  NOTE: The effect of all these differences still preserves the property
--- 113,117 ----
  
! 3.3**WSP and folding in Newsgroup- and Followup-To-headers MUST be
!      accepted, but SHOULD NOT be generated (yet).
  
  NOTE: The effect of all these differences still preserves the property

-- 
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: [email-masked]      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