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

["Owen Smigelski" <Owen.Smigelski@xxxxxxxxxxxx>]

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
>> 
>> 
>