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

["Mark Davis" <mark@macchiato.com>]

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
>