1. Meetings

This is a list of the current and previous meetings of the Internationalized Registration Data Working Group.

Monday, 18 April 2011 (See Transcript and MP3)

Actions: Open a dialog on the mailing list on this proposal for a Final Report: Instead of recommending a particular model the IRD-WG should speak about the technologies that are important and relevant to this process (translation/transliteration) and call out the questions that need to be studied to develop a policy/PDP.

Notes:

Questions for Sarmad Hussain on his comments:

1. Comments on the four models and the WHOIS service

• Dave: Helpful to consider looking at the models in the context of who benefits and who is affected in terms of usability, and other parameters.
• Jim: Comments seemed to converge on the requirement to include the must be present script .
• Steve M.: Monolingual registrant — that is the status quo, isn’t it?  What do registrants do today?   Do they provide their contact data in ASCII script?
• Jim: Get more input from ccTLDs in particular — we don't say much about that in our interim report.  How much was done in talking to ccTLDs.  Started with a report from Dave on what ccTLDs were doing, and we got input from other ccTLDs.
• Dave: We reached out through the ccNSO to ascertain what character sets that they accepted — 17 or 18 responses.  We did not go back to see what user interface and what they accepted as submissions .
• Jim: Jay Daley suggested in San Francisco that a user has a right to be monolingual.  If we have the registrar doing the translation/transliteration then we have a problem with the quality of the data.
• Sarmad:  My main question: Who is providing the data and who is the owner?  Is is the registrar or registrant?  I am not sure that this is clear in the RAA.  This is a fundamental question that needs to be clarified.   If the registrant is providing the data then if there is translation or transliteration provided by anyone else then that could conflict with that fundamental principle.  If the registrant is monolingual then he/she would not be able to verify the translation/transliteration.
• Ram: Speaking from a registry operator’s perspective the data is owned by the registrar and provided to the registry on a contract.  The registrar is responsible for the registration data and owns it and is the only body that has the authority to change that data in the database.  We should not worry about who else owns the data.  It is stored in many places, but the registrar has the authority and owns it.   As far as the translation/transliteration: I am not sure that we should worry about that.  Access controls for that data are outside of the scope of what we are trying to do in this WG.  By access control I mean is who has the authority to change the data downstream.
• Jim: In the analysis of the comments IPC expressed concerns with compliance issues related to translation and transliteration from ICANN’s point of view. I think we could raise the question of who has responsibility for the data.  I think we could state what is existing practice — that the registrars have responsibility.   The comments from Network Solutions also suggested that the IRD-WG should consider the role of registries in the process.
• Steve:  I am concerned about the term “ownership,” which has certain legal meanings.  We are talking about responsibility.  I think your perspective depends on where you sit.  If you look at the RAA it is the registrant’s job to provide this information.
• Jim: To clarify: I think this group can call out the question of who is responsible for the data.  The registrars are the only ones who have authority to change it but they don’t take responsibility for the quality of the data.
• Edmon: Conceptually the end registrant “owns” that contact information but the fact that the registrar gives it to the registry should be balanced with ICANN’s policy role.
• Jiankang: The registry is only responsible for keeping the data safe; who has the responsibility to keep the data accurate?  The registration should be responsible for ownership and quality.
• Steve: Maybe we do need more information about how ccTLD’s and gTLD’s handle this today.  Should we ask registrars how they handle this today?  Maybe we could identify some registrars that are offering second level domains in non-ASCII scripts.
• Jim:  I think we should take that as a proposed action and ask for comments and consensus on the mailing list, but we need to be clear about what we want to learn from the survey.
• Edmon: I think a survey would be quite useful, but I would caution that the data that we do get back might be excluding those who are not in the system right now.

2. Sarmad’s second point: quality of translations/transliterations

• Jim:  We don’t state the we know who owns the data.  We will need to expand on that carefully in our report.  On the other hand I agree with you that if the quality of the data is the responsibility of the user, but there is an issue if the user cannot validate the translation/transliteration.
• Edmon:  I think Sarmad raised an interesting question, but it could be important for us to think about the quality of the supplied data versus the quality of the translation/transliteration.  The threshold of quality for translation/transliteration could be lower.  It depends on what we are going to use the data for.
• Jim:  We should at least call out the question even if we don’t answer it ourselves.

