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

"Vaggelis Segredakis" <segred@ics.forth.gr> Fri, 11 February 2011 16:18 UTC

Return-Path: <segred@ics.forth.gr>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3A6083A69D1 for <dnsext@core3.amsl.com>; Fri, 11 Feb 2011 08:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id HxAhe7BKbCbM for <dnsext@core3.amsl.com>; Fri, 11 Feb 2011 08:18:06 -0800 (PST)
Received: from mailgate.ics.forth.gr (mailgate.ics.forth.gr []) by core3.amsl.com (Postfix) with ESMTP id 202173A68C0 for <dnsext@ietf.org>; Fri, 11 Feb 2011 08:18:01 -0800 (PST)
Received: from av1.ics.forth.gr (av1-in.ics.forth.gr []) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id p1BGI3Ba022938; Fri, 11 Feb 2011 18:18:05 +0200 (EET)
X-AuditID: 8b5b9d47-b7c88ae0000076fe-a5-4d55613b8969
Received: from enigma.ics.forth.gr (webmail.ics.forth.gr []) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 60.AA.30462.B31655D4; Fri, 11 Feb 2011 18:18:03 +0200 (EET)
Received: from Thanatos (thanatos.ics.forth.gr []) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id p1BGI0pQ001245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 11 Feb 2011 18:18:00 +0200
X-ICS-AUTH-INFO: Authenticated user: segred at ics.forth.gr
From: "Vaggelis Segredakis" <segred@ics.forth.gr>
To: "'Suzanne Woolf'" <woolf@isc.org>
References: <4D48617E.1020408@ogud.com> <3A5CD55E5CCE43F0BA44AAC89BADB866@ics.forth.gr> <20110211020125.GA147@bikeshed.isc.org>
Date: Fri, 11 Feb 2011 18:17:16 +0200
Message-ID: <F5CC3C0B5F464E63A4154F62B9BFFDD1@ics.forth.gr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20110211020125.GA147@bikeshed.isc.org>
thread-index: AcvJj6Zv6eRl6Yc5THmRTc30Rg8bJAAcU3zg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
X-Brightmail-Tracker: AAAAARdlQCA=
X-j-chkmail-Score: MSGID : 4D55613B.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
Cc: dnsext@ietf.org, 'Olafur Gudmundsson' <ogud@ogud.com>
Subject: [dnsext] draft-yao-dnsext-identical-resolution-02 comment
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2011 16:18:08 -0000

Dear Suzanne,

Having read your analysis in the document
draft-yao-dnsext-identical-resolution-02.pdf I would like to raise some
points of discussion.

The analysis was thorough and it explains very well the issues at hand for
the registries with variant IDN registrations. Although we have been advised
to create bundles or variants of domain names, their behavior was never
explained as a mechanism.

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 revision of the IDNA protocol to IDNA2008 brought forward two other
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.
2. The final sigma letter which is a representation of the small case sigma
when at the end of the word and not a letter by itself is represented in the
new protocol as a standalone character. This is good in a sense, since
almost all male names and surnames and numerous other words end in a final
sigma which was misrepresented. However -maybe you guessed it- the same
words, when spelled in upper case letters do not have a final sigma but
instead the normal one.

Your document has also raised the issue of "confusing similar visuality"
[Page 12] (Homographs) which although present in the Greek to Latin alphabet
similarities was solved by regulation and was not really a problem of DNS.
Our solution can be found at the address

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.

These are two completely different solutions and they have been asked by
different people for different cases. The word "similar" or "same" is
confusing but the needs presented are totally different. The SHADOW is a
request by registries that have multiple TLDs in different(?) character sets
and they want them to operate as one. The BNAME solution is suitable for a
TLD that wants to register variants and comply with the RFC3743 idea of
equivalence of labels and bundled names.

I would be very happy if your issue-analysis document turns into a solution
or even two, since these two are not even close, although BNAME would be a
solution even for shadow TLD zones as well, if it was to be used directly in
the root zone files.

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.

Thank you for your document and I look forward to your next draft. I would
be glad to assist in any way possible.

Vaggelis Segredakis

P.S. The http://users.isc.org/~woolf web site mentioned in the draft is not

-----Original Message-----
From: Suzanne Woolf [mailto:woolf@isc.org] 
Sent: Friday, February 11, 2011 4:01 AM
To: Vaggelis Segredakis
Cc: 'Olafur Gudmundsson'; dnsext@ietf.org
Subject: Re: [dnsext] DNSEXT progress and possible meeting at IETF-80

On Thu, Feb 10, 2011 at 04:11:54PM +0200, Vaggelis Segredakis wrote:
> We as the Registry of [.gr] domain names are still very much interested in
> the Aliasing Requirements item and the development of a "xNAME" identical
> tree solution.

This is good to know, as I am working on the -00 (WG item) of the
identical-resolution draft; it's behind schedule but definitely not

I expect to be in Prague and would work with you (or anyone
interested) there, as well as in email until then.

> We would be very happy to produce a comment of this document. If there is
> anyone else interested in that please feel free to contact me.

This would be helpful.