[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: General internationalization
- To: Paul Hoffman / IMC <firstname.lastname@example.org>
- Subject: Re: General internationalization
- From: James Seng <email@example.com>
- Date: Mon, 17 Jan 2000 16:20:04 +0800
- CC: firstname.lastname@example.org
- Delivery-date: Mon, 17 Jan 2000 00:27:46 -0800
- Envelope-to: email@example.com
Paul Hoffman / IMC wrote:
> Implementation must specify what character
> sets are used and how these characters are encoded in the DNS names
> and records.
> 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.
Ok, i think it is bad phrasing. I do not mean there is a requirement for
multiple character sets or encodings. What I intent to mean is there should
not be a requirement to reject multiple character sets. However, each
character sets are defined properly if multiple are used.
> Must allow I18C in DNS RR response.
> I don't know what an "RR response" is.
Resource Record. e.g A, CNAME, MX etc.
> 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?
Mix language need not be handled by language tagging. There are other ways to
do it, for example, if you are using Unicode, then it comes very naturely you
can mix European languages and East Asia language within the same label
without any tagging.
> 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.
Agreed. Will add something to the effect.