ICANN ICANN Email List Archives

[ssac-gnso-irdwg]


<<< Chronological Index >>>    <<< Thread Index >>>

[ssac-gnso-irdwg] Re: Variants

  • To: Edmon Chung <edmon@xxxxxxxxxxxxx>
  • Subject: [ssac-gnso-irdwg] Re: Variants
  • From: Dave Piscitello <dave.piscitello@xxxxxxxxx>
  • Date: Mon, 26 Jul 2010 05:47:37 -0700

Edmon,

Thanks for the clarification.
Yes I agree that getting views of ccTLDs would be important. Let's talk
about ways to do this.

Regards,

Dave


On 7/25/10 9:54 PM  Jul 25, 2010, "Edmon Chung" <edmon@xxxxxxxxxxxxx> wrote:

> Hi Dave,
> 
> It may be an appropriate recommendation for 2nd (or 3rd) level registrations
> as well.  Think the issue requires some further discussion though because I
> am more familiar with CJK situations, but not other languages, so am not
> sure if the same would appropriately apply to others.  From what I
> understand for Arabic and Indic domains though, such an approach would
> probably be appropriate too.  Am just saying that it may require further
> deliberations.
> 
> Also, the views of ccTLDs would be important if we are to "recommend" such a
> policy for all TLDs.
> 
> Edmon
> 
> 
> 
> 
>> -----Original Message-----
>> From: Dave Piscitello [mailto:dave.piscitello@xxxxxxxxx]
>> Sent: Tuesday, July 20, 2010 10:39 PM
>> To: Julie Hedlund; Edmon Chung; Steve Sheng; Greg Aaron; Jiankang YAO; Ram
>> Mohan
>> Cc: Jeremy Hitchcock; Ird
>> Subject: Re: Variants
>> 
>> Edmon,
>> 
>> This is an interesting insight, thanks.
>> 
>> Should we worry about adding complexity or opportunities for obfuscation
> for
>> second level label WHOIS (<label>.<TLD>)?
>> 
>> The policy you recommend for IANA seems like a good policy with regard to
>> tracking abuse. For example, if I'm writing automation to parse and
> analyze
>> WHOIS records, I think it's valuable to know that the primary is always
>> displayed (and distinguished as primary), that variants are displayed as
>> separate fields, and that the delegation is always considered to be one
>> record.
>> 
>> Can you comment on why this might be overly restrictive?
>> 
>> 
>>> On 7/19/10 8:05 PM, "Edmon Chung" <edmon@xxxxxxxxxxxxx> wrote:
>>> 
>>>> As a matter of broad policy, strict requirements may not be
> appropriate, i.e.
>>>> as in specifying exactly which variants MUST be displayed and how.
>>>> As you have pointed out, it is possible that different countries would
> have
>>>> different needs for the issue.
>>>> 
>>>> In general however, I would think delegated variants (i.e. those in the
>>>> zonefile) should be included, and that might be a good recommendation.
>>>> 
>>>> It is also possible to envision displaying part of the language table
> (e.g.
>>>> the rows for the characters involved), or have a link to the table so
> that
>>>> interested users can further check what else would be reserved.
>>>> 
>>>> For the IANA whois however, I think we should/could make some specific
>>>> policy.
>>>> At this time, I think the handling of .中国 (.XN--FIQS8S) and .中國
> (.XN--FIQZ9S)
>>>> is simply wrong.  They appear to be 2 separate entries in the IANA
> whois and
>>>> neither mentions the other.  For IANA whois:
>>>> 1. the primary ("base" or "submitted" or "applied for") should always
> be
>>>> displayed as the "Delegation Record for" field
>>>> 2. there should be a field to display the delegated variant(s)
>>>> 3. user should be able to query the whois by the primary or the variant
> (and
>>>> end up at the same record)
>>>> 4. the delegation should be considered to be one record (instead of 2
> chinas)
>>>> 
>>>> Edmon
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From: Steve Sheng [mailto:steve.sheng@xxxxxxxxx]
>>>> Sent: Tuesday, July 20, 2010 7:19 AM
>>>> To: Greg Aaron; Yao Jiankang; Ram Mohan; Steve Sheng; Edmon Chung
>>>> Cc: Jeremy Hitchcock; Julie Hedlund; Dave Piscitello
>>>> Subject: Re: Variants
>>>> 
>>>> Dear all,
>>>> 
>>>>   Thank you for your support for the IRD working group, particularly on
> the
>>>> issue of variants. I would like to engage you in the background and see
> if we
>>>> could come up with some good solution.
>>>> 
>>>>   I know Greg is not part of the IRD working group, but I would like to
>>>> include you since you have been most active in discussions on this
> topic.
>>>> 
>>>>   In our slides for Brussels, we have put forth the following proposal:
>>>> a) WHOIS port 43 clients must be able to accept a user query of domain
> name
>>>> in
>>>> either U-label or A-label;  b) WHOIS clients must be able display
> result of
>>>> queries in both U- and A label for the domain names; and  c) Bundled
>>>> representation of a single A or U-label query should be returned.
>>>> 
>>>> By bundled representation, we mean variants.
>>>> 
>>>> Greg raised an issue about supporting variants in Indian languages,
> that
>>>> there
>>>> may be tens and potentially hundreds of variants for a given U-label.
> The
>>>> Chinese situation is similar, since the Chinese IDN label allowed
> mixing of
>>>> traditional and simplified scripts, the number of variants can easily
> reach
>>>> ten.
>>>> 
>>>> For a given domain, CNNIC only put two types of variants into DNS, all
>>>> traditional and all simplified and reserved the rest. If we use this
>>>> approach,
>>>> we could require WHOIS to display the variants that are available in
> the DNS.
>>>> 
>>>> This seems to solve the problem for display, but what about query? Can
> a user
>>>> query any of the variant for a Chinese domain, and get the simplified
> and
>>>> traditional variant back? Is that satisfactory?
>>>> 
>>>> Coming back to the Indian language, would the above solution work? A
> query of
>>>> any of the variants for an Indian domain would return variants only in
> the
>>>> DNS
>>>> table.
>>>> 
>>>> Warmly,
>>>> Steve
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 6/24/10 12:22 PM, "Greg Aaron" <gaaron@xxxxxxxxxxxx> wrote:
>>>> A query for a reserved variant could return a result in WHOIS, perhaps
>>>> listing
>>>> the parent domain’s WHOIS data.
>>>> However, if one looks up a parent, WHOIS output should not necessarily
> return
>>>> the parent’s data PLUS a listing of all active and/or reserved
> variants.  (To
>>>> do so could create an exceptionally long output, as per some of the
> scenarios
>>>> I mentioned below.)
>>>> 
>>>> Some registries might handle variant activation and/or resolution
>>>> differently.
>>>> Which might be a perfectly reasonable and allowable implementation.
> Worth
>>>> checking out how practice might vary while being within RFCs and IDNA.
>>>> 
>>>> All best,
>>>> --Greg
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From: Yao Jiankang [mailto:yaojk@xxxxxxxx]
>>>> Sent: Thursday, June 24, 2010 10:21 AM
>>>> To: Greg Aaron; 'Steve Sheng'
>>>> Cc: 'Dave Piscitello'; 'Edmon Chung'; 'Jeremy Hitchcock'; 'James M
> Galvin
>>>> (Afilias)'
>>>> Subject: Re: Variants
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> the current practice for cnnic is that we list the variants which are
> put
>>>> into
>>>> dns.
>>>> 
>>>> sometimes three variants, sometimes two variants.
>>>> 
>>>> 
>>>> 
>>>> as far as I know, .AU will put all variants into dns. so the whois
> should
>>>> list
>>>> all variants.
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>> 
>>>> From: Greg Aaron <mailto:gaaron@xxxxxxxxxxxx>
>>>> 
>>>> To: 'Jiankang YAO' <mailto:yaojk@xxxxxxxx>  ; 'Steve Sheng'
>>>> <mailto:steve.sheng@xxxxxxxxx>
>>>> 
>>>> Cc: 'Dave Piscitello' <mailto:dave.piscitello@xxxxxxxxx>  ; 'Edmon
> Chung'
>>>> <mailto:edmon@xxxxxxxxxxxxx>  ; 'Jeremy Hitchcock'
>> <mailto:jeremy@xxxxxxx>  ;
>>>> 'James M Galvin (Afilias)' <mailto:jgalvin@xxxxxxxxxxxx>
>>>> 
>>>> Sent: Thursday, June 24, 2010 7:17 PM
>>>> 
>>>> Subject: RE: Variants
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Notes:
>>>> 
>>>> ・         If you look up a domain, should the WHOIS output also list
> all the
>>>> variants?
>>>> 
>>>> 
>>>> 
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 9.0.839 / Virus Database: 271.1.1/3010 - Release Date:
> 07/19/10
>>>> 14:36:00
>>>> 
>> 
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.851 / Virus Database: 271.1.1/3010 - Release Date: 07/21/10
> 02:36:00
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy