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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

As agreed during the 4 January 2009 teleconference, I'm opening discussion
on the topic of requirements for internationalized registration data. The
initial set of questions is reproduced below. The goal of this discussion
thread is to invite WG members to comment/elaborate on the set of questions
posed so that staff can produce a working draft document that provides
indication of support of requirements, more clarity on the nature of each
requirement, and rationale for including the requirement for future
registration data access.

Please post to the list. Where the questions below appear to ask for a
yes/no answer, please offer your perspective/supporting rationale.

Thanks very much!

Dave

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?

   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?

   c) Does (b) imply several representations of the same registration
      data, but in different languages or scripts?

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

      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)

      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?

   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?

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

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>

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

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