RE: [idn] Where to do form-folding?

["Seungik Lee" <silee@icu.ac.kr>]

Agree.

However, we should focus on the case-folding of the current DNS which is
processed in server-side.
Even if the protocol specification specifies the form-folding in
client-side, we cannot avoid the one in server-side, I think.

Arising with this topic: when I manage zone file, should I store
multi-lingual domain names encoded into UTF-8?
If so, I should convert some multi-lingual domain names into UTF-8 code with
an additional encoding tool and save the *unreadable* code to add records.
Yes, that's OK.
But, let's assume that I'm a new NS administrator. Then, I would have a
headache on zone file which contains a burden of *unreadable* record data.
:(

In the protocol specification, I think, form-folding should be processed in
resolvers.

But in the view of implementations, we should insert the form-folding
operation into servers too.
That's because of the reason described above, and backward compatibilities
with non-standardized UTF-8 domain name servers, e.g. Microsoft DNS
resolvers/servers.

Of course that the IDN wg is not for specific implementations or practical
operations, but form-folding issue is much related with those things.

If I misunderstood, correct me please. :)


- silee

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On
> Behalf Of A. Vine
> Sent: Saturday, July 22, 2000 1:55 AM
> To: idn@ops.ietf.org
> Subject: Re: [idn] Where to do form-folding?
>
>
> All,
> To add to Dan's comments:
> Much normalization is expected to take place at the point of
> generation from the
> charset perspective.  In other words, the client is expected to
> normalize the
> text as it is created.  This is the case for much of the text
> processing world.
> Logistically it has been found that if it has not been done at
> the point of
> entry, then the data will be inspected for normalization many,
> many times in its
> lifetime, reducing efficiency.
>
> So, since standards are stating, or at least highly recommending,
> normalization
> at the point of creation, it's not a huge step to add canonicalization for
> IDNs.  Of course, the specification would have to be precise.
>
> It's true it is a bigger burden on the client.  But as Dan
> pointed out, it has
> some distinct advantages.  And it has a precedent.
>
> Andrea
> --
> Andrea Vine, avine@eng.sun.com, iPlanet i18n architect
> "In these Regulations any reference to a regulation is a
> reference to a regulation of these Regulations"
> -- Education (UK Student Loans) Regulations 1997
>
> Dan Oscarsson wrote:
> >
> > Hi
> >
> > Even if it is summer, some of you are hopefully still active. At
> > least some of you going to the IETF meeting.
> >
> > Here is one thing we could discuss and that could be discussed
> > at the meeting.
> >
> > The question is: Where should form-folding be done?
> >
> ...
> > There are many applications that compare hosts or domain names.
> > For example: sendmail and many browsers.
> > These applications should also compare IDNs as equal in the same way
> > that DNS does. This means that they also need to implement form-folding.
> > If the resolver libraries include the standard implementation
> > of form-folding (and name comparing), and had the API public, all
> > applications could use it instead of implementing their own.
> >
> > So by choosing 2) we can get the additional benefit of supplying
> > a standard place for applications to the routines to do
> > form-folding and IDN comparing. And thus reducing the risk of many
> > implementations, some that will do it wrongly.
> >
> > Thats it. What do you think? Am I missing some important aspects to
> > make the best choice? Maybe it is something that could be
> > discussed at the meeting.
> >
> > Regards,
> >
> >   Dan
>
>
>
>
>
>