Page History

This is a list of the current and previous meetings of the

...

Internationalized Registration Data Working Group.

Next Meeting: TBD

Monday, 28 November 2011 (See Transcript and MP3)

Monday, 21 November 2011 (See Transcript and MP3)

Attendees:  Avri Doria, Sarmad Hussain, Bob Hutchinson, Steve Metalitz, Owen Smigelski; apologies: Jim Galvin; Julie Hedlund, Nathalie Peregrine, Dave Piscitello, Steve Sheng

Actions:

1.  Sarmad will post to the list his thoughts on a script tag.
2. The IRD-WG will produce a response concerning the comments received on the IRD-WG draft Final Report for staff to include in the Summary & Analysis Report.

Brief Notes on Public Comments:
1. ALAC Statement on the Draft Final Report of the Internationalized Registration Data Working Group <http://forum.icann.org/lists/ird-draft-final-report/msg00003.html>

• The Summary & Analysis Report should note the ALAC’s support for the IRD-WG draft Final Report recommendations.  
• What about the reference to the RAA?  What they are saying is that they are supportive of this kind of effort.  
• The Analysis should just thank and acknowledge their support.

2. INTA Internet Committee, Domain Disputes and Whois Subcommittee <http://forum.icann.org/lists/ird-draft-final-report/msg00002.html>  Claudio Di Gangi

• The key comment is that the INTA urges that the recommendations should be conducted expeditiously given the pending new gTLD program.  
• Not sure how we comment other than to say “thanks” and we hope it can happen expeditiously.
• The Analysis can call attention to other activity in IETF WEIRDS and the follow on to the SAC51 recommendations (Board directive for staff to develop a Road Map in coordination with the community).
• The concern from the INTA was about the timing and that there needed to be follow up.  
• The Analysis should also point out that the IRD-WG agrees with what INTA is saying that this work should be expedited.
• The IRD-WG will be disbanded once the Final Report is approved by the SSAC and the GNSO Council, unless it is tasked with more work, such as monitoring/tracking effort to implement the Final Report recommendations, but this is not something that has to be included in the Analysis of the comments.
• Who will take up the implementation of the Final Report recommendations? The IETF will take up the data model work, but it is unclear what the WEIRDS group will pick up.
• What about the language tag?  Is this requirement coming from ICANN?  There are multiple steps: 1) come up with a data model (xml schema) that includes language and character set tags that includes those elements that the IRD-WG Final Report has identified.  2) Socialize the data model with the community and get cooperation in the IETF to move towards a standards track and their may be work in the WEIRDS group.  3) Create an Issues Report and initiate a PDP that would identify the schema that registries/registrars in gTLDs and ccTLDs would adopt.
• Should there be a script tag along with a language tag?  Note that the character set comes from multiple scripts so you may not be able to tell which scripts the character set is from.  This issue is important for a discussion of possible changes to the Final Report.  Sarmad should send information on this issue to the IRD-WG list.

3.  [weirds] Internationalized Registration Data <http://forum.icann.org/lists/ird-draft-final-report/msg00000.html>  Alessandro Vesely

• The  comment talks about changing “must be present” to “may be present,” which would be permitting ASCII to the extent allowed.  This is something that the Issues Report might address but this seems to be different from any of the four models.  The comments seems to suggest that the local presentation is the “must be present” but then “may be present” would be if registrar or registry policy allows an ASCII version of that representation.  The IRD-WG members agreed to discuss this comment further on the next call.

Thursday, 27 October 2011 (See Audiocast and Presentation)

Monday, 03 October 2011 (See Transcript and MP3)

Monday, 19 September 2011 (See Transcript and MP3)

Monday, 12 September 2011 (See Transcript, MP3, and Final Report Draft v1 08 Sept 2011)

Monday, 29 August 2011 (See Transcript, MP3, and Draft Extended Outline for Final Report)

 Attendees:  Scott Austin; Avri Doria, Jim Galvin, Rafik Dammak, Bob Hutchinson, Steve Metalitz, Owen Smigelski; Glen de Saint-Gery, Julie Hedlund, Steve Sheng, Dave Piscitello

Actions:  Steve Sheng will revised the draft report based on the discussion.  (See below.)  Also fill in text where possible.  Produce a redlined document by Tuesday the 6th.

