Page History
This is a list of the current and previous meetings of the Internationalized Registration Data Working Group.
Next Meeting:
Monday,
...
22 August 2011
Previous Meetings:
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:
- 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)
- 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
...
