Idna-update Digest, Vol 25, Issue 3

[Andrew Sullivan]

Hi,

On Mon, Jan 05, 2009 at 02:11:37PM +0200, Vaggelis Segredakis wrote:
> 
> First of all please accept my clarification that I am not complaining and my
> registry has already put a significant amount of money and effort to operate
> in the IDNA2003 environment.

I believe it, and I do not intend to imply that you're complaining or
that you haven't already done plenty of work.  Having done similar
work myself for some registries, I understand how painful all of this
is.  Indeed, I had the impression at the BOF in Philadelphia that
some operators were arguing we needed to plan fewer changes, because
the scope of the changes on the table entailed too many differences
with existing practice.  Maybe we should have listened to that more
sympathetically (I don't know).
 
> For me this WG is working on a protocol that should allow everybody to
> register & use domain names in their actual language, like if they were
> registering & using domain names in Latin. 

Well, yes and no.  For instance, as John already pointed out,
alternative spellings of "the same word" in English, spelled only with
ASCII code points, don't match one another.  The significant
difference in your case is that you expect forms of labels with the
tonosh and forms without to match one another.  One way of looking at
that is to treat it similarly to the ASCII-only case of causing
colorful.org and colourful.org to resolve to the same
place.  Depending on where in the world the user is, only one of those
two will be the natural spelling of "the same word" used in a label.
The way we do this traditionally is to use DNAMEs or CNAMEs or just
duplicate records.
 
> My last email just explained why in Greek it is already required of the
> registry to DNAME different Greek (not Greek/Latin) domain names just
> because a "tonos" is required for most of the Greek words and every
> registrant is obliged to register at least two domains for each word. We
> provide the option to treat each domain name separately as well.

As I argue above, that's totally consistent with how the ASCII case is
handled as well.  But from the point of view of the DNS, we're both
speaking about this the wrong way.  DNS doesn't have words in it.  It
has labels.  Label matching requires an exact match.  If you want
semantic matching, you need to do it in some other way, using the
facilities of the DNS.
 
> In IDNA2008, each registrant who wishes to register a domain name with a
> final sigma will have to register four different domains (non-tonos / tonos
> with sigma, non-tonos / tonos with final-sigma) and the registry has no
> other way to help this registrant but to DNAME them.

I think I disagree with your final claim.  I outlined a way, based on
how one manages the "primary" record in one's back-end registration
database, using database triggers, to do other things as well.
 
> Even if we were to DNAME everything, this registrant still cannot enjoy
> having his email delivered to this email address, because he speaks Greek
> and IDN DNS will require from him to set up four different zones and four
> mailservers if he really wishes his email to arrive at destination no matter
> how a Greek person will type the word the registrant chose to register as a
> domain name.

Four different zones are not really needed.  Since you've DNAMEd them
all in the registry, actually, there's no zone on the opposite side of
the zone cut needed for the entries with the DNAMEs.  Every mail
server or web server of which I am aware allows you to specify
multiple destinations as being "equivalent"; and anyway, the DNAME
ought to solve the problem before the server in question even sees the
connection (the mail server probably still needs to be taught that a
given domain is equivalent).  

If you are arguing that this is a burden on the user, I have to
agree.  That's part of the cost we decided to accept in order to gain
the benefit of not having to replace the whole DNS for this purpose.
(Whether that trade-off is right is actually what I was asking John in
another note in this thread.)  I do think that various tools for users
of common mail and web servers would be a good idea.  I also think it
would be useful for registries to have some way of publishing their
transformation rules, so that such tools can be automated.  (I've been
working on a draft to outline how to make that happen, but it hasn't
gone very far.  I should blow the dust off.)
 
> Some better options in the protocol have to be introduced and no registry
> can fix that on its own zone files.

I disagree with your conclusion, very strongly; but I also think it
isn't supported by the evidence, as I argue above.

Best regards,

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.