RE: International Issues @ 3.4.2[6] and 9.

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

>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Monday, April 09, 2001 9:08 AM
>To: Hollenbeck, Scott
>Cc: ietf-provreg@cafax.se
>Subject: Re: International Issues @ 3.4.2[6] and 9.
>

[snip]

>Hi Scott,
>
>there is a misunderstanding, eventually caused by my bad english. I do
_not_
>propose any support for any special character _encoding_ or whatever, but I
>propose to restrict the _use_ to the ASCII character set, esp. to the 26
latin
>letters (+ non-letter characters, of course) for an international version
of
>the social data.
>
>I'm trying to figure out how a Japanese spells the name of an arabic domain
>owner ;-) I came to the conclusion that we need a common base to
communicate
>and exchange information, and the lowest denominator in this are IMHO the
26
>latin letters. It resembles the version b) you mention, with the exception
>that I didn't want to talk about character encodings (UTF8, ISO 8859, ASCII
or
>whatever), which is clearly out of scope, but on the characters which can
>actually be used, similar to a pattern matching international phone
numbers.

I'm OK with use of ASCII for a required version of the social data.

>I think that the topic is important not only for generic TLDs, but also for
>country code TLDs. Although ccTLD domains are normally registered by the
>people of the corresponding country, it should be possible for people from
>different countries to contact owner, admin, technical contacts etc., e.g.
in
>case of malfunction.
>
>Therefore I believe it is important enough to put this topic into the
>requirements document at the place I mentioned (instead of leaving this up
to
>the registry's policy) -- maybe with different words or different level of
>detail, but more concrete than the current text. If you disagree with this,
>then you should consider to replace the second "MUST" in section 9[2] with
>"MAY" or "SHOULD", as you shouldn't enforce internationalization there
while
>omitting it in 3.4.2.

This is where I'm getting confused.  As currently written (by Harald
Alvestrand), 9.-[2] basically says that we MUST represent data in accordance
with international standards for the data in question, and that we MAY need
to represent it twice (which implies (maybe this is the problem) once in
ASCII format and once in an optional non-ASCII format).  An
internationalization requirement would be out of place in 3.4.2.

Are you suggesting that 9.-[2] should more explicitly state that one of the
social information representations MUST be ASCII, and a second non-ASCII
format is OPTIONAL?

<Scott/>