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

Note: This ballot was opened for revision 07 and is now closed.

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-11-12 for -07)
No email
send info
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.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-11-13 for -07)
No email
send info
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 <benoitclaise@cisco.com>,Benoit Claise <benoîtclaise@cisco.com>;

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 <address-list> 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
       <mailbox> syntax element to the <address> 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 ...

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-11-26 for -07)
No email
send info
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."

(Stephen Farrell) No Objection

Comment (2012-11-12 for -07)
No email
send info
Some examples that clarify what is now allowed but
was previously forbidden would be nice to have. (No
more than that.)

(Brian Haberman) No Objection

Comment (2012-11-13 for -07)
No email
send info
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?

(Russ Housley) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Barry Leiba Recuse