Re: [idn] Internationalized PTR draft submitted

[Mark Davis <markdavis@ispchannel.com>]

A couple of points.

1. I am a bit puzzled by your example:

4.3.2.1.in-addr.arpa  IPTR  zh-tw "traditional-chinese xxx.com in utf8"
                      IPTR  zh-cn "simplified-chinese xxx.com in utf8"
                      IPTR  ja    "japanese xxx.com in utf8"
                      IPTR  ko    "korean xxx.com in utf8"

Are the xxx really the same characters? Or is it more like (I will choose examples
from ascii):

4.3.2.1.in-addr.arpa  IPTR  en "english yahoo.com in utf8"
                      IPTR  de "german jahu.com in utf8"
                      IPTR fr    "french iaou.com in utf8"

or even

4.3.2.1.in-addr.arpa  IPTR  en "english commerce.com in utf8"
                      IPTR  de "german handel.com in utf8"
                      IPTR  it    "italian commercio.com in utf8"

In any event, if they are different characters and are to be used as domain names,
it would seem that they would need to be separately registered.

2. Perhaps you can motivate the use of this more, with a usage scenario?

3. The Unicode consortium does not encourage use of the plane 14 language tags.
When language tagging is necessary, it should be done with a higher protocol (such
as xml:lang in XML, or HTTP accept-lang).

James Seng wrote:

> Rick,
>
> No, I am not referring to charset. I actually mean *language* in this context.
> The charset could be in UTF-8 (or whatever we decide). I think you still
> havent understand the purpose of the draft but you got sidetracked when you
> see the word "language".
>
> Let me give you an example.
>
> 4.3.2.1.in-addr.arpa  IPTR  zh-tw "traditional-chinese xxx.com in utf8"
>                       IPTR  zh-cn "simplified-chinese xxx.com in utf8"
>                       IPTR  ja    "japanese xxx.com in utf8"
>                       IPTR  ko    "korean xxx.com in utf8"
>
> All 4 RR are xxx.com but in *different* translation. The charset used is
> UTF-8. The language here is different. Different clients would then choose the
> most appropriate IPTR RR to use as they see fit. (Whether you like it or not,
> clients do have locale.)
>
> On the other hand, I am also wondering would IPTR be useful actually
> considering we have language tag on Plane 14. Hence, it is possible to do
>
> 4.3.2.1.in-addr.arpa  PTR  "traditional-chinese tag + xxx.com in utf8"
>                       PTR  "simplified-chinese tag + xxx.com in utf8"
>                       PTR  "japanese tag + xxx.com in utf8"
>                       PTR  "korean tag + xxx.com in utf8"
>
> which would achieve the same thing as what IPTR is trying to do.
>
> Once again, let me state that I am not endorsing this method nor am I
> opposing.
>
> -James Seng
>
> Rick H Wesson wrote:
> > why are you on this language bent? If we have UTF-16 which represents
> > *all* languages why do we need a "tag" which can't be enforced to let us
> > know what language the name is in. In fact the name could be in many
> > languages.
> >
> > Lets banish the term language in this group, you obviously mean charset and
> > thinking that I only want the Japanese IDN for an Arabic name is useless.
> > Lets just understand that localization of PTR records isn't going to happn
> > with i18n names.
> >
> > -rick
> >
> > On Tue, 19 Sep 2000, James Seng wrote:
> >
> > > PTR has a failing which IPTR attempts to address, ie, locale info (language
> > > info).
> > >
> > > So a Japanese application may choose the Japanese IDN for the IP and the
> > > Korean application may choose the Korean IDN for the IP. How useful it is
> > > subjected to debate of cos.
> > >
> > > -James Seng
> > >
> > > Randy Bush wrote:
> > > >
> > > > multiple names for one ip is a red herring (idiom for something which
> > > > distracts one from the proper path).
> > > >
> > > > 666.42.7.1.in-addr.arpa.    PTR  my.dom.ain.
> > > >                             PTR  another.dom.ain.
> > > >                             PTR  yet.another.name.
> > > >
> > > > is perfectly legal and in common use.
> > > >
> > > > randy
> > >