Subject: [ire] Variant Domain Names

From: James Mitchell <[email-masked]>
Date: Mon, 8 Apr 2013 17:29:02 +1000

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

---

From: Bhadresh Modi <[email-masked]>
Date: Mon, 8 Apr 2013 12:07:18 -0400

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 <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire
>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Apr 2013 12:49:04 -0400

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 is
blocked).

I think these distinctions are all extremely useful.

-- 
Andrew Sullivan
[email-masked]

---

From: Bhadresh Modi <[email-masked]>
Date: Mon, 8 Apr 2013 13:06:02 -0400

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

---

From: James Mitchell <[email-masked]>
Date: Tue, 9 Apr 2013 11:02:50 +1000

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

Thanks,
James

From: Bhadresh Modi <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 9 April 2013 3:06 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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:

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

On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote:
> [email-masked]<mailto:[email-masked]>> wrote:
>
> > Gustavo,
> >
> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

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

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 9 Apr 2013 14:57:15 -0700

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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 9, 2013 9:02 AM
To: Bhadresh Modi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ire] Variant Domain Names

Thanks,
James

Regards,
Bhadresh