Minor issues:
1. It is not clear from the draft what the use case for using the group
construct is. Section 3 talks about the issues with using the group
construct and recommend limited use, but this is the only information.
The main driver for this work is to add support for EAI downgrade mechanisms,
although a good case can also be made that the present restrictions on group
usage are silly, limiting and unnecessary. (The silliness arises from the
observation that these restrictions enforced by most agents in the field.)
It is far from clear that it makes sense to clutter up this very clean and
crisp specification with a bunch of EAI use case scenarios, especially since
this is an update to RFC 5322 that could in theory be merged into the main
document in the future. A decision taken long ago for both RFC 5321 and 5322
was to keep them as free of entanglements with technology that's layered on top
of them (e.g., MIME, various SMTP extensions) as possible.
In any case, the decision of the group was not to do this.
2. Section 2.1 says "If the sender field uses group syntax, the group
MUST NOT contains more than one mailbox." Why use a group name for a single
mailbox?
Why not? I'm sorry, but this question makes no sense. A group is a
characteristic attached to a collection of zero or more addresses. A group
containing a single member is every bit as valid as a construct as a group
containing 20 members. Or zero, for that matter.
Ned