3. Sarmad’s Proposed New Model:

• Jim:  We need to think of a new way of drafting this final report:  Talk about the issues that go over all of the models rather than trying to emphasize one.  Highlight the questions and where they apply.  In Sarmad’s 5th model registrants should be able to provide the data in whatever way is appropriate to them but to make sure the data is tagged in such a way so that it could be translated or transliterated by others.
• Sarmad:  The quality of the translation/transliteration depends on who does it.  The model doesn’t make the registrar liable for inaccurate translation/transliteration.  Example:  Take a name — Mohammad, which can be spelled in many different ways.  What translation/transliteration is doing is potentially pointing law enforcement to the wrong person.
• Jim:  Rather than trying to recommend a particular model we need to raise these questions and look at several options, the first of which is that the registrant provides the translation/transliteration.  Also we should think about a clearinghouse option — to universally provide a translation/transliteration.  
• Steve S.: Is our goal is to decide on one model?  There will be a policy development process that would determine the policy.
• Jim:  Up until this call we have had consensus that we would choose a model, but after this call I have a different view on what the final report should look like.  I am not inclined to recommend a particular model.  We should speak about the technologies that are important and relevant to this process (translation/transliteration) and call out the questions that need to be studied to develop a policy.
• Edmon: I agree very much with you.  I think the direction is right.   I think the way you characterized the perspective is a better way to go than the models approach.  It ties well with what Steve Sheng is asking.  Is that this group would produce a document that would feed into a PDP type of discussion.
• Action: bring to the mailing list this approach.  Open a dialog on the mailing list.

Monday, 21 February 2011 (See Transcript and MP3)

Monday, 07 February 2011 (See Transcript and MP3)

Monday, 24 January 2011 (See Transcript and MP3.)

Monday, 20 December 2010 (See MP3 and Summary.)

Thursday, 09 December 2010 -- Public Session on Interim Report (See Audiocast and Summary.)

Monday, 22 November 2010 (See Transcript and MP3.)

Monday, 08 November 2010 (See Transcript and MP3.)

Monday, 01 November 2010 (See Transcript and MP3.)

Monday, 25 October 2010 (See Transcript, MP3 and Summary.)

Monday, 11 October 2010 (See Transcript, MP3, and Summary.)

Monday, 27 September 2010 (See Transcript, MP3, and Summary.)

Monday, 20 September 2010 at 1400 UTC (See Transcript, MP3, and Summary)

Monday, 30 August 2010 at 1400 UTC (See Transcript and MP3 and Summary)

Monday, 16 August 2010 at 1400 UTC (See Transcript, MP3, and Summary)

Monday, 02 August 2010 at 1400 UTC (See Transcript and MP3)

Monday, 12 July 2010 at 1400 UTC (See Transcript and MP3.)

Attendees: Rafik Dammak, Jeremy Hitchcock, Robert Hutchinson, Avri Doria, Jiankang Yao. Apologies: James Galvin, Steve Metaliz, Ram Mohan; Staff: Glen De Saint Gery, Gisella Gruber White, Steve Sheng, Dave Piscitello

Jeremy Hitchcock first summarized the presentations he gave on behalf of the IRD working group at Brussels: a 10 -minute update to the GNSO council and at the IRD workshop. He felt that the feedback was positive for our work.

Discussion Points from Brussels Meeting Presentation:

There were a couple of questions raised in Brussels. In the GNSO update, a question on “What PDP would come out of this?” was raised. In the IRD workshop, a question was raised on displaying variants in WHOIS. The working group discussed the variant issue. Steve Sheng first summarized the issue, that in some languages such as Indian and Chinese, there could be tens if not hundreds of variants. How should WHOIS handle these domain name variants in queries and in responses?

Jiankang mentioned that CNNIC use RFC 3743 (Guidelines for IDN registrations and Administration for Chinese, Japanese, and Korean) to manage variants. In particular, they display two variants in the DNS zone file, and reserve the rest for registration purposes. He propose that instead of displaying all the variants, WHOIS should display only the variants that currently exists in the DNS zone file. Some WG members have raised the question “although variants may be important for localized user experience, what’s the rational for displaying variant in global gTLDs or registrars?”

Issues Remain to be Addressed:

