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

[Klaus Malorny <Klaus.Malorny@knipp.de>]

"Hollenbeck, Scott" wrote:
> 

> >
> >---8<---
> >3.4.2.
> >
> >[6] ...
> >
> >The social data MUST contain a version ("international variant") that uses
> >internatioal standards for names, addresses, phone numbers
> >etc. and uses a restricted character subset (US-ASCII).
> >
> >The social data MAY additionally contain multiple versions ("national
> >variants") that MAY use national representations of names, addresses and
> phone
> >numbers and MAY use any characters which are supported by the protocol.
> These
> >versions MUST be tagged with a country and/or language identification
> >according to RFC XXXX/ISO 639/ISO 3166.
> >---8<---
> 
> I think the existing text is more appropriate; it allows for non-ASCII
> representations as needed.  Plus, at IETF-50 there was room consensus that
> charsets other than UTF-8 should not be used, which gets us back to either:
> 
> a) One set of data in UTF-8, which would support a singular representation
> using both ASCII and non-ASCII characters, or
> 
> b) Two sets of data, with one (required) in ASCII and the other (if desired)
> in potentially non-ASCII UTF-8.  My recollection is that most folks who
> spoke up at the IETF meeting thought this was the best alternative.
> 
> Of course, this list is the final arbiter.
> 
> <Scott/>

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


regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeißer-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0