Re: Full-width/half-width issues

 > Canonical decomposition has no effect on U+2474.  I think you meant
 > compatible decomposition.

I did indeed.

 > You seem to be suggesting that the entire mail address be normalized,
 > although IMAA currently talks about dequoting only the local part (the
 > dequoting of the domain name was implicit in IDNA).

I was indeed suggesting that.

 > IDNA is mostly silent about how domain names are separated into labels.
 > In particular, if the domain name contains a compatibility character
 > whose decomposition includes an ASCII full stop (.), does that delimit
 > labels or not?  I think we punted on this because it was considered a
 > user-interface issue.
 >
 > If IMAA required normalization of the entire mail address, then it would
 > settle the question for domain names appearing in mail addresses.  But
 > should such a decision be made by IMAA, or by a future update to IDNA?

I don't think it makes sense for IDNA to punt it to the user
interface, per se.  IDNA can punt the issue to the user of IDNA, which
in this case is IMAA.  IMAA then has to make a decision (which could
be to punt it to the user of the IMAA, which could in turn be a user
interface).

 > Hmmm, the motivation for requiring recognition of fullwidth
 > metacharacters was consistency with the requirement to recognize
 > fullwidth at-sign, but now that I think about it, IDNA doesn't have
 > that sort of consistency.  For example, an extended DNS master-file
 > format might allow non-ASCII domain names, and IDNA would require that
 > fullwidth dots be recognized as dots in such names, but it does not
 > require that fullwidth backslash be recognized as beginning an escape
 > sequence.  That's a private interface issue for the designer of the
 > extended master-file format.

Ordinary users never encounter zone files, so it is reasonable to
leave that as a private issue for the name server implementor.

Ordinary users deal with RFC 822/2822 addresses (or at least
addr-specs) every day, and such constructs contain a variety of
metacharacters including (sometimes) quoting.

 > So maybe IMAA, like IDNA, should not try to dictate exactly how
 > dequoting is done, and should, like IDNA, limit any discussion of
 > fullwidth characters to those delimiters that remain after dequoting
 > (namely, at-sign).

IDNA addresses the issue for every metacharacter that an end-user will
ever see (there is only one, of course: full stop).  I think therefore
it's consistent for IMAA to consider doing likewise (as the
current draft does).

 > RFC 2822 defines the syntax of mail addresses appearing in
 > message headers, but does not define the syntax of mail addresses
 > entered/displayed in user interfaces, or appearing in config files.
 > Mail addresses in those other contexts might or might not use the syntax
 > of RFC 2822 (or 2821), and it is in precisely those contexts where the
 > definition of an IMA is relevant.

See my separate post "On humanly-readable (printable) e-mail
addresses", which started out (largely) as a response to this
paragraph.

For any e-mail system to be useful, it needs an external
(humanly-readable, printable) representation of addresses.  I would
argue that the Internet has one, even though the original authors of
RFC 822 never saw the need to formalize it.

	-roy