Date: 17 Jan 2008
From: Mark Davis
Subject: Stabilized Strings (UAX 15)

We had added Stabilized Strings for use by the IETF at the request of John Klensin. Since this meeting is the go/no-go decision on UAX #15, we contacted John to ensure that that feature was still required. Here is his reply (copied by permission).


None of us can speak for the IETF, but let me try for an answer
that may avoid your figuring out how to get an official IETF
position.  It has two elements:

(1) If IDNAbis stays on its current course, this work is not
really needed because the "treat as NEVER if not assigned in the
current version" approach means that unassigned code points are
treated in a different way and do not require this normalization
procedure.   Obviously, should IDNAbis take some other course
such as trying for a simple update of Stringprep to Unicode 5.1,
as some of your recent notes seem to imply that you would
prefer, that question would need to be reevaluated.  And even if
we stay with the current model but recommend compatibility
mapping as a user interface matter, it would appear very wise to
apply this type of procedure.

(2) It seems to me that there are an number of applications of
Unicode strings for which very long term stability (in the
normal, not necessarily Unicode, sense of that term) is very
important.  Unless it is impossible, for example, that any
unassigned code point will eventually be assigned to a
compatibility character -- e.g., such that NFKC normalization of
the string when the code point is still unassigned will produce
the code point itself and NFKC normalization after assignment
would yield a different value -- then I think we can anticipate
several other applications, both involving Internet protocols
and otherwise, for which NPSS will be important.   I think that
criterion, and hence the requirement, would apply to NFC and NFD
as well (I have to admit never having thought about NFKD in this