No subject


Tue Nov 18 23:43:20 CET 2008


one but instead it can lead to further problems.

In our registry we have been using this solution knowing the problems and
pointing them out to our registrants when they decide to set up their domain
name zones. However, if you wish this protocol to move forward and be
successful with the use of email as well, you should not impose on
registries to DNAME names. Instead, it would be useful each transformation
or mapping to exist in the protocol itself.

Under .gr we will continue to DNAME because the letters with a tonos sign
were decided not to be mapped to the letters without a tonos in the
IDNA2003, a fact that requires almost all of our IDN registered domain names
to be at least double, with a tonos and without one since all Greek word in
capital letters do not have the tonos but almost all the greek words in
lower case do. 

It seems to me that somebody decided back in 2003 that a best practice
document was better than resolving issues in the protocol itself. 

I would like to kindly ask you all if you honestly believe that any gTLD
would go as far for their registrants as we have and if the answer in "no"
please ask yourselves if the people that created the initial IDNA2003
haven't allowed phishing and fraud problems along with these other issues.
Unfortunately, this discussion of a best practice document for registries
really reminds me that history has the tendency to repeat itself.

Kind Regards,

Vaggelis Segredakis
Administrator of the .GR Top Level Domain
Institute of Computer Science
Foundation for Research and Technology - Hellas
Tel. +30-281-0391450
Fax +30-281-0391451
Email segred at ics.forth.gr


----------------------------
Date: Wed, 24 Dec 2008 11:43:31 -0500
From: Andrew Sullivan <ajs at shinkuro.com>
Subject: Re: Implementation questions (digressing from...)
To: idna-update at alvestrand.no
Message-ID: <20081224164331.GF19605 at shinkuro.com>
Content-Type: text/plain; charset=utf-8

On Wed, Dec 24, 2008 at 07:51:23AM -0800, Erik van der Poel wrote:

> >From my point of view, this is a leap of faith. I.e. hoping that zone
> operators at all levels of the DNS (not just TLDs) will bundle (or
> block) for eszett/ss.

As I've already argued, you _have_ to have that faith if you want the
current proposed protocol approach to work.  That is, if we're going to pull
mappings out of the middle of the protocol and push them out to the ends, on
the grounds that different circumstances demand different processing, then
we have to accept what moving the mappings entails.  One thing it entails is
an opening for possibly foolish behaviour on the part of zone operators.

This capacity for bad operation of a DNS zone is nothing new.
Significant portions of the DNS today only manage to operate because of
generous cache acceptance policies on the part of resolvers, without which
some zones would almost certainly go dark.  There are warnings in the
context of both CNAME and DNAMEs that long chains can be made circular, and
that you had better be pretty careful not to do that; but operators still
manage to do it.  I anticipate that there will be operators who allow the
"same" label spelled with "ss" and "?"
to resolve to different hosts.  I think that will be too bad.  I also think
there is nothing we can really do about that in the proposed protocol,
without reopening the question of the deep assumption of where mappings
ought to happen.  We can't have this both ways.  

The best we can do is tell people to be careful, and suggest different ways
that they can do that.  I think DNAME is probably more appropriate than
CNAME in many but not all of these cases, for instance.  Also, keep in mind
that anything we insist on probably brings with it more restrictions than
maybe we want.  For instance, MX records can't point at a CNAME.  Do we
really think it a good idea to open the DNS operation can of worms as part
of our effort to settle on this protocol?  Advice for what we think is sane
is, I think, not a bad idea.  But the closer we get to "SHOULD" or "MUST",
the more I see a bottomless rathole in our future.

A

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


------------------------------




More information about the Idna-update mailing list