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 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.