[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] WG last call documents
"Adam M. Costello" wrote:
> Exactly which "reasonable" characters are you talking about?
All UCS character codes are valid for something, and anything can be
stored in DNS as an owner domain name (think TXT) or as data (SOA, RP, or
as-yet-invented). The problem with the current spec is that case-folding
and normalization will impose restrictions on these assignments. This is
inappropriate for a generic i18n domain name label syntax.
On a secondary note, normalization and lowercasing are problems having to
do with hostnames, and those should be enforced by delegation and
application rules. Note well: the existing DNS does not enforce hostname
rules anywhere else, we should be mimic'ing this behavior. The hostname
rules should only define, the codecs should only encode/decode, and the
apps/protos/formats should enforce.
> The prohibited list in nameprep is pretty small, and they're all
> characters that you'd have to be somewhat crazy to want to use in
> domain names.
I think you meant hostname here. Remember that hostname rules apply to
delegations. Domain name rules are a broader category which also include
things like SRV, email addresses, and so forth.
> I asked long ago, shouldn't we try to design a solution that handles
> both domain labels and email address local-parts? I was told no,
> that's out of scope, a different working group will take care of
> email address local parts. I share your concern, but I got the
> impression that this was not open for debate.
The email people will come up with their own character restrictions, which
is exactly the point. The namespace should ALLOW them to come up with
mapping rules, case-folding, normalization and whatever other rules they
wish. I mean, if they want to have a perverse mailbox sequence, why
shouldn't they? The codecs should only deal with inputs and outputs. I'm
pretty certain that's what you were told.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/