Re: [idn] Requirements I-D

[RJ Atkinson <rja@inet.org>]

At 15:35 15-05-00 , Paul Hoffman / IMC wrote:
>>  > [12] - Keep. It lays down the restrictions on protocols that demand
>>>  multiple charsets
>>
>>It is confusing. And it is also written in such a way that there is no other
>>CCS(s) other than ISO10646 can meet the requirement so it become 
>>pointless. :P
>>
>>1. If the WG has decided to use ISO10646 (like it is written), then
>>    elimiate this and just say "Unicode only".
>>
>>2. If the WG is willing to be more open minded, then it should rewrite it to
>>    be more friendly for multiple CCS design.
>
>I would be perfectly happy with the first choice. Does anyone here feel 
>that the eventual IDN might have multiple charsets? If so, speaking up now 
>would be good.

I would propose saying that the WG has decided to use ISO-10646.  To the 
extent
that UNICODE is different from ISO, IETF should follow the ISO 
specifications, IMHO.
To the extent that UNICODE is the same as 10646, then UNICODE folks ought not
mind citing ISO-10646.

>>  > [36] - Keep. DNSSEC is pretty darn important, and we aren't going to
>>>  be able to say that IDN is more important than DNSSEC.
>>
>>I am inclined to say "IDN must be compatible with DNSSEC" and leave it as
>>that.
>
>That sounds good.

Fine with me.  The critical thing is that (via some method), one can use
IDN and DNSSEC at the same time so that DNSSEC will be able to provide
authentication of IDNs.


>>[29] remove pls. it actually is more a design then requirement.
>
>Disagree. Going back to the diagram, [29] says "all canonicalization must 
>be done before entering the big box through the DNS service interface". 
>Without such a requirement, it is not clear where in the big box 
>canonicalization might be done. Unless you are proposing a very strict 
>structure for the mushy parts inside the large box so that you can say 
>which parts handle canonicalization and which parts do not, [29] is 
>needed. And I think it is way too late in the deployment of DNS to start 
>saying exactly how the parts of the big box must be structured. It is fine 
>to require that the IDN say exactly where canonicalization will happen.

Other opinions:

- We must have some single global form of canonicalisation.
   I think its a lot more important to have one form (for global 
interoperability)
   than to have the perfect form.  The UNICODE work might be recycled for 
this purpose,
   since ISO does not appear to have anything we can recycle (at the moment).

- The functional location for canonicalisation needs to be standardised so
   that we have global interoperability.  If one server implementation requires
   that it only receive queries in canonical form, that won't interoperate with
   a client that assumes the server performs canonicalisation, for example.

- Case-folding needs to be locale-independent because there is no way to
   communicate "locale" as part of DNS queries.  Alphabetic characters should
   have a well-defined case folding.  Ideogrammatic characters might not have
   any case folding, of course.

Ran
rja@inet.org