Re: [idn] Charter, refocus

["James Seng/Personal" <jseng@pobox.org.sg>]

Hi Dan,

Thanks. In other words, we are in agreement with the Action Items, each
one could have more than one RFCs. What you want is an detailed RFCs for
each Action Items. IMHO, we can put each RFCs into the goal & milestone
sections if and when we have those RFCs.

-James Seng

----- Original Message -----
From: "Dan Oscarsson" <Dan.Oscarsson@trab.se>
To: <idn@ops.ietf.org>; <jseng@pobox.org.sg>
Sent: Saturday, November 24, 2001 8:13 PM
Subject: Re: [idn] Charter, refocus


>
> >
> >I am trying to get an update on the proposed charter. Note that I am
not
> >disagreeing with you, but just trying to find out the differences
> >between your RFC vs our proposed Action Item(s).
> >
> >> So what I see we need for DNS is:
> >>
> >> 1) An RFC stating the standard normalisation of domain names.
> >>
> >> 2) An RFC defining how domain names must be matched. As a minimum
> >>    it must require case-insentive matching for characters with
case.
> >
> >What is differences between your (1) & (2) vs
> >
> >"4. A standard track specification on normalization of domain name
> >identifiers for the purpose of string comparisons. This document may
> >include case folding, map outs, and prohibited characters."
>
> The above may mean the same as my (1) & (2).
> I wanted to make it clear that we should have one normalised format
> for all domain names (both host names, and all other types).
> This is to have a simple foundation for all software handling
> text strings. Normalisation may not do case folding.
> (1) is not only for comparisons of names, it is also for
> easy character handling and analysis.
>
> And the second should define how names are matched. That is how
> what rules define which names match as equal.
> For example: Abc.com and ABC.com match as equal.
> This is done on top of the (1) normalised strings, when you need
> to check if two domain names represent the same name.
> The character manipulation you may do to compare names, may change
> the name into something different than the "original" normalised
> form.
>
>
>
> >
> >
> >> When that is done, we can add:
> >> 3) An RFC for ACE so we have a standard way to encode domain names
> >>    in ASCII,  complying with the legacy "host name" character
> >> restriction.
> >
> >What is differences
> >
> >"3. A standard track specification on an ASCII Compatible Encoding
> >(ACE), to be used in the standard track specification on permitting
> >international characters in domain names."
>
> No difference. I just included all things to have all in there.
>
> >
> >> 4) An RFC updating what applications should accept as "host names".
> >
> >Hmm, how about modify Action Item 4 to
> >
> >"A standard track specification on normalization of domain name
> >identifiers for the purpose of string comparisons. This document(s)
may
> >include case folding, map outs, and prohibited characters, and what
is
> >acceptable as host names."
>
> You could, but I prefer to have the items as three different things.
>
> 1) is for how character data should be normalised everywhere.
>
> 2) is how compare domain names to see who are equal.
>
> 4) is what applications accept as a "host name".
>
> In many parts of DNS only 1) is needed.
> 2) is used when comparing names.
> 4) is used by applications restricting character allowed for
> "host names".
>
> With the combined text above, it might result in one document
> most see as only specifying host names instead of many things
> common for all parts of DNS.
>
> >
> >> 5) An RFC how to layer ACE on top of the current DNS protocol to
allow
> >>    legacy software to handle new domain names (for example IDNA).
> >>
> >> 6) An RFC defining how DNS itself can handle UCS based domain names
> >>    using UTF-8.
> >
> >Yours is a more specific action to
> >
> >"2.  A standard track specification on permitting international
> >characters in domain names, including specifying any transition
issues."
>
> Yes, I wanted to be specific to make things clear and to avoid
> missing something.
>
> I have felt that we have had to much focus on just "host names".
> Especially with my 1) and 2) I wanted a common base for
> DNS to stand on, before going to specific issues like
> what characters are allowed in host names.
>
>    Dan
>