The WG members discussed a set of open issues that needs to come to closure. The first one is “Which of these approaches of for contact information should we adopt?” The WG members have discussed three possible models. Which of these should the WG adopt as a recommendation? The second question that was raised is whether we treat port 43 and web based WHOIS separately and have different requirements. This question is related to the fact that there is more language support in the web based WHOIS and also the HTTP protocol is also more encapsulated.

Next steps in Preparing Recommendations/Implementation plan?
--Jeremy suggested we should have a report completed, including some recommendations by November.
--Some WG members suggested that staff should start to prepare a report on each of these issues, first by turning the slide deck into a working document, and then by using it as a way to put together recommendations for each of these issues.
--Other WG members suggested that staff should pull out the open issues and present them as agenda items for discussion at next meeting.

Action items: Staff will prepare a report based on the slide deck from Brussels.

Monday, 07 June 2010 at 1400 UTC (See Transcript and MP3.)

Attendees: Rafik Dammak, Avri Doria, Edmon Chung, Jeremy Hitchcock, Bob Hutchinson, Steve Metalitz, and Jiankang Yao; from staff: Julie Hedlund and Steve Sheng.

Action Items: Staff will revise slides and send them to the WG for review. Done. See Draft IRD-WG Preliminary Approach Slides for ICANN Brussels Meeting

Brief Notes: The WG members discussed a very rough draft of slides for a presentation in Brussels on Thursday, 24 June in the public session. It was noted that the slides should include a description of the four models, as suggested by Jim Galvin, along with other changes. Steve Sheng and Julie Hedlund noted suggested changes and agreed to draft a revised set of slides. Jeremy Hitchcock agreed to give the presentation in Brussels.

Monday, 24 May 2010 at 1900 UTC (See Transcript, MP3, and Summary.)

Attendees: Rafik Dammak, Avri Doria, Jim Galvin, Jeremy Hitchcock, and Bob Hutchinson, Ram Mohan, and Owen Smigelski; from staff: Julie Hedlund and Steve Sheng.

Action Items: Staff will develop a draft preliminary approach for Working Group consideration as a basis for a public session in Brussels.

Monday, 10 May 2010 at 1400 UTC (See Transcript, MP3, and Summary.)

Attendees: Edmon Chung, Rafik Dammak, Jim Galvin, Jeremy Hitchcock, and Bob Hutchinson; from staff: Julie Hedlund, Dave Piscitello, and Steve Sheng.

Action Items: 1) Staff will outline a Model 4 along the lines suggested by Jim Galvin with assistance from Jim; 2) Staff will develop a draft preliminary approach for Working Group consideration as a basis for a Public Forum in Brussels.

Monday, 26 April 2010 at 1900 UTC (See Transcript, MP3, and Summary.)

Attendees: Edmon Chung, Bob Hutchinson, Owen Smigelski; from staff: Francisco Arias, Gisella Gruber-White, Julie Hedlund, Dave Piscitello, and Steve Sheng.

Action Items: 1) Edmon will send out a question concerning how transliteration will be handled; 2) staff will provide an example of what a WHOIS reply might look like if the Working Group recommended that both an ASCII-7 and UTF-8 (IRD) version of a record be returned (Done); 2) staff will assist the Working Group in developing a set of preliminary recommendations for a Public Forum at the ICANN meeting in Brussels.

Monday, 12 April 2010 at 1400 UTC (See Transcript, MP3, and Summary.)

Attendees: Rafik Dammak, Avri Doria, Bob Hutchinson, Andrei Kolesnikov, and Steve Metalitz; from staff: Dave Piscitello and Julie Hedlund.

Action Items: Based on the working group members’ comments the staff will revise the matrix and send an updated matrix for further review.https://community.icann.org/download/attachments/11995194/Copy+of+matrix-draft-revised+414.xls?version=1&modificationDate=1302025996000

Monday, 29 March 2010 at 1900 UTC (See Transcript, MP3, and Summary.)

Attendees: Edmon Chung, Co-Chair, Ram Mohan, Rafik Dammak, Avri Doria, Bob Hutchinson, Andrei Kolesnikov, and Owen Smigelski; from staff: Dave Piscitello, Julie Hedlund, and Steve Sheng.

Action Items: Based on the working group members’ comment as well as the comment received in the email list, the staff will revise the matrix, and send an updated matrix for further review.

