Protocol Action: Internet Message Format to Proposed Standard
The IESG <iesg-secretary@ietf.org> Wed, 27 December 2000 19:58 UTC
Received: from cs.utk.edu (cs.utk.edu [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23366 for <drums-archive@odin.ietf.org>; Wed, 27 Dec 2000 14:58:01 -0500 (EST)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA09232; Wed, 27 Dec 2000 14:55:47 -0500 (EST)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 27 Dec 2000 14:55:09 -0500
Received: by cs.utk.edu (cf v2.9s-UTK) id OAA09194; Wed, 27 Dec 2000 14:55:08 -0500 (EST)
Received: from ietf.org (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA09181; Wed, 27 Dec 2000 14:55:02 -0500 (EST)
Received: from ietf.org (132.151.1.176 -> odin.ietf.org) by cs.utk.edu (smtpshim v1.0); Wed, 27 Dec 2000 14:55:02 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23348; Wed, 27 Dec 2000 14:54:57 -0500 (EST)
Message-Id: <200012271954.OAA23348@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: drums@cs.utk.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet Message Format to Proposed Standard
Date: Wed, 27 Dec 2000 14:54:56 -0500
Sender: scoya@cnri.reston.va.us
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>
The IESG has approved the Internet-Draft 'Internet Message Format' <draft-ietf-drums-msg-fmt-09.txt> as a Proposed Standard, obsoleting RFC822. This document is the product of the Detailed Revision/Update of Message Standards Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary The IESG has approved the Internet-Draft 'Internet Message Format Standard' <draft-ietf-drums-msg-fmt-09.txt> as a Proposed Standard. This document is the product of the Detailed Revision/Update of Message Standards Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. Technical Summary This document is a long-awaited update of RFC 822, "Standard for the Format of ARPA Internet Text Messages" [RFC-822]. It reflects current practice and incorporates incremental changes that were specified in other RFCs. Working Group Summary This document is the result of extensive and sometimes contentious discussion over the history of the DRUMS working group. Not all issues with RFC 822 were resolved; however, this document reflects the points on which the working group acheived consensus. Protocol Quality Keith Moore and Ned Freed reviewed the specification for IESG. RFC 822 is widely implemented. Most of those implementations would comply with this new specification with little or no modification. Even though this revision narrows the syntax as compared with RFC 822, this new specification generally requires conforming implementations to accept the entire (less restrictive) RFC 822 syntax when reading messages. Note to RFC Editor: In section 2.1, please replace the paragraph: Note: The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. The 78 character recommendation is due to limitations in many implementations that display these messages which may truncate the display of more than 78 characters per line. Of course, even though these limitations are put on messages, interpreters of messages would do well to handle an arbitrarily large number of characters in a line, including for display, for robustness' sake. with: Note: The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 1000 characters on a line including the CR and LF. The 78 character recommendation is due to limitations in some implementations that display messages which may truncate the display of more than 80 characters per line including the CR and LF. Of course, even though these limitations are put on messages, message handlers would do well to handle an arbitrarily large number of characters in a line, including for display, for robustness' sake. Please note: It has been suggested that the RFC Number assigned be 2822.