Re: [idn] draft-ietf-idn-requirements-04.txt (revised copy)

[James Seng <James@Seng.cc>]

I would prefer not to go down a path where there is any discussing of
"cultural" in the doc.

AFAIK, only DNSSEC need the names to be sorted, and even so, it need not be in
any particular order so long you can use it to determine if there is any
domain in between.

The only question is where this sorting occur (before/after nameprep and
before/after transformation to UTF-8 or ACE).

-James Seng

Mark Davis wrote:
> 
> Your additions look good. As to your "possible new", I'd suggest:
> 
> POSSIBLE NEW:
> The DNS has to match a host name in a request with a host name held
> in one or more zones. It also needs to sort names into a deterministic
> order . (This order need not be in any culturally correct order: sorting by
> coded representation is sufficient). It is expected that some sort of
> canonicalization algorithm will be used as the first step of these
> processes.
> 
>    Note: if sorted lists are to be presented to end users, culturally
>    correct order should be used - see [UTS10].
> 
> ----- Original Message -----
> From: "Karlsson Kent - keka" <keka@im.se>
> To: "Zita Wenzel" <zita@ISI.EDU>
> Cc: <idn@ops.ietf.org>
> Sent: Thursday, October 05, 2000 08:14
> Subject: RE: [idn] draft-ietf-idn-requirements-04.txt (revised copy)
> 
> >
> >
> > ============================================================
> > OLD:
> >
> > 1.1 Definitions and Conventions
> >
> > A language is a way that humans interact. In computerised form, a text
> >
> > ----------------------------------------------------------
> > NEW:
> >
> > 1.1 Definitions and Conventions
> >
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> > document are to be interpreted as described in [RFC2119].
> >
> > Examples quoted in this document should be considered as a method to
> > further explain the meanings and principles adopted by the document.
> > It is not a requirement for the protocol to satisfy the examples.
> >
> > In computerised form, a text
> >
> > -----------------------------------------------------------------------
> > That was just text that inadvertently got lost.  I've also deleted
> > the sentence that Mark did not like.
> > =====================================================================
> >
> > OLD:
> > [11] Internationalized characters MUST be allowed to be represented and
> > used in DNS names and records. The protocol MUST specify what charset is
> > used when resolving domain names and how characters are encoded in DNS
> > records.
> > -----------------------------------------------------------
> > NEW:
> > [11] Characters for letters, digits, ideographs, and syllables,
> > including combining characters, used in orthographies around the
> > world MUST be allowed to be represented and used in DNS names and
> > records. The protocol MUST specify what charset is used when
> > resolving domain names and how characters are encoded in DNS records.
> >
> > ============================================================
> >
> > OLD:
> > [14] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
> > only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
> > non-ambiguous.
> > ------------------------------------------------------------
> >
> > NEW:
> > [14] The protocol SHALL NOT invent any new CM, and SHOULD NOT invent
> > any new TES for the purpose of IDN. Each CM and TES that can be used
> > for IDN MUST be unambigous. Which CM (and TES, if any) is in use for
> > any given IDN MUST be unambiguous.
> >
> > ==============================================================
> > OLD:
> > [30] If the charset can be normalized, then it SHOULD be normalized
> > before it is used in IDN. Normalization SHOULD follow [UTR15].
> > (conflict)
> >
> > ------------------------------------------------------------
> > NEW:
> > [30] If the charset can be normalized, then it SHOULD be normalized
> > before it is used in IDN. Normalization SHOULD follow [UAX15].
> >
> > ==============================================================
> > OLD:
> > The DNS has to match a host name in a request with a host name held
> > in one or more zones. It also needs to sort names into order. It is
> > expected that some sort of canonicalization algorithm will be used as
> > the first step of this process.
> > ------------------------------------------------------------
> > POSSIBLE NEW:
> > The DNS has to match a host name in a request with a host name held
> > in one or more zones. It also needs to sort names into a deterministic
> > order (it need not be in any culturally correct order, sorting by
> > coded representation is suffient). It is expected that some sort of
> > canonicalization algorithm will be used as the first step of these
> > processes.
> >
> > ---------------------------------------------------------
> > I'm not sure about this change.
> >
> > For the purpose of sorting (domain) names, for human consumption,
> > UTS 10 (Unicode Technical Standard 10) should be used.
> >
> > But I guess a sorting that is not for human consumption is intended,
> > and then I guess any specific deterministic sorting can be applied
> > (like "binary" (code point) ordering after 'canonicalisation').  That
> > is, however, not clear from the requirements text.
> >
> > ================================================================
> > POSSIBLY ADD:
> >
> > [UTS10]     "Unicode Collation Algorithm", Unicode Technical Standard #10,
> >             http://www.unicode.org/unicode/reports/tr10/, 2000-08-31,
> >             M. Davis and K. Whistler, Unicode Consortium.
> >
> > [ISO14651]  ISO/IEC 14651, "International string ordering and
> > comparison -- Method for comparing character strings
> > and description of the common template tailorable ordering".
> >
> > -----------------------------------------------------------------
> >
> > These could be useful references; even if not needed internally
> > for IDNs (in a locale-independent way), I'm sure some UIs will
> > want to order also IDNs in a culturally correct, and locale-dependent,
> > way.
> >
> > Like the Unicode standard and 10646, UTS 10 and 14651 are "twin"
> > standards (though in neither case identical in all respects).
> > -----------------------------------------------------------------
> >
> > All of the references should be edited for consistency.
> >
> > ================================================================
> >
> > /Kent Karlsson
> >