https://community.icann.org/download/attachments/11995199/IRD-WG+Notes+29+March+2010+Meeting.pdf?version=1&modificationDate=1302026209000

Monday, 15 March 2010 at 1400 UTC (See Transcript, MP3, and Summary.)

Attendees: Jeremy Hitchcock, Co-Chair, James Galvin, Ram Mohan, Steve Metalitz, Jiankang Yao, Avri Dora; from staff: Dave Piscitello, Glen de Saint Gery, Francisco Aries, Steve Sheng.

Actions Items: ICANN staff will develop a matrix that identifies different models for registration data and the impact of each model on potential stakeholders.

Discussion Summary:
The staff first summarized the working group progress up to date. (See last meeting notes.) The staff also briefed the WG members on the relevant Universal Postal Union (UPU) standards (See the UPU standard email in the archives at: http://forum.icann.org/lists/ssac-gnso-irdwg/msg00081.html.). The staff pointed out that the UPU standards were presented as a principle or analogy since there is no direct comparison for postal addressing to Whois.

The Chair then asked the WG members to consider whether or not to use the UPU standard as a principle model for internationalized registration data (that requiring a “must be present” script, with the addition to other scripts). Members of the WG have expressed different opinions.

The staff pointed out that the original intent of looking at the UPU standard was to try to understand how the postal system dealt with local languages. The staff did not intend to suggest that the UPU standard was the only option that the WG members should consider.

Some WG members felt that the base requirement of having something that anyone in the world can understand is valid. In addition, they agreed it also would be useful to have a standard that was accessible to local users.

However, other WG members felt that UPU standard applies more in a peer-to-peer relationship, but the WHOIS model is a one-to-many relationship. Furthermore, if a letter is mailed within a country, then it is only necessary to provide the address in the local script. Similarly, today’s Whois frequently is used locally, in which case it would not be necessary to provide the information in anything other than the local script.

To assist in the IRD-WG’s deliberations on this issue, some WG members suggested that it might be useful for staff to develop a matrix that identified different models and their impact on potential stakeholders. The matrix could systematically explore different models proposed, their impacts on the registrars (both traditional and IDN), registries, registrant, and users of Whois (both human user and also legitimate automated clients).

The WG members participating in the call agreed that this was a good idea and asked the staff to move forward. The staff pointed out that this would be a qualitative exercise to examine the potential impacts and help to clarify alternative proposals. The WG members also asked the staff to consider both the primary effect and secondary effect to each of the stakeholders.

Several models will be considered initially:

Model 1: Requiring registrants to provide a “must be present” language to Whois, and in addition give the option to provide data in local languages as well.

Model 2: Registrants provide their registration data in a script that can be accepted by the registrar, and registrar to provide a point of contact for translation and abuse issues based on request.

Model 3: Registrants provide their registration data in a script that can be accepted by the registrar, and registrar provide translation service and publish it in a “must be present” language in Whois.

Monday, 01 March 2010 at 1900 UTC (See Transcript and MP3.)

Attendees: Edmon Chung, Co-Chair, James Galvin, Lisa Lennon, Owen Smigelski; from staff: Steve Sheng, Glen de Saint Gery and Julie Hedlund. Apologies from: Eric Iriarte Ahon, Jay Daley, Rafik Dammak, Yao Jiankang, Mark Kosters, Steve Metalitz, and Ram Mohan

Actions Items: Staff will provide more information about the UPU standard.

Discussion Summary:
The staff first summarized the working group progress up to date to the new working group members. Members of the working group then deliberated on the issue of internationalizing registrant information and postal addresses. The question discussed was, “is it desirable to adopt an English representation of data, in conjunction with local character set support with regard to registrant information and mailing address?”

Staff summarized WG members’ position on this question in past deliberations, that
--Requiring a English representation may present a barrier to those who do not know English.
--Requiring a English representation may be necessary to contact registrants from different countries.

Various members expressed their opinions on this issue:
--Some felt that registrants should not be required to know English to register a domain, and expressed concern that if we require English in Whois, who is going to translate and how do we make sure that translation is sensible and correct.

The WG discussed how should move forward on this particular issue:
--Edmon Chung, Co-Chair, wondered whether a useful way forward would be to consider whether a internationalized Whois should have backward compatibility with ASCII.
--Some WG members suggested the next step forward is to list all available options, and deliberate on the pros and cons of each. One option is not requiring registrants input English, but requiring registrars to publish points of contact to deal with translation issues, or for registrars to perform translation.

The WG members also discussed the UPU standard for international addressing: Background: Article RL 123.3.3 specified that "The addressee's address shall be worded in a precise and complete manner. It shall be written very legibly in roman letters and Arabic numerals. If other letters and figures are used in the country of destination, it shall be recommended that the address be given also in these letters and numerals.” (Annex 2, http://www.upu.int/post_code/en/addressing_and_postcode_manual_en.pdf) Essentially this is requiring mailing addresses in roman letters and they optionally be put into scripts of country of destination as well.

Other Discussions:
Some WG members noted that in the IETF working group of email address internationalization (EAI), there is a concept of downgrading from internationalized names, and that downgrading would require a handshake protocol that may not be possible for Whois.

Monday, 15 February 2010 at 1400 UTC (See Transcript and MP3.)

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.

Monday, 01 February 2010 at 1900 UTC (See Transcript and MP3)

Attendees: Jay Daley, Robert Hutchinson, Andrei Kolesnikov, Mark Kostas, Steve Metalitz, and Ram Mohan; From staff: Francisco Arias, Glen de Saint-Gery, Gisella Gruber-White, Julie Hedlund, and Steve Sheng

Action Items:
--WG members will continue to provide comments on the list to the draft of a questions related to topic #1 -- “What do we require from internationalized registration data?” See the email archive for the latest discussion at: http://forum.icann.org/lists/ssac-gnso-irdwg/ http://forum.icann.org/lists/ssac-gnso-irdwg/ . See also the attached summary provided by Steve Sheng of comments received by 25 January, as well as the discussion summary below.
--Steve Sheng will follow up with Jiankang and Edmon concerning Question 1a and the recommendation to provide output in A-label and U-label format and how this would work for Chinese registries.

Main Discussion Points: WG members discussed questions 1a and 1b, continuing from comments provided on the email list and summarized by Steve Sheng.
Question 1a: 1) What do we require from internationalized registration data: 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?
WG members agreed that 1) WHOIS must accept a "submit" in either U- or A-label; and 2) WHOIS must "display" both in U- and A-label. There is also an additional recommendation raised by Ram, which would be optional, that bundled representations (e.g. both the simplified and traditional Chinese) of a single A or U-label query should be returned. The WG members asked Steve Sheng to follow up with Jiankang and Edmon concerning their experience with Chinese registries and thoughts on this recommendation. In earlier emails, Jiankang mentioned that A-label input to Whois needs to be checked to confirm that it is a valid IDN. If it is not, error should be returned. This would require changes to the Whois client.

