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

[James M Galvin <jgalvin@xxxxxxxxxxxx>]

Thanks Owen, I look forward to your comments.

Jim



-- On May 16, 2011 8:08:37 AM -0700 Owen Smigelski 
<Owen.Smigelski@xxxxxxxxxxxx> wrote regarding Re: [ssac-gnso-irdwg] 
proposed new structure and recommendations for final report --
> 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
> >>
> >>
> >