[ssac-gnso-irdwg] Actions/Discussion Points: IRD-WG 15 February Meeting

[Julie Hedlund <julie.hedlund@xxxxxxxxx>]

Dear IRD-WG members,

Below are the action items and main discussion points from the 15 February 2010 
meeting of the IRD-WG.  These also are on the wiki at: 
https://st.icann.org/int-reg-data-wg/index.cgi?internationalized_registration_data_working_group
 
<https://st.icann.org/int-reg-data-wg/index.cgi?internationalized_registration_data_working_group>
 .   Please let me know if you have any changes or questions.  Our next meeting 
is scheduled for Monday, 01 March at 1900 UTC, 11:00 PST, 14:00 EST, 19:00 
London, 20:00 CET; 02 March: 03:00 Beijing, 04:00 Japan, 08:00 New Zealand.

Note:  Please let us know if you plan to attend the ICANN meeting in Nairobi as 
we may consider holding a face-to-face meeting there, depending on the number 
of WG members who are present.

Best regards,

Julie

Julie Hedlund, Director, SSAC Support

Attendees: Jeremy Hitchcock, Jim Galvin, Robert Hutchinson, Yao Jiankang, and 
Steve Metalitz; From staff: Gisella Gruber-White, Julie Hedlund, Dave 
Piscitello, and Steve Sheng

Actions/Discussion: During Monday's call we discussed several considerations 
for accommodating "internationalized" registration data. We attempted to 
decompose registration data into several individual and sets of data objects:
1) Domain name
We have agreed that the IDN A-label and U-label encodings are sufficient and 
necessary and no further encodings are needed.   In the call two weeks ago, WG 
members agreed that registrars / registries should accept both U-label and 
A-label queries, and return results both in U-label and A-label. In cases where 
there are bundled domains, querying one domain in the bundle should return all 
other domains in the bundle.
2) Registrar information
This includes the sponsoring registrar, status, creation/update/expiration 
dates. WG Members on the call agreed on the following points.

 *   This is information that is administered by the registrar (and registry);
 *   GTLDs today largely capture this information in "English/ASCII7";
 *   Certain ccTLD operators display this information in local languages;
 *   ccTLDs have their own practices and it is the hope of this WG that that 
the recommendations of this WG be considered by ccTLDs as well;
 *   There is value in continuing to make this information available in 
English/ASCII7 for abuse reporting, especially if "sponsoring registrar" could 
be used to obtain an abuse point of contact via ICANN or some other list of 
POCs; and
 *   This set of data objects is perhaps a good example of one that could be 
always available in English/ASCII7 and also published by registrar Whois using 
characters of a local language.

3) Telephone and fax numbers
This is information for which international standards/conventions exist and 
these should be applied. Steve Sheng studied this a bit further and summarized 
the current state as follows: WG members on the call agreed to use E.123 
(http://en.wikipedia.org/wiki/E.123), the ITU standard for printed 
representation of internationalized notation for telephone numbers, e-mail 
addresses and Web addresses as a standard to display the telephone numbers in 
Whois. The telephone numbers should be displayed in international notation (+31 
42 123 4567). The WG did not make recommendations on how registrars should 
store these data, but noted that some registrars or registries may have to 
convert their registrant phone numbers to this format.
4) Email addresses
WG members on the call thought that that the IRD should consider the IETF’s 
work on internationalizing email address 
(http://www.ietf.org/dyn/wg/charter/eai-charter.html). Steve Sheng, Yao 
Jiankang, and Jim Galvin are studying the relevant RFCs of the IETF working 
group on internationalized email (RFC 4952, 5335, 5336, 5337, 5504) and will 
report to the WG via the mailing list.
5) Contact information
WG members on the call agreed on the value of treating all the data associated 
with a contact's real world, postal/street address as a set of data objects. 
They agreed that there should be no mixed scripts in the contact information.  
Specifically, the WG members discussed applying criteria similar to IDN label 
composition to data such as "street address," "post office box," "city," 
"state," "province," and "country."   WG members discussed whether this meant 
that no provision would be made for also providing a "plain ASCII" version of 
contact information.  WG members agreed that prohibiting mixed scripts did not 
exclude the possibility of making full contact information available in 
characters from a local language/script and a separate but equally full contact 
information in ASCII characters as well. This is a separate, ongoing 
discussion.  Some WG members suggested that we use UTF-8 as the encoding but 
this needs to be discussed further.