Question 1b: 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? Much of the discussion focused on Jay’s suggestion that the various elements of registration data could separately internationalized. WG members agreed that the sponsoring registrar name should be displayed in US-ASCII7 subset of the Latin-1 character set. (Note: although some working group members do not fully endorse this idea, they nevertheless think this is acceptable). Ram and Andrei noted that in India and Russia, respectively, the registrar representation is provided in both local script and ASCII. The WG members also agreed that email addresses can be internationalized using RFC 4952 and 5336. The WG members discussed using UPU convention for postal address internationalization. Bob noted that the UPU standard is not computer based and that it is difficult to write a web page to capture manual addresses. Jay added that UPU is a standard that already exists and that the WG should not try to develop a separate standard. This needs to be taken up again in the next meeting. The WG discussed using E123 format to internationalize phone numbers, Ram noted that currently there is no standard for phone numbers in Whois. This issue should be followed up in the next IRD meeting. The rest of the discussion focused on the question of whether or not contact information (include registrant, admin contact name, tech contact name) should at least be displayed in ASCII. WG members presented reasons both for and against:

Reasons for at least have ASCII contact information:
--Avri noted that it is important for registrant information to be accessible to others.
--Ram noted that law enforcement often requires both local and ASCII output and Andrei agreed that was also the case in Russia.

Reasons against:
--Jay noted that insisting all data is in both the local language and ASCII will not make it universally usable. It will present a barrier for those who does not use English to register, and would introduce errors.
--Jay added that a solution would be to offer the information in as many scripts as possible, but that this wasn’t likely to be feasible.

