[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: General internationalization
- From: Paul Hoffman / IMC <firstname.lastname@example.org>
- Date: Sat, 15 Jan 2000 17:25:47 -0800
- Delivery-date: Sat, 15 Jan 2000 17:25:06 -0800
- Envelope-to: email@example.com
2.2 Internationalization (I18N)
Internationalized characters must be allowed to be represented and used
in DNS names and records.
This is good.
Implementation must specify what character
sets are used and how these characters are encoded in the DNS names
This is bad. I strongly disagree that there is a *requirement* for
multiple character sets or encodings. Those who feel that this is a
requirement should say why it is so. I believe that adding "All" to the
beginning of the first sentence is sufficient.
This document does not define any character sets that should be used
for I18N. However, non-standard character sets must not be used to
avoid duplicate work on general I18N. If multiple character sets are
used, they must be clearly identified.
The DNS protocol should remain deterministic. No DNS element (resolver,
network, server or zonefile) should be required to do guess work.
I do not see why "network" or "zonefile" is here; they are inherently
not capable of doing guesswork. I'm not sure I even like "server" here.
I fully agree that resolvers should not have to do any guessing.
Must allow I18C in DNS RR response.
I don't know what an "RR response" is.
Must allow I18C in DNS TXT records.
I don't think I agree with this since it has nothing to do with domain names.
I18N of domain names should be able to handle mix language characters
and script, within the same label and/or within the same FQDN.
[JS: I hear at least one strong objections to this]
Yes, you hear right. I do not see a requirement for language tagging
in internationalized names. Can you say why this is required?
I suggest (again) the following requirements for this section:
Make no assumptions about where in a host name that
internationalization might appear. In other words, don't differentiate
between any part of a host name. Such restrictions now will likely
block important internationalization efforts in the future.
Do not make cultural restrictions in the protocol. For example,
assuming that a host name would only use a single script would
immediately restrict multinational organizations.
--Paul Hoffman, Director
--Internet Mail Consortium