[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [idn] Requirements I-D
One of the major differences between ISO 10646 and Unicode concerns Hebrew and Arabic. ISO
10646 does not define the bidi algorithm. I think the bidi algorithm is needed, therefore
both 10646 and Unicode should be cited.
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of RJ Atkinson
> Sent: Monday, May 15, 2000 12:09 PM
> To: Paul Hoffman / IMC
> Cc: firstname.lastname@example.org
> Subject: Re: [idn] Requirements I-D
> At 15:35 15-05-00 , Paul Hoffman / IMC wrote:
> >> >  - 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
> 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.
> >> >  - 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 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.
> >> remove pls. it actually is more a design then requirement.
> >Disagree. Going back to the diagram,  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,  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
> 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.