RE: [ssac-gnso-irdwg] Preliminary approach to Brussels

["Andrei Kolesnikov" <andrei@xxxxxxxx>]

Steve, all - should we limit slides content to the core work path (as
proposed in the message) or make it more "sample oriented", for example
provide difference between transliteration and translation and other
examples which we used over time?

 

Thanks,

 

--andrei

 

From: owner-ssac-gnso-irdwg@xxxxxxxxx
[mailto:owner-ssac-gnso-irdwg@xxxxxxxxx] On Behalf Of Steve Sheng
Sent: Thursday, May 27, 2010 10:11 PM
To: Ird
Subject: [ssac-gnso-irdwg] Preliminary approach to Brussels

 

Dear IRD-WG,  

The action item from Monday's meeting was for staff to provide a suggested
preliminary approach for your consideration based on the many weeks of
Working Group discussion, both during meetings and on the list.  Please note
that there will be a public session of the IRD-WG in Brussels and we would
like to be able to prepare some brief slides outlining a possible
preliminary approach to encourage discussion at the session.  Your input on
the following suggestions will help us to develop a preliminary approach for
Brussels.  It is important that we get input from all Working Group members
so we welcome and encourage your comments.  Please respond by Thursday, 03
June so that we can collect all comments for discussion at our meeting on
Monday, 09 June, at 1400 UTC.  Thank you for your assistance."


Warmly, 
Steve


Possible Preliminary Approach for Working Group Consideration: 

1.    What should we require of the WHOIS service in the IDN environment?


1) WHOIS clients must be able to accept a user query of domain name in
either U- or A-label format; 2) WHOIS clients must be able display result of
queries in a) in both in U- and A-label for the domain names; and 3) Bundled
representations (e.g. both the simplified and traditional Chinese) of a
single A or U-label query should be returned. 

2.    What do we require from internationalized registration data to
accommodate users who want to submit and have registration data displayed in
"familiar" characters from local scripts? 


The various elements of registration data could be separately
internationalized and dealt with as follows:

a) Domain names (RAA 3.3.1.1): WHOIS services should return both A-label and
U-label representation for the given IDN domains queried. 
b) Name server names (RAA 3.3.1.2): Currently all of them are in US-ASCII.
However, with internationalized domain names, it is possible that some will
publish their name servers in IDN. Note - the Working Group has not
discussed this issue. Suggested approaches are welcome. 
c) Sponsoring Registrar (RAA 3.3.1.3): Make available in ASCII to aid
investigation purposes of law enforcements. 
d) Telephone/Fax (RAA 3.3.1.7,8): Apply the UPU E. 123 standard using the
international notation (+31 42 123 4567). 
e) Email address (RAA 3.3.1.7,8): Use RFC 5335 as a basis.  
f) Dates (RAA 3.3.1.4,5) Include creation date, expiration date, and update
date of the domain. Note -- the Working Group has not discussed the
internationalization of this field.  Suggested approaches are welcome.
g) Registration Status: Registrars and registries often provide the status
of the registration. For example client-hold, delete prohibited, update
prohibited, etc. Note -- the Working Group has not discussed the
internationalization of this field.  The following are approaches to
consider.  Please indicate which approach you prefer or you are welcome to
suggest alternative approaches. 
  1) leave it in ASCII 7;
  2) always publish the exact EPP status code and leave it to the clients to
decide whether to localize or not;
  3) identify a more easily understood representation (for the mandatory
character set); or
  4) publish the easily understood representation in mandatory and local
character sets.  
h) Entity names (RAA 3.3.1.6,7,8) (registrant, admin contact, technical
contact) and Postal addresses (RAA 3.3.1.6,7,8)  1)Registrants submit in a
"must be present" language to WHOIS; 2) registrants have the option to
submit in a local script; 3) registrars must provide backwards compatibility
for Port 43 when necessary.