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

"Gould, James" <> Mon, 12 May 2014 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 651AD1A077C for <>; Mon, 12 May 2014 10:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BeN8duxGuJOY for <>; Mon, 12 May 2014 10:52:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DAF401A0745 for <>; Mon, 12 May 2014 10:52:14 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Mon, 12 May 2014 10:52:10 PDT
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s4CHq8a1019744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 13:52:08 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Mon, 12 May 2014 13:52:07 -0400
From: "Gould, James" <>
To: Klaus Malorny <>, "" <>
Thread-Topic: [ire] question regarding IDN variant mapping, <orignialName> value
Thread-Index: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGAgAFWj4CAAwUEgIAAlswA//+3ToA=
Date: Mon, 12 May 2014 17:52:06 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="euc-kr"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 17:52:21 -0000


My feedback is below.


James Gould
Principal Software Engineer
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190

On 5/12/14, 2:13 PM, "Klaus Malorny" <>; wrote:

>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
>> 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
>> 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

I didn’t imply that the registries are bound to the OIDN and VIDN's data
model of draft-kong-idn-variants-mapping, but that a one-to-many
relationship was the only known relationship for variants.  Having a
primary OIDN that variants are enabled / disabled from is not as complex,
but it is certainly less flexible.

>> 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
>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
>> related variants?
>Yes, contacts need to be the same, and this constraint is enforced after
>creation of the variants. You can take the Canadian registry (CIRA) as a

When changing the registrant (update) or registrar (transfer), does the
entire group of variants get updated at once?

>>  From an EPP perspective, do you have a custom EPP
>> extension to reflect the related variants, and if so can you reference
>> to help clarify things?
>Yes, there will be an extension, but it will only occur in responses, not
>> The data escrow is a representation of a data model, and it only makes
>> sense to ensure that all object references exist.  Your proposed
>> 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
>> 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
>compatible with our intended/the French model was simply meant to keep
>effort low. I don't mind adding a new attribute of whatever name to the
>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
>Simply take it as the "city names on the map of domain names",
>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...

If the many-to-many relationship does not have any additional attributes
that need to be deposited, then <variantGroup> could be a simple data type
(token) that is a tag for the variant group without any linkage to an
entity / object.  It’s best to leave the intent and meaning of
<originalName> as is and simply add a new element to handle this case.
The CSV model would add the corresponding optional
<csvDomain:fVariantGroup> and <csvNNDN:fVariantGroup> elements.  Does this
work for you?