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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

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

> Hi Dave
> 
> On 7/01/2010, at 6:20 AM, Dave Piscitello wrote:
> 
>> 1) What do we require from internationalized registration data?

>>   c) Does (b) imply several representations of the same registration
>>      data, but in different languages or scripts?
> 
> I don't think it has to though I am sure that intellectual property concerns
> and law enforcement would prefer that.
> 
> 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?

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

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}?  

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.   

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

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

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?
 
>>      i) Related to c), and to avert a possible Babel effect,
>>         is it desirable to adopt a "must be present"
>>         representation with optional collection/display of
>>         registration data for the convenience of "local users"?
> 
> See above.
> 
>> 
>>      ii) Related to i), should we consider adopting a
>>          "format for civic address information that's reasonably
>>           functional around the globe"?
>>           (cf. Thomas Roeffler, in his reply to Steve Crocker)
> 
> I think this is unnecessary and just a lazy way of doing things.  If we know
> the country the postal address data is for then there is a defined format for
> the local postal address (as well as generally standard local labels for the
> fields).  The "correct" thing to do it is to ask for the data in the
> appropriate local format. If form designers asked for the country first then
> this would be trivial to implement once you know the fields/labels for each
> country.

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.