WG members also discussed whether their could be a standard for ccTLDs. Jay noted that ccTLDs handle output very differently and that it isn’t in the scope of the IRD-WG’s work to recommend a standard for ccTLDs, although it might be useful to provide a tool kit for each data element. Ram suggested that the WG should hold this topic for later. Andrei noted that it might be helpful to do a survey among non-ASCII ccTLDs on this issue. Ram suggested that the WG should focus on recommendations on output in a local script and some type of standard set, but should not address the issue of confusingly similar character sets.

Monday, 04 January 2010 at 1400 UTC (See Transcript and MP3.)

Attendees: WG Members: Edmon Chung, Steve Crocker, Rafik Dammak, Avri Doria, Jeremy Hitchcock, Bob Hutchinson, Yao Jiankang, Steve Metalitz, June Seo (absent apologies: Eric Iriate Ahon, Jay Daly, and Ray Plzak); ICANN Staff: Gisella Gruber-White, Julie Hedlund, Dave Piscitello, and Steve Sheng.

1. Action Items: Dave Piscitello will provide a draft of a questions related to topic #1 -- “What do we require from internationalized registration data?” for the Working Group to consider. Jeremy Hitchcock agreed to provide some additional points (See link) and Steve Metalitz also may provide some thoughts on the list.

2. Main Discussion Points: Dave Piscitello reviewed the draft 3 topic areas: (see link) 1) What do we require from internationalized registration data? 2) What should the registration data look like? 3) What methods of delivery (protocol) are needed to support IRD? How does internationalizing registration data effect existing protocols? Edmon noted that topic areas 2 and 3 were related and could possibly be considered together. He also asked what is in the scope of the WG with respect to suggesting protocols and how should the group approach these topics. Jeremy noted that there currently is no expectation in WHOIS for character sets to be identified and that the WG should consider the responsibility for application design and registrar requirements for making the WHOIS work correctly. Avri noted that while all three topic areas are related how you express the data needs to be explored separately. Edmon suggested rephrasing topic three, and others agreed, as “What is needed from the protocols to support IRD?” Jeremy suggested that the WG should focus on what we would require rather than the protocols or transport functions, although he assumed the WG would agree with the assumption that WHOIS/Port 43 has to function and be backwards compatible. Dave suggested that the WG/ICANN would not be developing protocols but identifying a data schema that could be presented to the IETF for discussion, perhaps via SSAC members who are active in the IETF. Avri asked whether the WG/ICANN should go far as to suggest schemas and Dave responded that the WG suggest a straw man schema for consideration. Edmon agreed that the WG is not suggesting a standard but is laying out specifications and requirements to provide a straw man. Dave agreed to take topic area #1 and set it out as a set of questions and possible answers for the WG to consider on the list and for discussion at the next meeting. Jeremy agreed to provide some additional points on the applications (human and machine) that are touching registration data. Dave asked Steve Metalitz whether he had some additional thoughts to provide to the list. The WG also agreed to rotate meeting times to accommodate various time zones. Accordingly, the meetings will continue to be held bi-weekly but alternate between 19:00 UTC and 14:00 UTC with the next meeting taking place on 18/19 January at 19:00 UTC.

Monday, 21 December 2009 at 1400 UTC (See Transcript and MP3.)

Attendees: WG Members: Erick Iriarte Ahon, Edmon Chung, Steve Cocker, Rafik Dammak, Bob Hutchinson, Yao Jiankang, Steve Metalitz, June Seo (absent apologies: Avri Doria and Jeremy Hitchcock); ICANN Staff: Francisco Arias, Julie Hedlund, and Dave Piscitello.

