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

[Ballot comment]
Pete and Barry have proposed some new text for the Introduction to cover both my Discuss and my Comment.

OLD
  As use cases for group syntax evolve, particularly with
  respect to email address internationalization issues, it is becoming
  clear that there is little value in forbidding that usage completely,
  and significant value in allowing it in certain situations:
  o  There are times when it is desirable to represent the creator of a
      message as a group or role designation, rather than as one or more
      mailboxes.
  o  There are times when it is desirable to represent the creator
      and/or sender of a message in a manner that is specifically not
      valid in a reply.
NEW
  While named groups were seen as useful in destination
  fields, their use in originator fields seemed unnecessary.
  Additionally, "group" syntax allows for empty groups (i.e., a group
  name followed by no specified mailboxes) to support a "Bcc:"
  function, and it was considered non-interoperable to specify an
  originator without any mailboxes since it would render the message
  unreplyable. However, use cases for group syntax have evolved. There
  are instances, particularly with respect to new internationalized
  email addresses, where a mail agent might need to create an email
  message with no replyable addresses in the "From:" or "Sender:"
  fields. Allowing group syntax in the "From:" and "Sender:" fields
  would make that possible. Review of current email user agents makes
  it clear that there is little value in forbidding that usage
  completely.
END

I realise that I am picking at this when there is clear consensus that the idea should go ahead. I have downgraded to a Comment since I don't believe I am raising any issue that causes interoperability issues or would represent a broken specification. This isn't harmful to the internet; it merely disrupts my digestion. I hope everyone will continue to polish this text.

>    While named groups were seen as useful in destination
>    fields, their use in originator fields seemed unnecessary.

"unnecessary" is not normally a reason why something is prohibited. But maybe it wasn't defined rather than explicitly prohibited?

>    Additionally, "group" syntax allows for empty groups (i.e., a group
>    name followed by no specified mailboxes) to support a "Bcc:"
>    function, and it was considered non-interoperable to specify an
>    originator without any mailboxes since it would render the message
>    unreplyable.

So, one of:
- that consideration has changed (i.e., it is no longer non-interoperable to specify an originator without any mailbox)
- specifying an originator without a mailbox no longer renders the message unreplyable
- something else changed

>    However, use cases for group syntax have evolved. There
>    are instances, particularly with respect to new internationalized
>    email addresses, where a mail agent might need to create an email
>    message with no replyable addresses in the "From:" or "Sender:"
>    fields.

Perhaps this is obvious to one skilled in the art, but to me it seems to be without logical progression to say that "new internationalized email addresses" create an instance where a mail agent might need to create an email address with no replyable addresses in the From: or Sender: fields.  I suspect that this could be solved by the insertions of a simple reference (or failing that, with a paragraph describing the "new" usage of these fields).

>    Allowing group syntax in the "From:" and "Sender:" fields
>    would make that possible.

As, indeed, would allowing the From: and Sender: fields to directly include the foreign character sets that must be the problem.

I think I worked out at this point what offends my delicate constitution.
I source code terms...
You have a typedef that says From: has syntax replyableAddress
You also have a type called groupAddress that allows all sorts of guff to be included.
You want to allow From: to include non-replyable addresses and so you have decided to make From: a union of replyableAddress and groupAddress because you are aware that you can put a non-replyable address into a structure of type groupAddress.
Great, but that is not what groupAddress is for!
Surely you should define a *new* data type for your specific form of non-replyable address instead of leveraging an existing type that has a completely different purpose (and name).

>    Review of current email user agents makes
>    it clear that there is little value in forbidding that usage
>    completely.

Ah, from this text I deduce that there *is* value in forbidding that usage completely.
Actually, review of current email user agents cannot make it clear whether there is value in forbidding usage or not. It can only make it clear how current UAs actually handle the case of an unexpected group syntax in a From: or Sender: field.
Thus you can say that it will be "harmlessly backward compatible because all current user agents surveyed already gracefully handle an unexpected group syntax in a From: or Sender: field."

[Ballot comment]
1. As mentioned by others, example (such as http://tools.ietf.org/html/rfc5322#appendix-A.1.3), mapped to the two following use cases, would help me understand what you try to accomplish:

  o  There are times when it is desirable to represent the creator of a
      message as a group or role designation, rather than as one or more
      mailboxes.
  o  There are times when it is desirable to represent the creator
      and/or sender of a message in a manner that is specifically not
      valid in a reply.

And along with "As use cases for group syntax evolve, particularly with respect to email address internationalization issues, ..."
For example, does it mean that I could have:

  From: AllBenoitName Group:Benoit Claise ,Benoit Claise ;

Note the i and î difference. Is this the use case, or I get that wrong?
After speaking to Pete, I now understand that this is not the goal. You see how confused I was ;-)

2.
Barry, you mentioned in a reply to a DISCUSS/COMMENT

    There's already nothing preventing the mailbox from being a forwarder
    or expander, so we can (and do) already do something like these:

      From: iesg@ietf.org, iab@iab.org
      Sender: iesg-secretary@ietf.org

    or

      From: iesg@ietf.org
      Sender: app-chars@tools.ietf.org

    or even

      From: ietf@ietf.org

    This doesn't change that, and it's another reason that this change
    doesn't really matter in practice.  I might add some text in to note
    this.

I was not aware that it was even possible.

Barry, you mentioned in a reply to a DISCUSS/COMMENT

    Let's start with some basics to make sure we're on the same page:

    1. From: is the author(s), and in the absence of a Reply-To:, it's where you send the reply.
    2. Sender: is the transmitter. There should only ever be one transmitter, and clients don't send replies there.
    3. Group syntax allows for empty groups (e.g., "Not telling:;"). So allowing for groups in the From: allows for unreplyable messages.
    4. Group syntax allows for any old crap in the name of the group. You can put RFC 2047 ASCII-encoded internationalized nonsense in there.

    So, adding group syntax to From: allows for unreplyable messages, and having it in any header field gives you a nice spot to stick internationalized stuff that you don't want attached to any particular email address.

