[ssac-gnso-irdwg] More: registry should accept registrations in whatever scripts/languages the registrars can support

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

I'm focusing this thread on one part of your longer email.


On 1/13/10 6:03 PM  Jan 13, 2010, "Jay Daley" <jay@xxxxxxxxxxx> wrote:

> Yes precisely that - the registry should accept registrations in whatever
> scripts/languages the registrars can support.

So I am clear, the consequence of what you are proposing is that

1) the domain name in a registry will conform to IDN guidelines
   - in the zone file it will be A-label
   - in the registration record it will be A-label or U-label or both
2) the registry will remain agnostic regarding scripts and languages
3) registration data will be stored in Unicode-8 or Unicode-16
4) submit and display is a local issue for registrars (and anyone
   who provides a Whois service?)


 
> There are some fundamental questions here:
> 1.  Is a gTLD a genuinely global TLD or a TLD based in a specific country that
> requires the language of that country?

If I understand your criteria for registry acceptance above, and if
providers of registration/whois services ultimately decide what
scripts/languages to support I don't see a difference.

> 2.  Who needs to be able to understand the registration data - the registry,
> registrar or both?

If I understand you correctly, then for a (GTLD) registry to understand
registration data it must potentially understand all languages/scripts that
any of the ICANN accredited registrars support for Whois.

Help me understand this scenario:

Registrar A supports COM domain registrations using characters from language
a. User Bob queries Whois using an A-label at Registrar B's web-based Whois
service. Registrar B's Whois service doesn't support characters from
language a. What should registrar B display to Bob?
 
> 3.  What actions on a registration is a registry incapable of performing if
> they do not understand the registration data, that they currently do now?

I need to understand what data will be available to a registry from sources
other than registration data. Assuming that sponsoring registrar ID and
contact information are available from some other source, and that DNS
configuration information is available in a form that can be processed and
incorporated into a zone file, then the registry would presumably be limited
only with respect to any administrative action or incident response that
would cause a registry to attempt to contact a registrant directly. These
are exceptional cases but they exist today (catastrophic events that
interrupt a registrar's business operations, registrar ceasing business
operations, a legal action forced upon a registry, or direct contact by a
major brand).
 
> Without thinking it through fully, my answers would be genuinely global,
> registrar only, none.

My answers (above) then are (1) genuinely global, (2) not sure, and (3) not
sure.

>> I could envision
>> this working in a thin registry, but is the consequence that much of the
>> registration data are locally understood but potentially unusable by some or
>> all non-local users?
> 
> This will always be the case because there is no global language/script.
> Insisting all data is in both the local language and ASCII will not make it
> universally usable.  There are plenty of people who will not understand
> either.

I agree that "universally usable" may not be an achievable objective. I
think if the objective were to not make the data less useful than it is
today then local+ASCII might achieve such an end. This is not too different
from writing a protocol so that it is "backwards compatible".

> The same fact shows where the problem is with insisting on local + ASCII - if
> someone lives in country C and only speaks L and writes it in S then how can
> they register a domain if they arerequired to also give the data in ASCII?
> Either they enter rubbish, expect the registrar to do it or give up, none of
> which are acceptable.

I agree that this is a problem with the local+ASCII. How then does the
postal service manage this?

>> Generalizing, if a registrar wishes to serve users of a given ccTLD, and the
>> country has more than one national language {L1, L2, ...Ln}, does this mean
>> that the registration data this registrar collects from country C would
>> potentially be accepted from users (and recorded) in scripts {S1, S2,
>> ...Sn}? 
> 
> I think that is a choice they make, weighing the practicalities of such an
> implementation against the potential business they get.
> 
>> Also, is it correct to assume that when you say "based" you mean "performing
>> a whois related operation from country C, using a normal script for C"? I
>> could be employed by ICANN temporarily in Tokyo but would be wholly
>> incapable of using a local script as the only method of accessing a gTLD
>> whois.  
> 
> No, by "based" I mean the country of the registrant.  Where you access the
> data from is irrelevant.  So if I registered a domain giving my address as in
> NZ then I could not use Devanagari as my script.

I think the general proposal you have presented is to push local language
support to the edge. The registration and whois service providers choose how
best to serve the local user community. The result is that some or all of a
registration record submitted via any registrar A may not be "readable" when
accessed using a Whois service offered by any operator other than registrar
A. 

If this is the model you propose then perhaps it's worthwhile thinking about
separating information that is submitted by a user from information that is
recorded in a registration record.

So as a strawman to assist us in understanding the details of your proposal
I offer the following analysis. (This is not necessarily an indication that
I agree that this is the way forward, but I think it's more valuable to
consider the details constructively at first rather than criticize at a
metalevel and get nowhere close to any level of detail that might help us
move forward):

Sponsoring registrar ID and contact information
-----------------------------------------------

Source: registrar
Comment: I suspect this is ASCII in nearly if not all registration records
for GTLDs. You could propose to keep it so. You could also propose that a
code point/index into a definitive, well-maintained, publicly accessible
repository replace or complement (added to) the current data constructs we
associate with sponsoring registrar. The entries in this list (or lists)
must provide sufficient information to facilitate contact with the
registrar; in particular, the registrar's help/technical and abuse points of
contact (SAC038) ought to be part of this information.
Display: exactly as recorded by registrar (assume ASCII)

Registrant, administrative, and technical contact information
-------------------------------------------------------------

Source: registrant
Comment: These could be recorded in the characters from scripts/languages
the sponsoring registrar supports. Addresses adhere to (local) postal
conventions, telephone and fax numbers ought to be in arabic numbers, etc.
email addresses must conform to Internet mail standards.
Display: local matter for registrar and whois service provider.

NOTE: it should be incumbent on the registrar to provide "language support"
for any party who has a legitimate need to contact a registrant in every
language the registrar supports. Simply put, if registrar A accepts
registrations in Klingon then the registrar must provide assistance to
non-Klingon speaking/reading parties who wish to report abuse, technical or
other issues relating to a domain the registrar sponsors.

DNS configuration information
-----------------------------

Source: registrant
Comment: Domain names of name servers must conform to DNS or IDN guidelines
for label composition.
Display: U-label or A-label or both

Registration-specific data
--------------------------
Source: registrar/registry
Comment: Registrar Status is essentially the EPP status code. The Created,
Updated, and Expires dates are typically displayed in the international form
yyyy-mm-dd. The Whois server for the domain is a domain name.
Display: There does not seem to be a common convention for displaying
Registrar Status. Some TLDs use the ASN1 string, clientTransferProhibited,
while others use the english expansion of the ASN1 string, e.g., CLIENT
TRANFER PROHIBITED. Could define one here. Whois server name can be
displayed in A-label or U-label or both. Dates in international format.

Does this capture what you had in mind?