Re: [idn] WG last call documents

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > The i18n "domain name" specification needs to allow any valid UCS
> > character code,
> 
> You might be able to argue that it should allow all valid code points,
> but I don't see why it's *necessary*.  Since IDNA will be the first
> specification to say anything about Unicode characters in domain names,
> later specifications will know exactly which code points they must
> live without.

Why must anything live without some reasonable characters just because
IDNA didn't see the reason for it at this particular moment? There is no
reason to impose any such restriction, so I fail to see why it should be
done in the first place. Perhaps you should argue why this restriction
needs to be in place?

> The email working group has at least two options:  They can either
> take IDNA (which was designed for domain labels) and apply it as-is to
> mailbox names (even though it wasn't designed for that) and live with
> the implications, or they can define their own way of representing
> internationalized mailbox names as ASCII strings (which might bear
> some resemblance to IDNA and might reuse components).  Either way,
> they will interoperate with IDNA just as well (or as badly) as ASCII
> mailbox names interoperate with ASCII domain names today.

Why can't they be accomodated now? Will this flexibility break something
that I don't know about? I mean, why come up with YET ANOTHER ACE ENCODING
just for email addresses or some other data-type which happens to get
stored in DNS sooner or later, when we can design for flexibility right
now? Why?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/