If I combine my point #1 with the fact that you have to give clarifications and explain the email basics to the reviewers in order to explain why you need this improvement ...  (and btw, don't get me wrong: thanks for that, that helped me a lot as a non email expert) ... I really would like to suggest that you extend the introduction with some more justifications and that you add the examples (as suggested by others).
However, this can't really be a DISCUSS (*), as most probably this entire draft might be very obvious to an email expert.

(*) but close. A general comment, not specific to your draft: my personal believe is that we someone make the RFCs way too hard to read, by specifying the very minimum, and by not justify the use cases, and the design choices.

3. In section 2, "this" refers to "this specification"?

      This changes that
      definition to use the  syntax element, as is used in
      other fields, such as "To:", "CC:", and "Reply-To:".  This also
      changes the definition of the "Sender:" header field from the
        syntax element to the

syntax element. 

4. I had Pete explaining this following sentence to me: "In particular, user agents SHOULD NOT permit the use of groups in those fields in outgoing messages.". Honestly, it would have been difficult for me to understand that you really wanted to say.


  Unless a user agent want to use a group functionality to make the
  message unrepliable (not even sure if this words exist), user agents
  SHOULD NOT permit the use of groups in those fields in outgoing messages.

Again, very close to a DISCUSS ...

[Ballot discuss]
I don't really object to the publication of this document, but I just don't understand the backward compatibility and limited scope pieces.

What happens when an old receiver gets one of these new fangled Sender: fields?

Section 3 appears to say that this specification is not to be used to generate Sender: etc. fields that include group syntax that leave the agent and go on the wire.

Is that understanding correct? If it is correct, why is there a necessity to write a specification?

OTOH Section 4 seems to say "it doesn't matter" because boxes will already have to handle malformed fields.

[Ballot comment]
I found the Introduction pretty bogus!

You say that "email address internationalization issues" are relevant to
the topic of this I-D, but you don't explain why a group syntax is
suddenly more important because of internationalization.

Furthermore, you cite two situations where the use of group syntax would
be valuable. The first is kind of circular, but is acceptable as a
motivation. The second reads:

  o  There are times when it is desirable to represent the creator
      and/or sender of a message in a manner that is specifically not
      valid in a reply.

This is as may be, but I can't see how it has anything to do with the
group syntax. And, anyway, as you note the group syntax is already
allowed in the Reply-To: and To: fields.

---

All the fancy language in 1.1.1 is a surprise. You don't like the normal
boilerplate, but you still want to rely on RFC 2119?

Anyway, you say:

  This document occasionally uses terms that appear in capital letters.
  When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
  NOT", and "MAY" appear capitalized, they are being used to indicate
  particular requirements of this specification.

But "RECOMMENDED" doesn't show up in the document.

[I disagree with you that there is any need to precisely repeat the
text in 1.1.1 from that found in RFC 5322.]

[Ballot comment]
1. I agree with Stephen's comment that some examples would be nice.

2. It is unclear to me if there are not some other issues to worry about here.  The IP architecture forbids the use of multicast addresses as source addresses in order to prevent a variety of attacks and potential DoS issues.  Is there an equivalent issue here by allowing a mailing list address to be used in these fields?  Is there a reliance on the receiver of such a message to recognize that any reply may go to a group, rather than an individual?

[Ballot comment]
The author proposes to delete the note on inconsistency. It might be wise the retain a note of this somewhere in some form to prevent the otherwise certain editorial errata.

    Document Shepherd Writeup - draft-leiba-5322upd-from-group-04



      Date: 2012-09-16

      Shepherd: John C Klensin



1.  Summary

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

  The abstract of the document is basically self-explanatory as to its
  intent and purpose.

  The document is requested to be published as a Proposed Standard
  status.  It updates a very established Draft Standard and is clearly
  protocol specification material.  It does contain an Applicability
  Statement in one section, but that is explicitly provided for in RFC
  2026.

  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.

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


2.  Review and Consensus

  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.


3.  Intellectual Property

  The author has confirmed conformance with BCP 78/79.  There are no
  IPR disclosure(s) on the document.  Given the nature of the
  specification, IPR claims seem extremely unlikely.


4.  Other Points

  The document contains no downward references, the IANA Considerations
  are very clear and easy to follow, and there do not appear to be any
  other signification procedural or format issues.

IANA has reviewed draft-leiba-5322upd-from-group-06 and has the following comments:

IANA understands that, upon approval of this document, there is a single IANA
action which must be completed.

In the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

the following Header Field Names will have their references updated to include
[ RFC-to-be ]. In each case the reference will now be RFC5322
and [ RFC-to-be ]:

Header Field Name: From
Protocol: mail
Status: standard
Reference: [RFC5322][ RFC-to-be ]

Header Field Name: Sender
Protocol: mail
Status: standard
Reference: [RFC5322][ RFC-to-be ]

Header Field Name: Resent-From
Protocol: mail
Status: standard
Reference: [RFC5322][ RFC-to-be ]

Header Field Name: Resent-Sender
Protocol: mail
Status: standard
Reference: [RFC5322][ RFC-to-be ]

IANA understands that this is the only action required to be completed
by IANA upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Update to Internet Message Format to Allow Group Syntax in the "From:"
  and "Sender:" Header Fields'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ballot/


No IPR declarations have been submitted directly on this I-D.