Subject: Internationalized vs. localized

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Oct 2002 15:16:36 +0100

In draft-ietf-provreg-epp-contact-05.txt, one can read:

  - One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms; a
  "type" attribute is used to identify the two forms.  If an
  internationalized form (type="int") is provided, element content MUST
  be represented in a subset of UTF-8 that can be represented in the 7-
  bit US-ASCII character set.  If a localized form (type="loc") is
  provided, element content MAY be represented in unrestricted UTF-8.

The vocabulary is very strange: the international form should be the
encoding allowing full use of Unicode (here, UTF-8). Because it is the
form that works in every country.

A form restricted to US-ASCII should be named "local" because it will
work only in some countries. I suggest to swap "internationalized" and
"localized" in the above text. Or to use less ambiguous words like
"Full repertoire" and "Subset".

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 29 Oct 2002 11:01:04 -0500

Stephen,

We've got

    <simpleType name="postalInfoEnumType">
      <restriction base="token">
        <enumeration value="loc"/>
        <enumeration value="int"/>
      </restriction>
    </simpleType>

I wanted to leave open the possibility of using something other than
ASCII (or UTF-8) for Postal information. So I requested a change which
is the addition of the "type" option to the <postalInfo> element. Some
others in the WG saw use in this, so we have it circa -05.

My idea of the use-case is a postal address encoded in Big5 for some
registrant in Taiwan, as an example.

What string is used to designate each value in the enum set I left to
the editor.

Is the non-normative text in draft-ietf-provreg-epp-contact-05.txt, 3.1.2,
correct? Every instance of interoperability is compromise.

It is simply wrong where it suggests that an XML conformant parser is going
to fail if the charset isn't UTF-8. Fortunately, if implementors assume the
language of 3.1.2 is controlling, that simply means they will be doing a
codeset conversion before emitting data, which wouldn't bother implementors
strictly following the XML standard for charsets.

Incidently, I don't agree with the statement that "Unicode (here, UTF-8)
is the form that works in every country". My time in Beijing with the CDNC
and JET was fairly corrosive of that belief-system, as was time spent with
Nii Quanor on African Languages, or time spent on Indigenous Languages of
the Americas. Mind, these aren't all exactly "DNS growth markets", but I
do care about one in particular.

The better distinction, in my mind, is between 7bit, and 8bit, which may
or may not be identical to some particular 7bit when restricted to just
7bits. Viz.,

    <simpleType name="postalInfoEnumType">
      <restriction base="token">
        <enumeration value="7bits"/>
        <enumeration value="8bits"/>
      </restriction>
    </simpleType>

Anyway, who cares what color the bikeshed is painted, so long as it fits
an ASCII bike for the bitwise handicapped, a UTF-8 bike for the Universalists,
and an 8-bit bike for bicyclists?

Scott,

The "MUST" on lines 610 and 931 and 1322 can be changed to "MAY", and be in
accord with the "MAY" at lines 297 (Individual and Organizational Names),
306 (Address), 612 (ibid). As these aren't normative, its discretionary to
the as editor as far as I'm concerned.

Cheers,
Eric