[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Internationalized PTR draft submitted
- To: "Brian W. Spolarich" <firstname.lastname@example.org>
- Subject: Re: [idn] Internationalized PTR draft submitted
- From: James Seng <James@Seng.cc>
- Date: Tue, 19 Sep 2000 01:12:21 +0800
- Cc: Rick H Wesson <email@example.com>, firstname.lastname@example.org
- Delivery-date: Mon, 18 Sep 2000 10:15:00 -0700
- Envelope-to: email@example.com
Excellent analysis. I totally agreed with Brian here.
Just like to add one point:
While the draft focus on having the ability to return multiple domain names to
a single IP (in different language using UTF-8, choose one you like), there is
also an advantage to discuss how we can encapsulate IDN names in DNS packet in
PTR records and making sure it wouldnt break the application. IMHO, one of the
most likely break-and-die in IDN is when application receiving UTF-8 domain
names in PTR when it is expecting only ASCII. And most of the time, it is
embedded in the core infrastruture such as routers, mail gateway etc etc.
So far, no one/company/testbed has attempted to put UTF-8 in PTR. It would be
interested to see what would break.
"Brian W. Spolarich" wrote:
> On Mon, 18 Sep 2000, Rick H Wesson wrote:
> | please explain why having a tag for a hostname's PTR record, when it
> | is already encoded in a charset that encompance's *all* languages, is
> | benifitial.
> I think I see what this draft is getting at, although I'm not sure that
> its a good idea. The intent here (as I read it) is to ensure that the
> response received from the DNS can be interpreted in the user's native
> language and script. This seems to be coming from the particular point of
> view of speakers of the CJK languages (see the examples in the draft),
> where a reasonably similar word or phrase can be be represented in very
> divergent scripts and Unicode ranges. The idea then would be to be able
> to receive a response appropriate for (essentially) your 'locale'.
> I can see the logic here: when I do the forward query I'm starting with
> a name that I want in a language and character set I (presumably) know.
> When I do the reverse query I want to specify what language and character
> set I get the answer back in (or at least be able to have the resolver or
> application do something with the data based on my preferences...this
> issue isn't addressed in the draft). Actually I don't think the issue
> here is character set...the data will be in UTF-8, just different data
> depending on the user's preferences.
> My initial reaction was basically: 'Is this a problem that really needs
> solving?' PTR lookups are not performed by the vast majority of
> user-facing applications, and the only time that I can think of this data
> even being exposed in any application scenario is the case where some
> services (ftp, http) will complain or deny access to a resource if the A
> and PTR data do not match (which I think is stupid, but that's another
> discussion :-) This seems like a lot of protocol and implementation work
> to solve a problem that will only be experienced by a particularly small
> group of users (mostly sysadmins).
> I can see other, existing mechanisms that could solve or minimize the
> perceived problem that underlies this draft, which is 'how do I obtain
> meaningful (to me) information about a given IP address?'. While the DNS
> is one place to look, the various routing/AS information registries can
> also be used to support this.