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

[James M Galvin <jgalvin@xxxxxxxxxxxx>]

Thanks Steve, I look forward to your comments.

Jim



-- On May 16, 2011 8:56:17 AM -0400 "Metalitz, Steven" <met@xxxxxxx> 
wrote regarding Re: [ssac-gnso-irdwg] proposed new structure and 
recommendations for final report --
> 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
> >
> >