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

Klaus Malorny <> Mon, 12 May 2014 16:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E10101A034E for <>; Mon, 12 May 2014 09:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DMsqCnKlcgO1 for <>; Mon, 12 May 2014 09:13:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2DB421A033E for <>; Mon, 12 May 2014 09:13:32 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id 268F74D; Mon, 12 May 2014 18:13:25 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from ([]) by localhost ( []) (amavisd-new, port 10004) with ESMTP id D+SdzP4XxnVT; Mon, 12 May 2014 18:13:18 +0200 (MESZ)
Received: from ( []) by (Postfix) with ESMTP id B4B704C; Mon, 12 May 2014 18:13:18 +0200 (MESZ)
Received: from [] ( []) by (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s4CGDHe2029630; Mon, 12 May 2014 18:13:17 +0200 (MESZ)
Message-ID: <>
Date: Mon, 12 May 2014 20:13:04 +0200
From: Klaus Malorny <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1
MIME-Version: 1.0
To: "Gould, James" <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ire] question regarding IDN variant mapping, <orignialName> value
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 May 2014 16:13:35 -0000

On 12.05.2014 15:12, Gould, James wrote:
> Klaus,
> My feedback is embedded below.

Hi James,

> The data escrow needs to reflect the possible set of data models, where
> the only known model for related variants is a one-to-many relationship of
> OIDN to VIDN¹s as reflected in draft-kong-epp-idn-variants-mapping (
> ) with
> different levels of sharing (share all in your model #1 and NNDN, or share
> none or some in your model #2 and separate objects).

Well, to my knowledge, registries are not bound to data models that are 
published as RFCs or expired drafts ;-). Also, the Kong mapping is clearly an 
implementation of model #1, and this assumes that the OIDN remains constant -- 
otherwise, a domain "rename" would have to be implemented, like this can be done 
for the hosts. While this is not impossible, I haven't seen this in the wild...

> What you are
> referring to is a different model that reflects a many-to-many
> relationship with no concept of an OIDN, since all of the variants are
> sibling objects (A, B, and C are related to each other with no hierarchy).

Yes -- more or less -- as this is a matter of definition.

>  I¹m assuming that in your data model that you have some form of a link
> table to reflect the relationship.

This is still in the planning phase, however, there is no dedicated object or 
attribute whatever planned that is publicly visible.

>  Are all related variants authorized to
> a single registrant?  Does your system need to ensure that any of the
> attributes remain the same, like the registrar and registrant, across the
> related variants?

Yes, contacts need to be the same, and this constraint is enforced after the 
creation of the variants. You can take the Canadian registry (CIRA) as a prototype.

>  From an EPP perspective, do you have a custom EPP
> extension to reflect the related variants, and if so can you reference it
> to help clarify things?

Yes, there will be an extension, but it will only occur in responses, not in 

> The data escrow is a representation of a data model, and it only makes
> sense to ensure that all object references exist.  Your proposed language
> change defines a new variant group entity or tag that does not match the
> existing supported data model.  To support your data model of a
> many-to-many relationship, a new entity (or tag) "variant group" would
> need to be defined.  Instead of using the <originalName> element to refer
> to a domain object (OIDN), something like <variantGroup> would be needed
> to reference a variant group entity or be used to tag the variant group
> string.  If <variantGroup> is a reference to an actual entity with
> attributes, I¹m assuming that the variant group entity would be removed
> once all variant references are removed. Are there other registries out
> there that support a many-to-many relationship for variants?

The proposal to concretize the <originalName> attribute in a manner that is 
compatible with our intended/the French model was simply meant to keep the 
effort low. I don't mind adding a new attribute of whatever name to the escrow 
format if this is considered the better way. However, I would like to avoid a 
separate new object type to which the "variantGroup" attribute is referring. 
Simply take it as the "city names on the map of domain names", figuratively 
spoken ;-) -- you won't link contact objects of persons living the same city to 
a "city" object in the escrow, just because they share that property...