Re: [ire] Variant Domain Names

[Gustavo Lozano <[e-mail]>]

James,

On version 02, the IDN variants model for data escrow was updated based on feedback from the list, private emails and internal discussions.

Suppose café.example is a mirroring variant for cafe.example.

Following the current version of the draft the registry would escrow:

<rdeDom:domain>
<rdeDom:name>xn--caf-dma.example</rdeDom:name>
<rdeDom:originalName>cafe.example</rdeDom:originalName>
......
</rdeDom:domain>

I'd propose a slight change from version 01 draft to be incorporated in the next version of the data escrow mappings specification as follows:

   <rdeNNDN:NNDN>
     <rdeNNDN:aName>xn--caf-dma.example</rdeNNDN:aName>
     <rdeNNDN:originalName>cafe.example</rdeNNDN:originalName>
     <rdeNNDN:nameState>mirrored</rdeNNDN:nameState>
     <rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
   </rdeNNDN:NNDN>

The proposal is that nameState=mirrored would mean that the NNDN is a mirrored variant, i.e., the NNDN name implicitly has the same data as the originalName. The other two states mentioned in the Integrated Issues Report on IDN variants are not needed since the registry would need a domain object to include data fields that diverge from those in the orginalName.

An optional attribute "noNSmirroring" would mean when true, that mirroring is NOT based in the default NS mirroring.

Default NS mirroring means:
* If the originalName is present in the DNS zone file, the NNDN mirror variant name (NNDN:aName) is also present in the DNS zone file with the same NS as the original name.
* The Registry MUST satisfies glue record requirements of the mirrored variants in the escrow deposit, but the Data Escrow Agent does not verify this.

Whether mirrored DNAME (or something else?) is used, will have to be discovered by analyzing the DNS zone file and/or reviewing the relevant IDN policy.

Just to clarify, the blocked and withheld states can be used not only for IDN variants. There are registry services that may require these states. The mirrored state would ONLY be used for IDN variants.

NNDN and Domain objects variants are explicit variants.  Algorithmically generated variants are generated based in the IDN policy document referenced by urlPolicy.

Comments are welcome.

Regards,
Gustavo

From: James Mitchell <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 9, 2013 9:02 AM
To: Bhadresh Modi <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ire] Variant Domain Names

Apologies, I was intending to use the term "activated". I have "allocated" on my mind from the launch discussions..

Thanks,
James

From: Bhadresh Modi <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 9 April 2013 3:06 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ire] Variant Domain Names

More precise terms are certainly helpful, I think the main point is that the current set of "blocked" and "withheld" as shown in the draft is insufficient.

Perhaps it makes sense to simply use the same terms with the same definitions from the IDN TLD project that Andrew provided.

Regards,
Bhadresh

On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan <[e-mail]<mailto:[e-mail]>> wrote:
I have no idea how those terms got adopted, but I'd like to point out
the distinctions that were made by the variant issues project/IDN TLD
project:

Delegated: actually in a zone with an SOA and parent NS RRset.

Activated: in the DNS somehow.  (Delegated is a species of activated.
For instance, a DNAME would be activated but not delegated.)

Allocated: someone has administrative control over the name, but it is
not activated.  For instance, any domain on Hold in EPP would be
allocated.

Blocked: nobody is allowed to register the name.  For instance, in
.com nobody may register the label example (so example.com<http://example.com> is
blocked).

I think these distinctions are all extremely useful.

On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote:
> I agree - we were using the "allocated" value in the previous revision to
> differentiate between IDN variants that simply blocked registration and
> variants that would actual resolve similar to the original domain name.
>  With the omission of this value there is no longer any way to express this.
>
> Regards,
> Bhadresh
>
>
> On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell <
> [e-mail]<mailto:[e-mail]>> wrote:
>
> > Gustavo,
> >
> > I would like the nameState of NNDNs to include "activated". The
> > "allocated" value was in revision –01, however seems to have disappeared
> > without reason? Adding "allocated" would make the NNDN consistent with the
> > text in Section 6 that states that either domain objects or NNDNs may be
> > used to represent variants.
> >
> > Also, the NNDN <crDate> should be optional as some registries may not
> > track the creation date of reserved list entries.
> >
> > Regards,
> > James
> >
> >
> > _______________________________________________
> > ire mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/ire
> >
> >

> _______________________________________________
> ire mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ire


--
Andrew Sullivan
[e-mail]<mailto:[e-mail]>
_______________________________________________
ire mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ire