[ssac-gnso-irdwg] Re: Variants

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

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