Re: [ssac-gnso-irdwg] Open discussion: what do we require from IRD?

[Jay Daley <jay@xxxxxxxxxxx>]

Hi Dave

On 7/01/2010, at 6:20 AM, Dave Piscitello wrote:

> 1) What do we require from internationalized registration data?
> 
>   a) that a user can submit or have a domain name displayed in
>      the IDN A-label (xn--) format or U-label (local language
>      readable) format?

That is two separate questions and both are incomplete.   The first: "can a 
user submit" needs a definition of what "submit" means in this context.  Does 
it means to register?  The second "have a domain displayed" needs an 
explanation of where the display takes place.  Otherwise these two questions 
are too general.

>   b) that registration data be extensible to accommodate users
>      who would benefit from the ability to submit and have registration
>      information displayed in "familiar" characters from local
>      languages and scripts?

We need to be clear on the distinction between the various elements of 
registration data that could be separately internationalised:

- domain names
- entity names
- postal addresses
- email addresses
- telephone numbers

The questions we ask need to address these elements individually.

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

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,

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.

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.

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.

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

>      iii) Related to c), is it possible to adopt an ICANN policy
>          that both meets the expectations and needs of internet
>          users around the globe and has a high probability of
>          adoption by ccTLD operators as well?

Yes provided we delineate the problems and solutions appropriately and consider 
the ccTLD perspective as well as the gTLD perspective.  I suspect many gTLD 
people know far less about ccTLDs than vice versa and so some education might 
be appropriate.  For example could we get a sample of WHOIS outputs for 
different countries?

>   d) that registration data be collected and displayed (or returned
>      via a whois/port 43 or successor protocol) *uniformely*, in manners
>      that would allow applications to process the data efficiently? In
>      particular, should applications that do not involve
>      humans (automation) not be complicated by variations across
>      display/collection practices/policies by registries and registrars?

I think this is way out of scope for this group.

It would be useful to tackle standardised flagging of encoding in port 43 
input/output but no more than that and even then I would want that to go 
through the IETF (see below).

>   e) that some filtering or processing be considered to reduce the
>      opportunity for deception/misuse when characters from
>      multiple scripts are used in the composition of certain
>      registration data? While perhaps not a perfect fit, are the
>      prohibitions of mixed-scripts in the IDN guidelines that
>      applied to labels of a domain name representative of
>      the opportunities we might attempt to define?.

I would go one step further and expect whole sets of data to be in one script 
or another, not mixed.

> 2) What should the registration data look like?
> 
>  a) some form of tagging of the data to identify the piece (object),
>     i.e., "this is a contact address"
>     Using XML, for example, such a tag and the data might look like
>     <contact-address>3 Myrtle Bank Lane</contact>
> 
>  b) alternatively, tagging of blocks of data where a group of objects
>     such as an administrative contact would be tagged
>     Using XML, for example, such a tag and the data might look like
>      <admin-contact>
>         David Piscitello
>         3 Myrtle Bank Lane
>         Hilton Head SC 29926
>         ...
>       </contact>

Both of these are now heavily into protocol design, which is what we have the 
IETF for, not ICANN.   I think it entirely inappropriate for us to be 
discussing XML (or other) field identifiers.

If we were to identify a list of requirements for a new/amended protocol then 
that could be pushed over to the IETF, but we should not design the solution 
here.  This is not the right place to do it.

>  c) some means to identify the language or script that the characters
>     in the data "belong to"

Yes, I agree, see above.

>  d) should some elements of registration data always be represented
>     in US-ASCII7 (e.g., sponsoring registrar)?


see above.

kind regards
Jay

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