[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Internationalized PTR draft submitted
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
>
>