RE: My personal comments on the requirements.

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

OK then, how about leaving 9-[1] as-is to cover domain and host names and
adding a new requirement for internationalized meta-data:

[2] The protocol MUST allow exchange of meta-data associated with objects in
formats consistent with current internationalized character encoding
standards.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Patrik Fältström [mailto:paf@cisco.com]
Sent: Tuesday, December 26, 2000 2:09 PM
To: AndrÈ Cormier; Provreg (E-mail)
Subject: Re: My personal comments on the requirements.


At 13.49 -0500 00-12-22, AndrÈ Cormier wrote:
>9. Internationalization Considerations
>   [1] Current Internet standards restrict the encoding of Internet host
>   and domain names to a subset of the 7-bit US-ASCII character set.
>   Registries and registrars now serve customers whose native languages
>   require encodings other than US-ASCII, which automatically disallows
>   use of those languages when registering host and domain names.
>   Support for internationalized host and domain names will greatly
>   increase world-wide usability of a generic registry registrar
>   protocol, so standards for internationalized host and domain names
>   MUST be considered during the protocol design process.
>AC: [2] All data MUST be sent using UTF-8 as stated in [RFC2277] to enable
>AC: the use of internationalized data.

The information in section 9 should be syncronized with what happens 
in the IDN working group -- BUT, I would like to differ between two 
different types of data:

   - The Domain Names themselves
   - Other meta-data which goes along with the domainname, such as the
     street address of the admin contact etc, which can include not only
     non-ascii characters but also the address in a different format than
     what is default by the registry. Example: Street name and number is
     in the US written as "<number> <street name>" while in Sweden the
     order is the inverse "<street name> <number>".

To start with, the meta information should be able to be both in 
"english" ascii and in the native characters using Unicode, but the 
domainname definition should wait for the IDN definition (it might be 
that the domainname should be in some ACE encoding, already 
nameprepped -- or equivalent).

   paf