To:
"'Klaus Malorny'" <Klaus.Malorny@knipp.de>, ietf-provreg@cafax.se
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Mon, 9 Apr 2001 08:09:43 -0400
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: International Issues @ 3.4.2[6] and 9.
>-----Original Message-----
>From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
>Sent: Monday, April 09, 2001 5:08 AM
>To: ietf-provreg@cafax.se
>Subject: International Issues @ 3.4.2[6] and 9.
>
>
>
>
>I would like to have some additions to 3.4.2:
>
>rationale
>
>Allthough section 9[2] mentions the problem of different languages and
scripts
>and gives a solution, especially in the requirement to MAY have multiple
>versions of names, addresses etc. in different versions, I think it is
>important to substantiate this for the so-called social data in section
>3.4.2[6]. We should force to have a version of the social data that is
>understandable around the world so we can assure that the data
>is useful outside the country where it is originated.
>
>
>added text
>
>---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/>