[ire] question regarding IDN variant mapping, <orignialName> value

Klaus Malorny <Klaus.Malorny@knipp.de> Fri, 09 May 2014 14:07 UTC

Return-Path: <Klaus.Malorny@knipp.de>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525991A02BF for <ire@ietfa.amsl.com>; Fri, 9 May 2014 07:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level:
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNJ5_--kKaDg for <ire@ietfa.amsl.com>; Fri, 9 May 2014 07:07:40 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id EA5421A02D9 for <ire@ietf.org>; Fri, 9 May 2014 07:07:39 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3ECAF49; Fri, 9 May 2014 16:07:34 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 7UW4V9yktif5; Fri, 9 May 2014 16:07:26 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id D1DCE4A; Fri, 9 May 2014 16:07:26 +0200 (MESZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s49E7QSi002222; Fri, 9 May 2014 16:07:26 +0200 (MESZ)
Message-ID: <536CE129.4010004@knipp.de>
Date: Fri, 09 May 2014 16:07:37 +0200
From: Klaus Malorny <Klaus.Malorny@knipp.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1
MIME-Version: 1.0
To: "ire@ietf.org" <ire@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/i58p-bbHOafeTNeihxcueMXcWLw
Subject: [ire] question regarding IDN variant mapping, <orignialName> value
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire/>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 14:07:57 -0000


Hi all,

my colleagues and I came across a specific problem regarding of the handling of 
IDN variants in escrows, and we did not find a clear answer in the 
specifications[1].

As you might know, there are basically two models of how to treat IDN variants:

  1) as an attribute to a domain, i.e. variants are part of a single domain,
     the names are typically supplied via an EPP extension to the create
     and update commands. (example: .cat gTLD registry)

  2) as separate domain objects, i.e. for each variant, separate create and
     delete commands have to be issued to add or remove them. The registry
     may restrict operations so that two variants can not be associated with two
     different registrants and so on. (example: .ca ccTLD registry)

The specification provides an <originalName> element (in the XML form, a 
respective field in the CSV form) to link these variants to each other, both for 
the domain objects and for the NNDNs. While the latter is quite suitable to 
represent the model described in 1), the first is likely intended for the model 
described in 2).

The question now is, what does that field actually contain in the model 2)? Of 
course, a domain name, as the specification demands, but which one?

If it would need to be one of the existing variants, this would become a problem 
on an incremental update. For example, if we have the variants A and B, and B 
would point to A in the <originalName>: If A gets deleted, B remains factually 
unchanged, and would not be reported in an incremental escrow. When the data 
gets reconstructed (for example by an EBERO provider), the importer might find 
the reference to A, but not A itself, because its deletion was reported. Also, 
if a new domain C is registered that is a variant of A and B, it would likely 
point to B instead of the deleted domain A. This would also puzzle a potential 
importer.

On the other hand, the specification does not clearly define that the name which 
is specified by <originalName> needs to exist at all. One could declare one of 
the potential variants as a "generic", "canonical" variant, which is used for 
this field even if this variant itself is not registered. For example, if D 
would be this generic variant, and the variants A and B have been registered, 
they both would refer to D in the <originalName> field. Thus, if either A or B 
gets deleted, nothing would break. An importer would simply group domain names 
that refer to the very same name, whatever this is.

Any ideas, any opinions, any interpretations of the specs? This would be greatly 
helpful for us.

Regards,

Klaus




[1] https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05