Re: [ssac-gnso-irdwg] proposed new structure and recommendations for final report

[Gisella Gruber-White <Gisella.Gruber-White@xxxxxxxxx>]

Dear Owen,

Thank you for informing us.

I have noted your apology.

Kind regards,
Gisella

On 16/05/2011 16:08, "Owen Smigelski" <Owen.Smigelski@xxxxxxxxxxxx> wrote:

>
>My apologies for missing the call right now. I am out of the office and
>my work email is blocking my login (so I cannot access the dial in
>information). I will respond soon to the list about Jim's proposal.
>
>____________________
>Sent from my iPhone
>
>On May 16, 2011, at 5:58, "Metalitz, Steven" <met@xxxxxxx> wrote:
>
>> 
>> Thank you for this detailed proposal Jim. I will probably not be able
>>to join today's call but will comment on list.
>> 
>> Steve Metalitz
>> 
>> Sent from my iPhone
>> 
>> On May 15, 2011, at 6:20 PM, "James M Galvin" <jgalvin@xxxxxxxxxxxx>
>>wrote:
>> 
>>> 
>>> We are meeting on Monday, 16 May, at 1500 UTC.  Our last two
>>> meetings have been cancelled due to lack of participation.  However,
>>> it is important that we move forward and seek closure on our work in
>>> this group.
>>> 
>>> I am going to propose a path to closure in this message.  It
>>> represents my understanding of our last meeting on 18 April
>>> (transcript has been available for some time), our public meeting
>>> during ICANN San Francisco (transcript has been available for some
>>> time), and a few private conversations I have had since and between
>>> those two meetings.
>>> 
>>> I am submitting this proposal as an individual.  I welcome
>>> discussion on its merits and completeness both in the meeting on 16
>>> May and on this mailing list.
>>> 
>>> Speaking as co-Chair, I am going to press to move forward with this
>>> plan, incorporating feedback and suggestions from our discussion in
>>> our next meeting on 16 May as well as any future discussions in
>>> meetings and on this mailing list.  I will interpret silence as
>>> agreement with this plan and its evolution.
>>> 
>>> In the rest of this message I am speaking as an individual.
>>> 
>>> 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.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Jim
>>> 
>>> 
>> 
>