ICANN ICANN Email List Archives

[ssac-gnso-irdwg]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: ssac-gnso-irdwg@xxxxxxxxx
  • Subject: [ssac-gnso-irdwg] proposed new structure and recommendations for final report
  • From: James M Galvin <jgalvin@xxxxxxxxxxxx>
  • Date: Sun, 15 May 2011 18:17:39 -0400


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




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy