Re: [ssac-gnso-irdwg] Open discussion: what do we require from IRD?

["YAO Jiankang" <yaojk@xxxxxxxx>]

----- Original Message ----- 
From: "Dave Piscitello" <dave.piscitello@xxxxxxxxx>
To: <ssac-gnso-irdwg@xxxxxxxxx>
Sent: Thursday, January 07, 2010 1:20 AM
Subject: [ssac-gnso-irdwg] Open discussion: what do we require from IRD?


> 
> As agreed during the 4 January 2009 teleconference, I'm opening discussion
> on the topic of requirements for internationalized registration data. The
> initial set of questions is reproduced below. The goal of this discussion
> thread is to invite WG members to comment/elaborate on the set of questions
> posed so that staff can produce a working draft document that provides
> indication of support of requirements, more clarity on the nature of each
> requirement, and rationale for including the requirement for future
> registration data access.
> 
> Please post to the list. Where the questions below appear to ask for a
> yes/no answer, please offer your perspective/supporting rationale.
> 
> Thanks very much!
> 
> Dave
> 
> 1) What do we require from internationalized registration data?
> 
>   a) that a user can submit or have a domain name displayed in
>      the IDN A-label (xn--) format or U-label (local language
>      readable) format?


I prefer U-label. The default format should be U-label. Many "xn---weqasdf 
asdf" format name is not valid IDN.

Based on IETF IDNA standard, whether A-label (xn--) format or U-label is 
submitted, we should use some algorithm to confirm whether it is a valid IDN.


> 
>   b) that registration data be extensible to accommodate users
>      who would benefit from the ability to submit and have registration
>      information displayed in "familiar" characters from local
>      languages and scripts?

yes, that is why we use internationlized whois.

> 
>   c) Does (b) imply several representations of the same registration
>      data, but in different languages or scripts?

no. It means that the local languages are compulsive.

> 
>      i) Related to c), and to avert a possible Babel effect,
>         is it desirable to adopt a "must be present"
>         representation with optional collection/display of
>         registration data for the convenience of "local users"?

both English and local language are necessary.



> 
>      ii) Related to i), should we consider adopting a
>          "format for civic address information that's reasonably
>           functional around the globe"?
>           (cf. Thomas Roeffler, in his reply to Steve Crocker)


we may follow the EPP RFC about contact address.


> 
>      iii) Related to c), is it possible to adopt an ICANN policy
>          that both meets the expectations and needs of internet
>          users around the globe and has a high probability of
>          adoption by ccTLD operators as well?

ICANN policy is useful.


> 
>   d) that registration data be collected and displayed (or returned
>      via a whois/port 43 or successor protocol) *uniformely*, in manners
>      that would allow applications to process the data efficiently? 

of course.


>In
>      particular, should applications that do not involve
>      humans (automation) not be complicated by variations across
>      display/collection practices/policies by registries and registrars?

easy one is better.

> 
>   e) that some filtering or processing be considered to reduce the
>      opportunity for deception/misuse when characters from
>      multiple scripts are used in the composition of certain
>      registration data? 


if all data are requested to use UTF8, that should be no problem.


>While perhaps not a perfect fit, are the
>      prohibitions of mixed-scripts in the IDN guidelines that
>      applied to labels of a domain name representative of
>      the opportunities we might attempt to define?.

prohibitions of mixed-scripts is necessary.


>     
> 
> 2) What should the registration data look like?
> 
>  a) some form of tagging of the data to identify the piece (object),
>     i.e., "this is a contact address"
>     Using XML, for example, such a tag and the data might look like
>     <contact-address>3 Myrtle Bank Lane</contact>

XML is good.

> 
>  b) alternatively, tagging of blocks of data where a group of objects
>     such as an administrative contact would be tagged
>     Using XML, for example, such a tag and the data might look like
>      <admin-contact>
>         David Piscitello
>         3 Myrtle Bank Lane
>         Hilton Head SC 29926
>         ...
>       </contact>

I prefer the following format

      <organization> CNNIC</organization>
      <address>
         <postal>
            <street>No.4 South 4th Street, Zhongguancun</street>
            <city>Beijing</city>
           </postal>
         <phone>+86 10 58813007 </phone>
         <email>yaojk@xxxxxxxx</email>
      </address>




> 
>  c) some means to identify the language or script that the characters
>     in the data "belong to"

that will be better since it will allow the user to easily identify the whois 
data language used.


> 
>  d) should some elements of registration data always be represented
>     in US-ASCII7 (e.g., sponsoring registrar)?

agree. such as telephone number.

but the email address is not in this category since there will have an 
internationalized email address soon.



*****

another issue for internationalized data is security issues.

if all whois data are uniformed, it not only convient to the normal internet 
users but also to the misusers who may easily get the information they want to 
do some offensive things.


is security issue in the scope of our WG?




> 
>