1. Action Items: Dave Piscitello will provide a draft of a list of topics (See http://forum.icann.org/lists/ssac-gnso-irdwg/msg00021.html) for the Working Group to consider as possible study topics.
2. Main Discussion Points: Dave Piscitello suggested that a possible requirement for international registration data could include a way to identify the character set so one could know what was being displayed, particularly if more than one language is present. It also could be useful for the information to be machine readable so that a computer can know what character set and identify individual characters. This requirement could include a feature to present someone from submitting illegal characters. Steve Crocker noted that the World Wide Web Consortium (W3C) might have some expertise in this area. He sent a message to Thomas Roessler who also indicated that it could be good to engage them. Edmon Chung agreed that this is a helpful suggestion. Dave added that, if the Working Group agreed, this could be an optional requirement for local scripts and emphasized that the requirement could only apply to the domain name, rather than other information (such as the registrant address). Edmon suggested that a language tag for domain names might not be useful to guess the character set. He added that besides having some sort of tag the Working Group should consider whether we want blocks of data and how we would encode it, rather than a recommendation to encode each field of data. Dave noted that there already is a standard for domain name encoding so the Working Group does not need to go beyond IDN guidelines. However, Working Group members noted that for domain name registration you might have more than one script in the domain name and some of these might include characters (such as hyphens) that could otherwise be restricted because they could be used for malicious purposes. Edmon asked what is the next step for the Working Group. Julie Hedlund noted that the Charter lists as the primary deliverable a study of the feasibility and suitability of introducing display specifications to deal with the internationalization of Registration Data. Edmon suggested that as a next step staff could assist by drafting a list of three to five areas of specific concern, which the Working Group could review on the email list and discuss at the next meeting. Issues could include 1) domain name/IDN — is there an additional field that should be displayed; and 2) whether there should be a block for each contact or each domain, or have the whole set in a different language. Dave agreed to draft an initial list for Julie to post to the IRD-WG email list for review and comment.

Monday, 07 December 2009 at 1400 UTC (See MP3, Transcript IRD WG 07 December 2009)

Attendees: WG Members: Edmon Chung, Steve Crocker, Rafik Dammak, Bob Hutchinson, Yao Jiankang, Mark Kosters, June Seo (absent apologies: Avri Doria and Jeremy Hitchcock); ICANN Staff: Francisco Arias, Gisella Gruber-White, Julie Hedlund, and Dave Piscitello.

1. Action Items: WG members should consider on the list possible requirements that could form part of a check list to decide what is, or is not, in the scope of the work of the WG.
2. Main Discussion Points: The Charter calls for co-chairs from the GNSO and SSAC. The WG approved Jeremy Hitchcock as co-chair from SSAC. Edmon Chung suggested that to help further define the scope/mission/goals the WG could begin by looking at requirements for registration data. Dave Piscitello noted that based on the survey he conducted one possible requirement could be that in addition to collecting and displaying data in ASCII/roman script, if it was beneficial data also could be displayed in local script. Bob Hutchinson asked whether there was any sense of the degree of difficulty for adding data display in local script. He wondered whether it would be helpful to formulate a set of specific questions that could form a larger survey of ccTLDs. Edmon noted that a survey could be a good idea, particularly in understanding how registries currently receive and display data, although he noted that the goals of the ccTLDs would likely be different from those of the gTLDs. Dave suggested that one requirement could be to tag each piece of data and Mark Kosters asked whether such a requirement would be in the scope of the WG. Dave noted that the requirement would not have to change what data is collected today. He also noted that ICANN staff are studying Whois service requirements at the request of the GNSO Council (the “May 7 request of the GNSO Council”) and this study considers a data schema for registration data in the context of a broad set of service requirements including IRD. Edmon suggested that it might be useful to prepare a checklist of possible requirements for receiving and displaying internationalized registration data and use the list to decide what is, or is not, in the scope of the WG. Bob questioned whether there was a consensus on a recommendation for structure data and didn’t know if displaying in a local language would require a significant amount of work. Steve Sheng, Edmon, and Yao Jiankang all noted that there could be challenges for translation of an address into Chinese. Edmon suggesting using the summary provided by Dave of the survey of 16 ccTLDs as a basis to produce an initial checklist of requirements to decide what is in scope. Dave noted that the WG would not have to recommend a specific format, but could use the United Postal Union (UPU) standard as an analog for how data could be represented using Roman characters and additionally represented for a recipient or viewer of the data. In the UPU example, the recipient is both the addressee and the postal workers in the destination country; in the Whois case, the recipient/viewer could be an application (that already assumes USASCII7) or a viewer who may or may not understand roman characters but does understand characters of his local language.

https://community.icann.org/download/attachments/11995205/IRD-WG+Notes+12+April+2010+Meeting.pdf?version=1&modificationDate=1302026628000