Recommendations (starting on page 15 of the document):

1. Develop a data model:  Aren’t some data elements already specified?  There isn’t total agreement on the elements.  We may not want to be overly prescriptive concerning what the baseline should be, but the WG could propose something.  In the last sentence change “tagging information” to “tagging elements”.  Like the phrase “ICANN staff should develop, in consultation with the entire ICANN community...”  (Add entire “ICANN” in the existing sentence.)  Is the term “data model” confusing in the context of this document?  Look through the document to make sure we are consistent in how we use the term and define it when it is first used in the document.  We have discussed using XML as a representation language — should it be in this recommendation?  The choice of a representation language would more properly belong to the IETF.  Not sure the IETF should be involved in the formalization of the representation language, but would be interested in the protocol (versus the data).
2. Issues Report:  The GNSO Council requests an Issues Report (should be clear in this document).  The SSAC also can request an Issues Report, as can the ccNSO.  “The GNSO Council or the SSAC should request an Issues Report...”  (See ICANN Bylaws at http://www.icann.org/en/general/bylaws.htm.)  May want to include here some of the elements that should be included in an Issues Report.  Although the WG should have given specific advice concerning how to approach transliteration/translation requirements, but it did not produce a consensus on how to proceed on these specification.  The question of who should provide transliteration/translation could be a policy issue, which is why there is a recommendation for an Issues Report.  Editorial note:  Make sure that the language in this recommendation meets the requirements in the Bylaws and also check it against the recommendations for changes to the PDP procedures from the PPSC-PDP work team (Policy Staff Support -- Marika).
3. Identify a directory service: Need clarification.  Make it clear that it is referencing a registration data directory service.  Draw an important distinction between the protocol and the service.  ICANN should define the service and separate it from the protocol that is currently in use.  We have identified a deficiency that the service definition doesn’t exist so we are saying that ICANN needs to specify the service definition.  Change “work with ICANN and the technical community” and “propose” not “identify” a “registration data directory service.”  This is one piece of a very large set of work at ICANN and in the community.  The recommendation should say specifically that this is part of other work.  Change the trailing phrase “meetings the needs...enumerated in this report AND (add this) the WHOIS Service Requirements.  Include language that says that internationalization should be part of that work.  Reference the Board’s specific request for this work.

Monday, 08 August 2011 (See Transcript and MP3)

Attendees:  Scott Austin; Jim Galvin, Rafik Dammak, Sarmad Hussain, Bob Hutchinson, Steve Metalitz; Julie Hedlund, Steve Sheng, Dave Piscitello, Gisella Gruber

Actions:  Steve Sheng will send a draft report prior to the next call.  Jim and Sarmad will provide Devanagari and Arabic script examples.  Dave will provide text for the findings section (4.2) and Steve and Scott will comment.

Notes (continuing discussion of outline):

Section 4.2, Second Bullet
Question:  Language or script or language and script?  Answer:  RFC tags both language and script.  Sarmad:  A string could be valid in more than one script.  Would it be arbitrarily based on the user-selected language?  In that case it would be necessary to tag the language.  User could indicate language and script.  Jim:  The issue Sarmad is raising goes back to the discussion with CNIC and Andrew Sullivan at IETF.  We have a technical issue and we should probably say something about it with examples to show that you need both the language and the script.  It will be good to have examples from Jim and Sarmad (Devanagari and Arabic script examples, respectively). If we are asking the users to supply this information we should make this more clear, but it might be sufficient for us to observe that the data needs to be tagged in this way.  With the additional examples, separate this into two sections for clarity.
Section 4.2, Third Bullet
Question: Change “many of the elements” to “all of the elements”?  Answer: We don’t have consensus on what is registration data.  There is another technical issue:  Not all elements have standards at this time.
Next Two Points (re: Internationalizing Contact Information: Names and Addresses) -- Question: Not clear what we are trying to say here?  Are we saying the models are out of scope?  Jim:  We were not able to come to consensus on the models in this group.  It is not our place to say what should or shouldn’t happen, although we could make a recommendation if we could come to consensus.   I think we need to document this discussion and we could observe that no consensus was forthcoming on our group or in the Public Forum.  We could recommend that other parties could examine these issues in detail.  (Change “options” to “model” in preceding points.)  Change the section “while it is not in the remit...” to note that there was some discussion in the group, but no final consensus.  But, is there a consensus emerging around how this data flows and its sourcing, we could acknowledge that we have to operate within the constraints of the system.  That the data is sourced by the registrant, the ability to enter scripts and languages is constrained by the registrar and registry and those policies that exist ad hoc today will probably exist in a future system and these are what we have to shape the policy in the future.  It is important to include this dialog in the final report even if there is no consensus to help to provide reference.  Rewrite this section an discuss at the next meeting.  Dave will produce some text and Steve and Scott will contribute.

Recommendations:  Look at the Policy Development Process and match it with the recommendations.  Example: “The Community needs to adopt a model...” and “The Community needs to develop an issues report...”  Steve will rework this section and ask for specific comments when the group considers the first draft of the final report text.

Monday, 01 August 2011 (See Transcript and MP3)

Attendees:  Scott Austin; Avri Doria, Jim Galvin, Bob Hutchinson, Steve Metalitz; Julie Hedlund, Steve Sheng, Dave Piscitello, Glen de Saint-Gery

Actions:  Steve Sheng will begin work on writing the report based on comments on the outline received through section 4.1.  WG members should provide any text they think is missing and should be included.

Notes (continuing discussion of outline from 2.3):

2.3 — Current Practices:  2nd bullet point -- add practices by other registries.  Reword to “to support Internationalized Data many registries currently support UTF8.”  We should be able to give some examples of what we do know is being used.  Combine second and third bullet in some fashion, but eliminate the 2nd bullet as it is currently written.  4th bullet:  Say that registries whose business targets countries with internationalized languages requiring greater than ASCII 7 support have acquired a way to do this.  Add either to the 1st bullet point to after the 4th bullet point.

Section 3 — International Standards: This section is included to show that there are some recognized standards, although we don’t have a finding or recommendation that speaks to this issue.  Make a note to add it.  We need to speak to the issue that the reason we are including these references is because they are useful to use for the data elements.  This group could recommend that where data elements can take advantage of these standards they should do so.

Section 4 — Findings
4.1: Second to last bullet is not complete.  Last bullet:  What does it mean?  We are trying not to get bogged down in other options, such as intellectual property interests.  The main point is that registration data serves purposes other than the life cycle of a domain name.  The focus for this report should just be the suitability and feasibility of displaying the data and not the uses of the data.  However, we don’t specifically state the purpose of the data, which is an interesting point.  It is hard to make a finding about the suitability and feasibility without speaking to the uses.  We are not comprehensively trying to survey all of the uses, but the preceding paragraph makes the point that for some uses for WHOIS data there are issues with internationalized registration data.  There is a need for some clarity here.  The last bullet is probably an overstatement.  We could reference some of the other work that we know has existed.  We should stay away from the policy discussions and find a neutral expression to avoid a subjective evaluation of the validity of an outcome.  Separate out the notion of abuse.  We have noted that registrants are monolingual, which leads us to translation and transliteration, but it is not possible for this group to answer that question since it is a policy question and therefore is out of scope.  Action:  Include the discussions on the burdens associated with suitability and feasibility of display for background — how the WG explored the issue.
4.2 --- Re: First paragraph Port 43:  Note Steve Metalitz’s comment that perhaps the solutions could be described.  Also, when you go into “must be present” script that seems to go into the area of policy.  For the tagging — who will have to deal with this?  Probably all parties at some level.   Note that ccTLD registries probably would not have consistent policies and requirements.  Need to revisit the issue of how to word this.  Concerning the policy questions on page 8, these seem terse and should probably be filled out with additional explanatory text.

Monday, 25 July 2011 (See TRANSCRIPT and MP3)

Actions: WG members review the revised draft extended outline and provide comments prior to the next meeting.

Notes:

General questions/suggestions:  

1. Do we want to make a recommendation related to policy?  In particular, do we want to say that it would be good to have uniformity between ccTLDs and gTLDs? (See text provided by Steve Metalitz)
2. Suggest throughout the document that we speak about WHOIS services independent of ccTLD or gTLD — just focus on service requirements.  The distinction should be left to the reader.  Question: How can we speak to ccTLD practices if we don’t know what they are?  Jim will offer some suggestions for Steve S.

Suggestions for each Section:
1.1 — Objectives and Goals: how do the recommendations tie to the two objectives — suitability and feasibility?
2.1 — Addresses — change to postal address and add email address at the end.
2.2 — Add the distinction on the second bullet relating to “thin” registries.  Describe also where each is collected and stored.  Delete “managed” from the header for section 2.2.  The response should say “data elements are stored here, collected here, etc.”  

Monday, 13 June 2011 (CANCELLED)

Monday, 30 May 2011 (CANCELLED)

Monday, 16 May 2011 1500 UTC (See MP3)

Attendees: Jim Galvin, Chair; Steve Austin, Avri Doria, Rafik Dammak, Sarmad Hussain, Bob Hutchinson, and Jiankang Yao; Staff: Julie Hedlund, Dave Piscitello, and Steve Sheng

Apologies: Steve Metalitz

Comments on Jim’s Proposal (see proposal and draft outline below)

Dave: The issue is not one of cost, but how we are going to pay for this.  The recommendations could talk about improvements to WHOIS to support IRD in a manner that no individual group ends up with an unfunded mandate.
Avri: This is a decent way to approach the work.  Comments on unfunded mandates, if we try to make that a consideration then we may just end up with the status quo.   We could include understanding the cost of what is being recommended, but that could be a result of this work.
Dave: Trying to get us to a more constructive dialog and consider models to share the cost or look at examples from other areas, such as data escrow.
Jim:  Suggest that we allow for some text to be developed in this area.
Avri:  We don’t have to call it an “unfunded mandate,” we can break it down into cost, who bears it, how do we fund it.
Bob: We may need to wordsmith the recommendations to clearer reflect the sentiment of the group: We can’t move forward without a policy that says who is going to do what.
Jim:  Maybe I have gone to far in narrowing the scope.
Bob:  There is another group that is working on trying to pick a protocol.  We could do a bottom up systems analysis, but we need a proper understanding of the policies that the system was trying to implement.
Avri: The GNSO Council is working on the whole issue of WHOIS services and policies.  One part of that report has the international display requirements, which helped kick off this group.  Perhaps Jim should be plugged into that work.
Jim:  The question I have is what is the action we should take?  Are we expanding on text to include in the recommendations?   Also, we should look into coordination.
Steve Sheng: When we wrote the service requirements report for WHOIS data we said we would wait until the IRD-WG provides its recommendations.  I am not sure the recommendations would be ready in time to include in a survey.
Bob (to Avri): Should we suspend the work of this group until the GNSO completes its work?
Avri:  I would not recommend suspension.  I would definitely recommend coordination.  We can provide updates to the GNSO Council.  The policy comes later.
Julie:  We do provide updates at GNSO Council meetings during ICANN meetings.
Avri:  I suggest more frequent coordination.
Jim:  Suggest we draft the document based on what I have proposed and give a heads up to the GNSO Council.
Sarmad: I had proposed a new model.  I am not sure what you mean by 4c.
Jim:  It was my intention to cover your proposal in the section on monoligualism.   Concerning 4c, I think the internal part of the system is ready for IRD to the extent that things are XML based since this allows tagging.  We could recommend that registries, registrars, and ICANN should make sure their systems are capability of handling this.  I was trying to separate this from the protocol issue.
Sarmad:  I am not sure what we are recommending.
Jim:  I think we can see how the text develops and reconsider this question.
Bob:  What happens after we publish this document?
Jim:  The report will need to be published for comment and will need to consider those comments.  Once it is final it will go to the Council, which will decide how to proceed.
Steve:  The staff could fill in a more detailed outline and send it to the WG to consider and to discuss on 6 June for a call on 13 June.
Avri:  Is this tied to any dates for Singapore?
Julie:  No, this is only for internal review in the WG, although we will provide a brief update on the status of our work in Singapore for the GNSO Council and the public.

Proposal from Jim for Consideration:

As a reminder, the mission of this working group is as follows:

The IRD-WG shall study the feasibility and suitability of introducing display specifications to deal with the internationalization of Registration Data.  In our interim report we have evolved 4 models and we sought community input on the efficacy of the those models.  We did get a few well reasoned comments but it is fair to say that we did not receive anything close to a community consensus on how to choose between the models.  I would like to propose something different than choosing between the 4 models, which we discussed during our last meeting.

In my opinion, the models are trying to address the problem of executing translation and transliteration.  Model 1 is status quo, i.e., we stick with the system we have and require US-ASCII to be
present at all times.  The other models distribute the translation and transliteration services in various ways.  I do not think we need to solve this problem.  I think we identify this as the problem that needs further study.

Specifically, I suggest the outline below for our final report. This is an expanded outline insofar as I try to say a bit about what I would expect to be in each section.  It is probably not explained
as well as it could be but I do hope it gets the point across.  I did not want to make this message any longer than it already is.  I also was not trying to write the report since I do want some discussion about this approach first.

The model for the outline is we state what we have, we make some observations about what we have, and we propose further study of a few specific issues.

1. INTRODUCTION - Mostly boilerplate information including problem statement and details about the formation of this group.  We can re-purpose a great deal of what is in the interim report.

2. BACKGROUND - This should include all the facts we need to support our findings.  Most of this is in our interim report.

a. what we know various registrars and registries are doing today to support the display of internationalizes data.
b. what we know about the existing WHOIS protocol.
c. what we know about the definition of registration data.
d. what we know about where different registration data elements are collected, stored, managed, and displayed.

3. INTERNATIONAL STANDARDS - This could be a part of the background information but my current thinking is that it is better to elevate to a major section.  In this section we summarize all the
international standards and standard practices that exist for internationalizing the various elements of existing registration data.  Most of this is in our interim report.

4. FINDINGS - In this section we list the conclusions we can draw from all the facts stated previously.

a. WHOIS is insufficient.  It has no structure and hence no method of signaling encodings.

a.1. Registration data has multiple purposes and internationalization requirements are different depending on the purpose.  To the extent the data is already represented in XML, e.g., within EPP between registrars and registries, internationalization is primarily ensuring the data is properly tagged with the script that is in use.

a.2. The lack of structure in WHOIS excludes any signaling mechanism, thus the data can not be correctly tagged and further it can not be correctly displayed.

a.3. There are recognized standards for internationalizing many of the elements of registration data but in many cases the data would need to be translated or tranliterated for use with the current
WHOIS.

b. Registrants are monolingual.  This is intended to highlight the problem of who does the translation or transliteration and what it means to responsibility for quality and compliance.

c. Quality of data is not a well defined phrase.  Registrants are expected to provide high quality data but can it be verified?  Even if could what happens to the quality after translation and transliteration and who is responsible for that?

d. Registration data is itself undefined.  WHOIS services do vary. WHOIS requirements vary between registrars and registrants as evidenced by the contracts.

4. RECOMMENDATIONS

a. Seek a plan to define registration data, who collects it, who stores it, who is responsible for it, and specify its purpose.

b. Seek a plan to replace WHOIS.  In other words, although the data can probably be internationalized, displaying it is problematic with the current system.  This study would need to consider if
registration data should be translated or transliterated, who should do it, what it means to the overall registration data infrastructure, and what it means to the quality of the data.

c. As an interim solution, given the continued use of WHOIS, as much as possible, all parties in the lifecyle of the registration data should adopt the international standards noted above for
registration data elements wherever they can.

Monday, 02 May 2011 -- CANCELLED

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)

...

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.

...

Action Items: Based on the working group members’ comments the staff will revise the matrix and send an updated matrix for further review.https://stcommunity.icann.org/data/workspaces/int-reg-data-wg/attachments/ird_wg_meeting_notes:20100422174607-0-17508/original/download/attachments/11995194/Copy+of+matrix-draft-revised%20414revised+414.xls?version=1&modificationDate=1302025996000

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

...

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://stcommunity.icann.org/data/workspaces/int-reg-data-wg/attachments/ird_wg_meeting_notes:20100405184333-0-617/original/IRD-WG%20Notes%2029%20March%202010%20Meeting.pdfdownload/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.)

...

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://stcommunity.icann.org/data/workspaces/int-reg-data-wg/attachments/ird_wg_meeting_notes:20100422174702-1-17508/original/IRD-WG%20Notes%2012%20April%202010%20Meeting.pdfdownload/attachments/11995205/IRD-WG+Notes+12+April+2010+Meeting.pdf?version=1&modificationDate=1302026628000