Re: Protection of hyphen

 > Note that "owner-listname" is a prime example of why we might *not* 
 > want to protect the hyphen. The hyphen in that name is not for making 
 > subaddresses: it is just there for preventing the two names from 
 > smooshing together.

But some software (eg sendmail) has special knowledge of the
owner-listname construct.

I wonder how much mailing list management software has things like
owner-listname or listname-request hardwired?  (Note: I'm not saying
that this is a big problem in practice; I'm just posing the question.)

Also hyphen is the default delimiter for subaddressing in qmail
(though this is easily changed, so may not matter so much).

 > >One simple approach would be to leave underscore unprotected instead,
 > >use xn__ as the ACE prefix and to use _ as the delimiter in
 > >bootstring.  Underscore is one of the few characters that would be
 > >safe to use in this way, since it has longstanding use in e-mail
 > >addresses of the form initials_surname.
 > 
 > "longstanding use" is probably an overstatement. Some people use it 
 > for that, others don't. It can be said to be a rarely-used character, 
 > and is certainly not used in normal non-computer writing.

My point was that underscore was common enough in e-mail addresses
long enough ago that underscore is unlikely to be incompatible with
existing e-mail gateways or non-Internet e-mail clients.  In
particular, I seem to recall regularly seeing initials_surname in the
days before initials.surname became popular.

If ToASCII is going to introduce punctuation that wasn't present in
the original address, it is highly desirable that this does not
involve unusual characters that may be incompatible with existing
software.  (Hyphen or underscore are unlikely to pose problems; other
choices may be less safe.)

 > The advantage of keeping the hyphen is again simplicity and 
 > parallelism with IDNA. Do we lean in one direction and move away from 
 > IDNA in a possibly-confusing fashion, or do we lean in the other 
 > direction and look very much like IDNA but possibly lose some 
 > perceived functionality? Right now, we have taken the second 
 > approach, but we are open to hearing other opinions.

I'm currently undecided on the issue of structured local parts.  The
proposed solution just struck me as a slightly odd compromise, in that
its stated aim is to protect structured local parts, but it fails to
protect one of the more common separators.

I can certainly see the benefits in the current proposal, though, even
if protecting hyphen is considered too much work for too little gain.

In particular, preserving % and ! addressing formats (as the current
proposal does) may be important to some people.  Even though such
constructs are considered obsolete on the networks that most of us
use, they _may_ be needed (I don't know) by people in countries where
the network infrastructure is less developed.  (Then again, maybe IMAs
may not be considered a priority by users of such networks?)

	-roy