Skip to main content

Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
draft-leiba-5322upd-from-group-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields' to Proposed Standard (draft-leiba-5322upd-from-group-09.txt)

The IESG has approved the following document:
- 'Update to Internet Message Format to Allow Group Syntax in the "From:"
   and "Sender:" Header Fields'
  (draft-leiba-5322upd-from-group-09.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/


Ballot Text

Technical Summary

   The Internet Message Format (RFC 5322) allows "group" syntax in some
   email header fields, such as "To:" and "CC:", but not in "From:" nor
   "Sender:".  This document updates RFC 5322 to relax that restriction,
   allowing group syntax in those latter fields, as well as in "Resent-
   From:" and "Resent-Sender:", in certain situations.

   This change is required to make the relationship between an
   internationalized POP or IMAP server handing messages with non-ASCII
   material in message headers and legacy POP or IMAP clients work in
   some of the ways approved by the EAI WG.  Without this change, such
   messages effectively become completely undeliverable and may be lost.

Working Group Summary

   The specification has been reviewed informally on the EAI and 822
   mailing lists and extensively discussed among EAI participants as
   part of that effort (see above).  Other than as noted below, there
   have been no significant objections; smaller issues that have been
   identified have already been addressed in the document.

   One individual has expressed concerns about the change represented by
   the document.  The core of that concern has been addressed by adding
   an Applicability Statement to the specification and adjusting some
   other text.  He would like us to go further, perhaps abandoning the
   change entirely.  There seems to be consensus on the mailing lists
   that have reviewed the document that his concerns are largely
   unfounded (no one else has spoken up in favor of his point of view
   and several people have made that observation) as well as primarily
   focused on a protocol that has not been considered in the IETF, much
   less standardized.

   Given that concern, the Security Considerations provisions should be
   checked during IETF Last Call, but, especially if use of the change
   is confined to carefully-selected cases as the document recommends,
   the document Shepherd is convinced that there are no outstanding
   important issues in that or any other area.

   The small amount of ABNF in the document has been checked carefully
   and adjusted for maximum clarity.

Document Quality

   Implementation of this change is basically trivial.  Parsers for
   email message headers already have to contain the necessary
   provisions and code to support group syntax in other contexts, so
   allowing that syntax for additional backward-pointing fields should
   be just a matter of changing the applicable processing from one
   already-present case to another.  If any additional code or
   processing is needed, it will be control the specific cases in which
   the construction is allowed (as advised by the Applicability
   Statement).


Personnel

   The document shepherd is John C Klensin.  The responsible Area
   Director is Pete Resnick.

RFC Editor Note