RE: [idn] Requirements I-D

[Jonathan Rosenne <rosenne@qsm.co.il>]

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.

Jony

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf Of RJ Atkinson
> Sent: Monday, May 15, 2000 12:09 PM
> To: Paul Hoffman / IMC
> Cc: idn@ops.ietf.org
> Subject: Re: [idn] Requirements I-D
>
>
> 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
>
>