Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment

On Fri, Feb 11, 2011 at 06:17:16PM +0200, Vaggelis Segredakis wrote:
> As the Greek registry, offering registrations in Greek characters presented
> the problem with the accent mark "tonos" which is used in the majority of
> Greek words. In capital letters however, the same words are spelled without
> the tonos. Their representation in the Punycode is unfortunately different
> and we had to match these up (make similar) for the user, otherwise the user
> experience of case-insensitivity would be lost. We used the DNAME mechanism
> with not very satisfactory results.

The previous version of the document used your previous messages on
Greek as an example of the "bundling" requirement, however I can't
find any previous reference to specific problems you might have had
with DNAME. Could you elaborate?

> The revision of the IDNA protocol to IDNA2008 brought forward two other
> issues:
> 1. The mapping of the upper case letters to the lower case is no longer a
> feature of the protocol but rather a task of the application. This way we
> cannot have consistent mappings since we do not know what the programmer has
> chosen to do with the upper case characters, especially in regards to tonos
> and final sigma.

This uncertainty about what the application will do with "bundled"
names as far as treating them "the same" seems to be the underlying
concern that motivates all the discussion we've had about adding
functionality to the DNS to support the "sameness" property.

However, it's also been strongly argued here that there's no way to
support "aliases" in the DNS without application support, particularly
without introducing inconsistencies in handling of certificates and
other objects that rely on domain names. So the tension that needs to
be explained in the next version of the document is between the need
for providing this kind of "help" to applications, and the challenge
of getting them to use it.

> We are in favor of a solution of the BNAME type proposal. We do not intend
> to SHADOW the .gr zone to another one but we would really like to "make
> similar" a great number of IDN domain names that will have variants. This
> way, while a SHADOW would be helpful only to our registrants wishing to
> "make similar" the variants themselves we as a registry would like to
> provide to our registrants the easiest solution of not having to deal
> extensively with DNS. The registrant could just ask the registry to provide
> the "sameness" for the variants in the BNAME form.

The thing that worries me about this is that the registry can provide
BNAMEs, but if applications don't make use of the "sameness"
semantics, we haven't really gained anything....

> I hope that Olafur in his email on the 1st of February was mistaken
> when he declared the item "Aliasing Requirements" dead and a
> discussion will take place in the next DNSSEC meeting to initiate
> the solution procedure.

The requirements document is a WG item under the recent charter, and
it remains my intent (as I believe Olafur knows) to make sure the
document is completed as an Informational RFC in the near future. The
work item isn't done until the WG has decided one way or another
whether to pursue additional work on the subject, so I'll respectfully
disagree with Olafur's assertion.

Whether there's a meeting of DNSEXT in Prague or not, the WG version
of this draft will ship soon so we can continue the discussion.

best,
Suzanne
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext