Re: [idn] draft-ietf-idn-requirements-04.txt

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

Hi, all.
Thanks your idea, Harald. :)
I think it is a good idea, simple and reasonable idea. 

From: Harald Alvestrand <Harald@Alvestrand.no>
Subject: Re: [idn] draft-ietf-idn-requirements-04.txt
Date: Thu, 05 Oct 2000 10:51:33 +0200

> >From: Zita Wenzel <zita@ISI.EDU>
> >Subject: [idn] draft-ietf-idn-requirements-04.txt
> >Date: Mon, 2 Oct 2000 20:24:50 GMT
> >
> > > OLD:  [37] The protocol MUST work for all features of DNS, IPv4, and
> > > IPv6.
> > >
> > > NEW:  [2.6] The protocol MUST work for all features of DNS, IPv4, and
> > > IPv6.  The protocol MUST NOT allow an IDN to be returned to a requestor
> > > that requests the IP-to-(old)-domain-name mapping service.

NEWER: [2.6] The protocol MUST work for all freatures of DNS, IPv4, and IPv6.
       The protocol MUST NOT allow an IDN to be returned to a reauestor that
       requests the IP-to-(old)-domain-name mapping service. If there is only
       IDN exists, then DNSSEC MUST sign an ACE to avoid an empty answer 
       section. [RFC2535]

> 1) Suppress the PTR record containing the IDN. This has bad implications 
> for DNSSEC, since DNSSEC signs record sets, not individual records.
   
  Right. 
  In addition, if "a set of IDNs only", means a chain of IDNs, 
  it is very difficult to detect which one should be used in PTR records
  without PTR modification. like a loop without beginning and end.

> 2) Use a new record type (IPTR) for storing the IDN, so that old clients do 
> not see it
> 3) Return a PTR containing an ACE. This means that DNSSEC must sign an ACE, 
> and that clients will see even more meaningless names than 
> "123.234.123.wcom.com" (a not-unusual style of PTR value to see now).
>
> 2 and 3 can be combined.... if we want to force the choice, or want to 
> specify requirements forcing the choice, please suggest requirements text.

  Right. Honestly until reading Zita's requirements, I concerned this problem.
  In short, IPTR is invisible to those old clients, just like what Harald 
  indicated. I have concerned that our first draft was written based on a 
  "a set of iDNs with an old domain name" consideration. 
  Therefore, I am going to update it as quickly as I can and think about 
  the IPTR based on the following cases.
 
  CASE "IDNs only or an IDN only":  
     PTR MUST NOT allow an IDN to be returned to a requestor that requests
     the IP-to-(old)-domain-name mapping service. PTR record SHOULD NOT be 
     NULL. DNSSEC MUST sign an ACE. 
     IP-to-IDN mapping service MUST be provided by IPTR.
  /*
     "DNSSEC MUST sign an ACE" based on the consideration [RFC2535]. 
    [RFC2535]
      2.3.2 Authenticating Name and Type Non-existence
      2.4 DNS Transaction and Request Authentication
      5.  Non-existent Names and Types       
  */    

  CASE "IDNs with an old domain name":  
     IP-to-IDN mapping service MUST be provided by IPTR.

  CASE "old domain name only":  
     Don't care. :)
  /*
     Though both PTR and IPTR records will exist. 
     Furthermore, they are maybe different. 
     Such as, 
        52.0.0.10.in-addr.arpa   IN   PTR          C.ISI.EDU.
        52.0.0.10.in-addr.arpa   IN   IPTR   "en"  USC-ISIC.ARPA.  
        USC-ISIC.ARPA            IN   CNAME        C.ISI.EDU.
     <the samples above are from [RFC1034]>
     As a matter of fact, above representations also appear in current 
     PTR records. 
        52.0.0.10.in-addr.arpa   IN   PTR          C.ISI.EDU. 
        52.0.0.10.in-addr.arpa   IN   PTR          USC-ISIC.ARPA.
     As the best effort, I'd like to suggest that in the "old domain name 
     only" case, PTR record and IPTR record SHOULD be the same, but not 
     let the English/Malay Language domain names away from IDNs. 
  */

Correct me, if I am wrong. 

Best Regards. 

P.S. Sorry for the Delay. My neck ache caused me could not nod my head to 
     say "yes, I agree with it" in time. Now I am alright. :)

Hongbo Shi