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

[Klaus Malorny <[e-mail]>]

On 09.05.2014 20:40, Gould, James wrote:
> Klaus,
>

Hi James,

thanks for answering.

>
> I view A as the OIDN and B as the VIDN, where if A is deleted, B should also be
> deleted.  There could be a pre-condition that VIDN's (B) be disabled or deleted
> prior to allowing the OIDN to get deleted.  That means that no orphan VIDN’s
> should exist when deleting the OIDN.  If deleting the OIDN deletes all VIDN’s
> then they would be deleted together.  I would imagine that domain C would only
> be allowed as a VIDN of A.  If not, I would need to better understand the
> registry logic for variants.

But why this restriction? The advantage of the "object model" over the 
"attribute model" is -- besides the ability to have different name servers 
and/or DNSSEC data -- that you only have a loose bundling. Also, in some 
scripts, you don't have a variant that is "original". If you have two variants 
which have equal value, what makes the one the "original" and the other not? For 
example, we have this situation with the Chinese traditional and simplified 
ideographs and also with Arabic letters. Why should a registrant, who has 
registered A at first and then B, shall not be able to give up variant A at a 
later point in time, while keeping variant B?

Maybe I miss something, but while I think it is at a registry's discretion to 
use a policy as you describe, I do not see neither technical nor procedural or 
legal needs for such constraints.

> Although the draft does not explicitly define that the <originalName> must
> exist, the existence of referenced entities should be expected throughout the
> draft.  The same could be stated for the <domain:hostObj> or <rdeDom:contact>
> references, but I believe it is expected that the referenced hosts or contacts
> must already exist.
>
> I view the OIDN’s to have a containment relationship with the VIDN’s in both
> your models, where the only difference is whether the domain attributes are shared.

I think it is not within the authority of the escrow format to enforce such a 
policy. I therefore propose to define the <originalName> as follows:

   1) The "original name" is a FQDN (as defined in the draft).
   2) The "original name" identifies a group of domain names that are
      considered to be variants of each other.
   3) The "original name" does not need to refer to an existing domain object.
   4) If the "original name" is not given with a domain, it is implicitly the
      name of the domain. This rule does not apply to NNDNs.

Rule 4) assures the compatibility to registry models where a "primus inter 
pares" exists (i.e. the OIDN in your description) and the "original name" is not 
generated in escrows for these objects.

> JG
>

Regards,

Klaus