[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[idn] =?UTF-8?B?Rlc6IEFkZGVkIHJlZmVyZW5jZSwgYW5kIHN5bmNoLiBvZiB0ZXJt?==?UTF-8?B?aW5vbG9neQ==?=

Title: FW: Added reference, and synch. of terminology

Hi!

        I had hoped the attached remarks (that I sent yesterday)
would have had time to be worked into the req. document before
any new version of the requirements document was issued.

        E.g. [13] talks about CESes, but does *definitely not*
mean CESes, but TESes.  Even so, I don't really understand
what [13] means, so maybe Paul is right that is should be
removed.  But I don't know since I don't understand what it
says.  At least it needs to be clarified also beyond replacing
"CES" with "TES".

        Further, Paul talks about ACEs, but the most closely
corresponding concept in UTR 17 is called TESes.

        So that everyone understand what is being talked about,
I strongly suggest that the terminology, and definitions, of
UTR 17 is adhered to.  Sometimes referring to TESes as CESes,
sometimes referring to them as ACEs is not helping anyone
understand the requirements document.

                Kind regards
                /kent k

 


Title: Added reference, and synch. of terminology

For increased mutual understandability, I suggest the following:

Both the requirements document and other IDN documents should
refer to Unicode Technical Report 17, Character Encoding Model
(http://www.unicode.org/unicode/reports/tr17/). Perhaps also to W3C's
Character Model for the World Wide Web (http://www.w3.org/TR/charmod/).
The terminology used in the IDN requirements document, comparison
document, and others should be aligned with the terminology
defined in UTR 17.  Thus, e.g., "ACE" to "TES" (Transfer Encoding
Syntax); and all of RACE, UTF-5 (and UTF-7), "hex of UTF-8", and
many other proposals are or include TESes (i.e. they are not UTFs,
despite the name of some of them).  The requirements document
should also give a short summary of the five terms defined in
UTR 17.  It should also point out that the IETF notion of "charset"
is not well-defined, and that two TESes (BASE64 and QP) are
singled out and not included in "charset", but any other CES+TES
is regarded as a "charset".

The requirements document should also point out that the use
of TESes may pose problems over and above the use of CESes,
like risk for lack of decode of the (chosen) TES even within
special applications, and total lack of decode (of any TES)
outside of certain portions of special applications.

                Kind regards
                /kent k