> 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