Comments on draft-ietf-idnabis-mappings-00
Debbie Garside
debbie at ictmarketing.co.uk
Wed May 27 16:45:21 CEST 2009
Hi Pete
I would like to propose the following wordsmithing:
1. Introduction
This document specifies the operations that applications apply to
user input in order to get it into a form acceptable by the
Internationalized Domain Names in Applications (IDNA) protocol
[I-D.ietf-idnabis-protocol].
Change to:
1. This document specifies the operations that should be applied to
user input in order to generate a form that is acceptable to the
Internationalized Domain Names in Applications (IDNA) protocol.
The document describes the architectural principles that underly this
function in section 2,
describes a general procedure that an application SHOULD implement in
section 3, and specifies an algorithm and mapping that an application
MAY implement in order to remain reasonably backward compatible with
the original version of the IDNA protocol in appendix A.
Propose change to:
This document describes the underlying architectural principles (Section 2)
and the general implementation procedure (Section 3) as well as an algorithm
with mappings in order to facilitate backwards compatibility (Appendix A).
It should be noted that this document is NOT specifying the behavior
of a protocol that appears "on the wire". It specifies an operation
that is to be applied to user input in order to prepare that user
input for use in an "on the network" protocol. As unusual as this
may be for an IETF protocol document, it is a necessary operation to
maintain interoperability.
I don’t like the use of “on the wire” in this paragraph but cannot come up
with anything sensible as I am not sure what you mean.
2. Architectural Principles
An application that implements the IDNA protocol
[I-D.ietf-idnabis-protocol] must take a set of user input and convert
that input to a set of Unicode code points. That user input might be
typed on a keyboard, written by hand onto some sort of digitizer,
spoken into a microphone and interpreted by a speech-to-text engine,
or otherwise.
Propose change to:
An application that implements the IDNA Protocol [I-D etc] MUST (or did you
really mean must?) take any user input set (use string here instead of set?)
and convert it to a set of Unicode code points. The user input may be
acquired by any of several different input methods all with differing
conversion processes to be taken into consideration e.g. keyboard input,
digitized hand writing, speech recording devices converted into text by
speech-to-text engine.
2. (cont.)
The process of taking any particular user input and
mapping it into a Unicode code point may be a simple one: If a user
strikes the "A" key on a US English keyboard, without any modifiers
such as the "Shift" key held down, in order to draw a Latin small
letter A ("a"), many (perhaps most) modern operating system input
methods will produce to the calling application the code point
U+0061, encoded in a single octet. Sometimes the process is somewhat
more complicated: A user might strike a particular set of keys to
represent a combining macron followed by striking the "A" key in
order to draw a Latin small letter A with a macron above it.
Depending on the operating system, the input method chosen by the
user, and even the parameters with which the application communicates
with the input method, the result might be the code point U+0101
(encoded as two octets in UTF-8 or UTF-16, four octets in UTF-32,
etc.), the code point U+0061 followed by the code point U+0304 (again,
encoded in three or more octets, depending upon the encoding
used) or even the code point U+FF41 followed by the code point U+0304
(and encoded in some form). And these examples leave aside the issue
of operating systems and input methods that do not use Unicode code
points for their character set. In every case, applications (with
the help of the operating systems on which they run and the input
methods used) MUST perform a mapping from user input into Unicode
code points.
I think this is rather long winded and confusing and would propose the
following:
Processes need to take into consideration that there might be several ways
in which user input can be converted into corresponding Unicode code points
and that this can be dependant on several contributing factors e.g.
operating system, input method. For example: A user might strike a
particular set of keys to represent a combining macron followed by striking
the "A" key in order to draw a Latin small letter A with a macron above it.
The result might be the code point U+0101 (encoded as two octets in UTF-8 or
UTF-16, four octets in UTF-32, etc.), the code point U+0061 followed by the
code point U+0304 (again, encoded in three or more octets, depending upon
the encoding used) or even the code point U+FF41 followed by the code point
U+0304. In designing implementation processes consideration should also be
given to systems that do not use Unicode code points for their character
set.
Please correct the following typos:
Last paragraph section 2.
In the next section, this document specifies a general algorithm that
applications SHOULD implement in order to produce Unicode code points
that will be valid under the IDNA protocol. Then, in appendix A, a
full mapping is specified that is substantially compatible with the
original IDNA protocol. An application MAY implement the full
mapping or MAY choose a different mapping.
Last paragraph Section 3
These are the minimal mappings that an application SHOULD do. Of
course, there are many others that MAY be done. In particular, a
mapping that is (not in) substantially compatible with [RFC3490] appears
below
in appendix A.
I have run out of time today to comment further but if you would like me to
go through the document paragraph by paragraph let me know (it is easy doing
revisions – the difficulty is in writing the first draft ;-) Well done!)
Feel free to accept or reject proposals.
Best regards
Debbie
Debbie Garside
Managing Director
ICT Marketing Ltd.
Corner House
Barn Street
Haverfordwest
Pembrokeshire SA61 2RD
Tel: +44 (0)1437 766441 Fax: +44 (0)1437 766173
HYPERLINK "http://www.ictmarketing.co.uk"Web: http://www.ictmarketing.co.uk
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.557 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009
17:53
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090527/ee97c2a3/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1088 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20090527/ee97c2a3/attachment-0001.jpeg
More information about the Idna-update
mailing list