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.