[lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-lamps-eai-addresses-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.