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

[Klaus Malorny <[e-mail]>]

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 (
> http://tools.ietf.org/html/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 
commands.

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


Regards,

Klaus