Re: [ssac-gnso-irdwg] what do we require from IRD? Question (1c)

[Jay Daley <jay@xxxxxxxxxxx>]

On 14/01/2010, at 7:42 AM, Dave Piscitello wrote:

>> To answer the question properly we need to develop some categorisation around
>> constraints.  In all cases I assume the registrar is happy with billing
>> details they have for registrant, which may be different from the 
>> registration
>> data.
> 
> Agree. Do we agree that registrar billing data and generally, any data a
> registrar or registry keeps that are unique from the registration data
> identified in a gTLD agreement or RAA are outside our scope?

I for one agree.

> 
>> 1.  Entirely local registration in a gTLD or ccTLD
>> 
>> In this category the constraints are:
>> - registrant is based in country C
>> - data in script S which is a normal script for C
>> - data is meaningful in language L, a normal language of that country.
>> - registrar can read script S and language L (so they understand the data 
>> they
>> are supplying)
>> 
>> It is hard to see any primary reason why the registration data must be in any
>> other script/language as well in this instance.  Obviously there are 
>> secondary
>> reasons - law enforcement, intellectual property protection, consumer
>> awareness,
> 
> I don't understand how this works for a gTLD. In the simplest
> interpretation, and focusing specifically on registrations processing, are
> you saying that a gTLD registry with a thick registry would accept
> registrations in an arbitrary number of scripts/languages?

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

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?
2.  Who needs to be able to understand the registration data - the registry, 
registrar or both?
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?

Without thinking it through fully, my answers would be genuinely global, 
registrar only, none.

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

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.

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

> 
>> 2.  Local registration through non-local registrar (by which I mean a
>> registrar that cannot speak S or L) in a gTLD
>> 
>> In this category the constraints are:
>> - registrant is based in country C
>> - data in script S which is a normal script for C
>> - data is meaningful in language L, a normal language of that country.
>> 
>> In which case we can assume that any problems with the data cannot be
>> understood by the registrar and so requesting the data also in English/ASCII
>> is a prudent move, and having the WHOIS record show both is also prudent.  
>> But
>> then we are treating different registrars differently.
> 
> Given that a very large percentage of gTLD registrations are placed through
> fewer than 10 registrars, this is either likely to be the preponderant case,
> or registrars with strong incentives to attract and accommodate customers
> based "anywhere" would adopt your (1) above; specifically, the registrar
> would seek to "read script S and language L (so they understand the data
> they are supplying)", no?

Yes.

> 
>> 3.  Non-local registration in a gTLD
>> 
>> In this category the constraints are:
>> - registrant is in country C
>> - data is in script S which is NOT a normal script for C
>> 
>> We would then have to question why this combination should be allowed.  If it
>> is not allowed then we start to get into the business of connecting scripts 
>> to
>> countries and enforcing that linkage at data entry.
> 
> Even if this were disallowed, (1) and (2) seem to present significant enough
> challenges.

My reason for disallowing this is whilst allowing (1) and (2) is ultimately 
about the reasonable expectations of end users.  

> 
>> 4.  Non-local registration in a ccTLD
>> 
>> In this category the constraints are:
>> - registrant is in country C which is different from the country of the ccTLD
>> - data is in script C which is a normal script for C but NOT a normal script
>> for the ccTLD
>> 
>> It would seem quite appropriate in this case for the registry to insist the
>> data is also supplied in a local script of the ccTLD.
> 
> Can you explain what you perceive the registrar's obligation here? Seems
> that the registrar has a second set of conditions beyond (1); for example,
>  if registrar can read script S and language L AND
>     if the data are meaningful in L AND
>        if the TLD the registrant wishes to register the
>        label understands S then proceed?

Well spotted, yes the conditions are as you identify.

> General comment: Do the secondary reasons become less "secondary" when you
> apply set theory to your categories, or am I misunderstanding your intent in
> these categories and you are patiently enumerating all the cases we need to
> consider? 
> 
> Consider C as the set of TLDs {C1, C2, ...Cn}, data in script {S1, S2,
> ...Sn}, etc. While there is admittedly duplication, don't we end up with the
> Babel scenario? 
> 
> Law enforcement, IP, and other businesses that automate/make use of Whois
> are likely to be interested in a lingua franca, right? So would these
> parties say that this alternative satisfies the needs of a local community
> at the expense (and considerable risk) to the global community?

The reality of the world we live is in that there is no lingua franca and we 
should not fall into the trap of believing there is one.  We already have the 
Babel scenario and cannot get away from that.  In domain names by our use of 
ASCII we have not created a lingua france but simply excluded those people who 
do not use it.  That is a state of affairs that cannot continue.

To be accurate, there are two Babel scenarios that need to be separated out.

- the first is where different self-contained groups have there own languages 
and scripts which are used within a *local context*.  Some people 
speak/read/write more than one language/script for communications with others 
outside of that local context.

- the second is where multiple languages scripts are used outside of the local 
context and communications breaks down.

My suggestions above have all been about recognising the first scenario and 
trying to avoid the second.

That leads onto the point about law enforcement, IPR etc.  It is in my view, 
entirely unreasonable for us to insist that all registration data be duplicated 
in ASCII for English speaking law enforcement and law firms to be able to use 
it.  That would exclude all those law enforcement officers and law firms that 
do not read ASCII or speak English.

The alternative, where we expect registration data in every language is clearly 
absurd, so we are left with the scenario where some registration data can only 
be understood in the local context, which mirrors the real world. 

The argument that "all registration data is currently in ASCII and so readable 
by law enforcement, IPR concerns etc and we can't lose that" is completely 
bogus.  We only have that situation because a lot of people have been excluded 
and we cannot continue that way.

> So do we have three cases:
> 
> - adopt UPU standards
> - adopt an unique civic address format?
> - only accept local format
> 
> If only appropriate local format I imagine this would not satisfy law
> enforcement, security community, or IP concerns.

Are there differences between UPU standards and local formats?

You mean English-speaking "law enforcement, security community, or IP concerns" 
?

best
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services
desk: +64 4 931 6977
mobile: +64 21 678840