Summary: Has enough positions to pass.
I cleared my DISCUSS concerning the need to update RFC 5280, since Russ tells me those updates are already in draft-ietf-lamps-rfc5280-i18n-update. However, I still think the text in sections 1, 4, and 6 should be clarified to avoid the impression that those updates are done by _this_ document. Editorial Comments and Nits: - section 3: -- Please proofread section 3 for missing articles. -- please consider reformulating " ... subjectAltName MUST only be used when ..." in the form of "... MUST NOT be used unless..." (MUST ONLY can be ambiguous about whether you mean "MUST NOT unless" or "MUST do this and nothing else.") - 4: "... (and avoids any "mappings" mentioned in that document)" s/avoids/avoid
Thanks for your work on this document. One thing I noticed is that the name for what I presume is an early registration at IANA ("id-on-smtputf8Name") varies from the final name used in this document ("id-on-smtputf8Mailbox"). I would ask the authors and shepherd to please carefully review the final IANA registrations upon document approval to ensure this is updated appropriately.
I know that you guys have been doing this longer than I've even been thinking about it, but I'm looking at Due to operational reasons to be described shortly and name constraint compatibility reasons described in Section 6, SmtpUTF8Mailbox subjectAltName MUST only be used when the local-part of the email address contains non-ASCII characters. When the local- part is ASCII, rfc822Name subjectAltName MUST be used instead of SmtpUTF8Mailbox. This is compatible with legacy software that supports only rfc822Name (and not SmtpUTF8Mailbox). The appropriate usage of rfc822Name and SmtpUTF8Mailbox is summarized in Table 1 below. and, if I'm reading this correctly, the plan is IF you don't NEED to send non-ASCII characters use rfc822Name and all implementations know what that means and all implementations will work fine ELSE you DO have non-ASCII characters so use SmtpUTF8Mailbox and all the new implementations will work fine and all the old implementations will barf which is OK because they can't handle non-ASCII anyway Am I getting that right? Assuming so, I looked at the "operational reasons to be described shortly" and "name constraint compatibility reasons described in Section 6", and didn't see anything that was was quite that blunt. Assuming that you're sending SmtpUTF8Mailbox to an implementation that doesn't support it, and you figure that out, is there a well-understood fallback that could be either referenced or described in a sentence or two? If the answer is "what an implementation does at that point is up to the implementation, and different implementations may have different reasons to respond differently", that could be a fine answer, of course.
I think some of the comparison issues brought up in RFC6943 might be relevant in the Security Considerations here.
I found this clean and understandable; unfortunately, I know basically nothing about the subject matter and so am balloting NoObj instead of Yes. Thanks to Ron Bonical for the OpsDir review.
I don't know much about this subject, so I'm balloting 'No Objection', however, section 4 and section 6 read to me that this doc should update RFC5280. Please check!