[lamps] Adam Roach's Discuss on draft-ietf-lamps-rfc5280-i18n-update-03: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-lamps-rfc5280-i18n-update-03: Discuss

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-rfc5280-i18n-update/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The final paragraph in Section 2.4 reads:

   Implementations should convert the local-part and the host-part of
   internationalized email addresses placed in these extensions to
   Unicode before display.

The mention of converting "local-part" to "Unicode" has a very strong
implication that the local-part of internationalized email addresses can be
(should be?) ACE-encoded (or otherwise converted to some non-Unicode encoding).
Unless my understanding of internationalized email addresses is wildly wrong
(and that may be the case), this isn't how they work: the local-part *is* in
Unicode, and so conversion to Unicode doesn't make sense.

This seems highly likely to lead developers down the path of ACE-encoding the
local-part component of email addresses, which would cause incompatibilities.


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

The document has several instances of (lower-case) "should" where talking about
implementation behavior. These look like they should be normative to me -- if
that's the intention, please make them uppercase. If not, please update to RFC
8174 boilerplate.

The document contains the following normative requirement:

   Note:  Implementations MUST allow for increased space requirements
   for IDNs.

It's hard to determine what an implementation needs to do in order to satisfy
this normative requirement. Presumably, "increased" is relative to previous
buffer allocations for domain names? Also, the statement can be satisfied as
stated by simply increasing such buffers by a single byte. Surely that's not
what's intended, is it?

(Aside: I find the use of "Note:" preceding normative text to be confusing, so
you might want to remove it)