Re: [idn] Internationalized PTR draft submitted

[Hongbo Shi <shi@goto.info.waseda.ac.jp>]

I really appreciate Harald's suggestion and the comments from others. :) 

Mingliang has explained why we suggest the
  "4.3.2.1.in-addr.arpa  IPTR  en "english yahoo.com in utf8" "
not 
  "lang-en.4.3.2.1.in-addr.arpa PTR "yahoo.com"". 
It is the real disadvantage of your ideas we consider. Sorry.

By the way, here is my thinking on the advantages/disadvantages that 
you raised. 
1) In the sample, lang-en.4.3.2.1.in-addr.arpa PTR "yahoo.com":
   I perfer to say the effect of the "lang-en" in your ideas is as 
   the same as the "en" in IPTR. The point is the procedure of the 
   "language" selection and lookup is not so much different. 
   Mean select a "language" before lookup (sending a query), 
     Or select a "language" after lookup (receiving a response).  
   I don't think it is possible to skip the "language" selection step.
   Therefore, I am sorry that I can't agree with the following ideas. 
   - does not hurt people not looking for/knowing about language info
   - one lookup gives you the answer for the language you want, no need 
     to carry stuff around for the languages you can't use anyway
    
2) The disadvantage that you don't get lang-cn and lang-jp as answers to 
   one query is not the disadvantage of your ideas. If you think it is a 
   disadvantage, I perfer to say that is a disadvantage of PTR. 
   In fact, the best expression is 
     "give answers in one query" is a new function of the IPTR.

3) About encoding, UTF-8, RACE or whatever idn wg decide. Just as
   what James Seng said before. 
   
   From: James Seng <James@Seng.cc>
   Subject: Re: [idn] Internationalized PTR draft submitted
   Date: Tue, 19 Sep 2000 04:34:05 +0800
   ...
   > 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). 

   Furthermore I don't think the encoding will affect the purpose of 
   the IPTR. It is not the main purpose of the IPTR. Hence, I don't 
   think it is a advantage of your ideas, a disadvantage of the IPTR. 

Ok, I arranged the advantages and disadvantages of your ideas. :)
If I am not wrong, and not misunderstand your ideas, here is the result.
Advantages:
- no new record types
- can be deployed by some owner of a reverse-mapping zone
                     ~~~~
  Modified "any" to "some". The reason is in the disadvantage.

Disadvantages:
- the reason which Mingliang has given in his email. 

Correct me, if I misunderstood your ideas. :)

Best Regards.

Hongbo Shi

From: Harald Alvestrand <Harald@Alvestrand.no>
Subject: Re: [idn] Internationalized PTR draft submitted
Date: Wed, 20 Sep 2000 11:12:52 -0400

> While we are in the area of making semi-perverse ideas:
> What about replacing
> 
> > > 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"
> 
> with
> 
> lang-en.4.3.2.1.in-addr.arpa PTR "yahoo.com"
> lang-de.4.3.2.1.in-addr.arpa PTR "jähu.com" (ACE encoded)
> lang-fr.4.3.2.1.in-addr.arpa PTR "iaou.com"
> *.4.3.2.1.in-addr.arpa          PTR "anylanguage.yahoo.com"
> 4.3.2.1.in-addr.arpa PTR                "yahoo.com" (normal clients)
> 
> Advantages:
> - can be deployed by any owner of a reverse-mapping zone
> - does not hurt people not looking for/knowing about language info
> - no new record types
> - using RACE (or the ACE we agree on) gives backwards compatibility
> - one lookup gives you the answer for the language you want, no need to 
> carry stuff around for the languages you can't use anyway
> 
> Disadvantage is that you don't get lang-cn and lang-jp as answers to one query.
> 
>              Harald
> 
> --
> Harald Tveit Alvestrand, alvestrand@cisco.com
> +47 41 44 29 94
> Personal email: Harald@Alvestrand.no
> 
>