One document matched: draft-ietf-precis-problem-statement-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY bibxml2rfc-informative SYSTEM "draft-ietf-precis-problem-statement-03.xml-informative">
<!ENTITY bibxml2rfc-normative SYSTEM "draft-ietf-precis-problem-statement-03.xml-normative">
]>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-ietf-precis-problem-statement-03.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<front>
<title>Stringprep Revision Problem Statement</title>
<author initials="M." surname="Blanchet" fullname="Marc Blanchet">
<organization>Viagenie</organization>
<address>
<postal>
<street>2600 boul. Laurier, suite 625</street>
<city>Quebec</city>
<region>QC</region>
<code>G1V 4W1</code>
<country>Canada</country>
</postal>
<email>Marc.Blanchet@viagenie.ca</email>
<uri>http://viagenie.ca</uri>
</address>
</author>
<author initials="A." surname="Sullivan" fullname="Andrew Sullivan">
<address>
<postal>
<street>519 Maitland St.</street>
<city>London</city>
<region>ON</region>
<code>N6B 2Z5</code>
<country>Canada</country>
</postal>
<email>ajs@anvilwalrusden.com</email>
</address>
</author>
<date month="July" day="11" year="2011"/>
<abstract>
<t>
Using Unicode codepoints in protocol strings that expect
comparison with other strings requires preparation of the
string that contains the Unicode codepoints.
Internationalizing Domain Names in Applications (IDNA2003)
defined and used Stringprep and Nameprep. Other protocols
subsequently defined Stringprep profiles. A new approach
different from Stringprep and Nameprep is used for a revision
of IDNA2003 (called IDNA2008). Other Stringprep profiles need
to be similarly updated or a replacement of Stringprep needs to
be designed. This document outlines the issues to be faced by
those designing a Stringprep replacement.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Internationalizing Domain Names in Applications (IDNA2003)
<xref target="RFC3490"/>, <xref target="RFC3491" />, <xref
target="RFC3492" />, <xref target="RFC3454" /> described a
mechanism for encoding Unicode labels making up
Internationalized Domain Names (IDNs) as standard DNS labels.
The labels were processed using a method called Nameprep <xref
target="RFC3491"/> and Punycode <xref target="RFC3492"/>.
That method was specific to IDNA2003, but is generalized as
Stringprep <xref target="RFC3454"/>. The general mechanism
can be used to help other protocols with similar needs, but
with different constraints than IDNA2003.
</t>
<t>Stringprep defines a framework within which protocols define their
Stringprep profiles. Known IETF specifications using Stringprep are
listed below:
<list style="symbols">
<t>The Nameprep profile <xref target="RFC3490"/> for use in
Internationalized Domain Names (IDNs);</t>
<t>NFSv4 <xref target="RFC3530" /> and NFSv4.1 <xref
target="RFC5661" />;</t>
<t>The iSCSI profile <xref target="RFC3722"/> for use in
Internet Small Computer Systems Interface (iSCSI) Names;</t>
<t>EAP <xref target="RFC3748" />;</t>
<t>The Nodeprep and Resourceprep profiles <xref
target="RFC3920"/> for use in the Extensible Messaging and
Presence Protocol (XMPP), and the XMPP to CPIM mapping <xref
target="RFC3922" /> (the latter of these relies on the former);</t>
<t>The Policy MIB profile <xref target="RFC4011"/> for use in
the Simple Network Management Protocol (SNMP);</t>
<t>The SASLprep profile <xref target="RFC4013"/> for use in
the Simple Authentication and Security Layer (SASL), and SASL
itself <xref target="RFC4422" />;</t>
<t>TLS <xref target="RFC4279" />;</t>
<t>IMAP4 using SASLprep <xref target="RFC4314" />;</t>
<t>The trace profile <xref target="RFC4505"/> for use with the
SASL ANONYMOUS mechanism;</t>
<t> The LDAP profile <xref target="RFC4518"/> for use with
LDAP <xref target="RFC4511" /> and its authentication methods
<xref target="RFC4513" />;</t>
<t>Plain SASL using SASLprep <xref target="RFC4616" />;</t>
<t>NNTP using SASLprep <xref target="RFC4643" />;</t>
<t>PKIX subject identification using LDAPprep <xref
target="RFC4683" />;</t>
<t>Internet Application Protocol Collation Registry <xref
target="RFC4790" />;</t>
<t>SMTP Auth using SASLprep <xref target="RFC4954" />;</t>
<t>POP3 Auth using SASLprep <xref target="RFC5034" />;</t>
<t>TLS SRP using SASLprep <xref target="RFC5054" />;</t>
<t>IRI and URI in XMPP <xref target="RFC5122" />;</t>
<t>PKIX CRL using LDAPprep <xref target="RFC5280" />;</t>
<t>IAX using Nameprep <xref target="RFC5456" />;</t>
<t>SASL SCRAM using SASLprep <xref target="RFC5802" />;</t>
<t>Remote management of Sieve using SASLprep <xref target="RFC5804" />;</t>
<t>The i;unicode-casemap Unicode Collation <xref target="RFC5051" />.</t>
</list>
</t>
<t>There turned out to be some difficulties with IDNA2003, documented
in <xref target="RFC4690" />. These difficulties led to a new IDN
specification, called IDNA2008 <xref target="RFC5890" />, <xref
target="RFC5891" />, <xref target="RFC5892" />, <xref target="RFC5893"
/>. Additional background and explanations of the decisions embodied
in IDNA2008 is presented in <xref target="RFC5894" />. One of the
effects of IDNA2008 is that Nameprep and Stringprep are not used at
all. Instead, an algorithm based on Unicode properties of codepoints
is defined. That algorithm generates a stable and complete table of
the supported Unicode codepoints. This algorithm is based on an
inclusion-based approach, instead of the exclusion-based approach of
Stringprep/Nameprep.
</t>
<t>This document lists the shortcomings and issues found by
protocols listed above that defined Stringprep profiles. It also
lists some early conclusions and requirements for a potential
replacement of Stringprep.</t>
</section>
<section title="Issues raised during newprep BOF">
<t>During IETF 77, a BOF discussed the current state of the
protocols that have defined Stringprep profiles <xref
target="NEWPREP" />. The main conclusions from that discussion
were as follows:
<list style="symbols">
<t>Stringprep is bound to a specific version of Unicode:
3.2. Stringprep has not been updated to new versions of
Unicode. Therefore, the protocols using Stringprep are stuck to
Unicode 3.2.</t>
<t>The protocols need to be updated to support new versions of
Unicode. The protocols would like to not be bound to a specific
version of Unicode, but rather have better Unicode agility in
the way of IDNA2008. This is important partly because it is
usually impossible for an application to require Unicode 3.2;
the application gets whatever version of Unicode is available on
the host.</t>
<t>The protocols require better bidirectional support (bidi) than
currently offered by Stringprep. </t>
<t>If the protocols are updated to use a new version of
Stringprep or another framework, then backward compatibility
is an important requirement. For example, Stringprep is
based on and may use NFKC <xref target="UAX15" />, while
IDNA2008 mostly uses NFC <xref target="UAX15" />.</t>
<t>Protocols use each other; for example, a protocol can use
user identifiers that are later passed to SASL, LDAP or another
authentication mechanism. Therefore, common set of rules or
classes of strings are preferred over specific rules for each
protocol.</t>
</list>
</t>
<t>Protocols that use Stringprep profiles use strings for
different purposes:
<list style="symbols">
<t>XMPP uses a different Stringprep profile for each part of the
XMPP address (JID): a localpart which is similar to a username and
used for authentication, a domainpart which is a domain name and a
resource part which is less restrictive than the localpart.</t>
<t>iSCSI uses a Stringprep profile for the IQN, which is
very similar to (often is) a DNS domain name. </t>
<t>SASL and LDAP uses a Stringprep profile for usernames.</t>
<t>LDAP uses a set of Stringprep profiles.</t>
</list>
</t>
<t>During the newprep BOF, it was the consensus of the
attendees that it would be highly desirable to have a
replacement of Stringprep, with similar characteristics to
IDNA2008. That replacement should be defined so that the
protocols could use internationalized strings without a lot of
specialized internationalization work, since
internationalization expertise is not available in the
respective protocols or working groups.</t>
</section>
<section title="Major Topics for Consideration" anchor="topics">
<t>This section provides an overview of major topics that a
Stringprep replacement needs to address. The headings
correspond roughly with categories under which known
Stringprep-using protocol RFCs have been evaluated. For the
details of those evaluations, see <xref target="knowncases" />.</t>
<section title="Comparison">
<section title="Types of Identifiers" anchor="buckets">
<t>Following <xref target="I-D.iab-identifier-comparison"
/>, we can organize identifiers into three classes in
respect of how they may be compared with one another:</t>
<t>
<list style="hanging">
<t hangText="Absolute Identifiers">Identifiers that can be compared
byte-by-byte for equality.</t>
<t hangText="Definite Identifiers">Identifiers that have a
well-defined comparison algorithm on which all parties
agree.</t>
<t hangText="Indefinite Identifiers">Identifiers that have
no single comparison algorithm on which all parties agree.</t>
</list>
</t>
<t>Definite Identifiers include cases like the comparison of
Unicode code points in different encodings: they do not match
byte for byte, but can all be converted to a single encoding
which then does match byte for byte. Indefinite Identifiers are
sometimes algorithmically comparable by well-specified subsets
of parties. For more discussion of these categories, see <xref
target="I-D.iab-identifier-comparison" />.
</t>
<t>The section on treating the existing known cases, <xref
target="knowncases" /> uses these categories.</t>
</section>
<section title="Effect of comparison">
<t>The three classes of comparison style outlined in <xref
target="buckets" /> may have different effects when applied.
It is necessary to evaluate the effects if a comparison
results in a false positive, and what the effects are if a
comparison results in a false negative, especially in terms
of the consequences to security and usability.</t>
</section>
</section>
<section title="Dealing with characters">
<t>This section outlines a range of issues having to do with
characters in the target protocols, and spends some effort to
outline the ways in which IDNA2008 might be a good analogy to
other protocols, and ways in which it might be a poor one.</t>
<section title="Case folding, case sensitivity, and case
preservation" anchor="case">
<t>In IDNA2003, labels are always mapped to lower case before
the Punycode transformation. In IDNA2008, there is no mapping
at all: input is either a valid U-label or it is not. At the
same time, upper-case characters are by definition not valid
U-labels, because they fall into the Unstable category
(category B) of <xref target="RFC5892" />.</t>
<t>If there are protocols that require upper and lower cases be
preserved, then the analogy with IDNA2008 will break down.
Accordingly, existing protocols are to be evaluated according
to the following criteria:</t>
<t><list style="numbers">
<t>Does the protocol use case folding? For all blocks of
code points, or just for certain subsets?</t>
<t>Is the system or protocol case sensitive?</t>
<t>Does the system or protocol preserve case?</t>
</list></t>
</section>
<section title="Stringprep and NFKC">
<t>Stringprep profiles may use normalization. If they do,
they use NFKC <xref target="UAX15" />. It is not clear that
NFKC is the right normalization to use in all cases. In <xref
target="UAX15" />, there is the following observation
regarding Normalization Forms KC and KD: "It is best to think
of these Normalization Forms as being like uppercase or
lowercase mappings: useful in certain contexts for identifying
core meanings, but also performing modifications to the text
that may not always be appropriate." For things like the
spelling of users' names, then, NFKC may not be the best form
to use. At the same time, one of the nice things about NFKC
is that it deals with the width of characters that are
otherwise similar, by canonicalizing half-width to full-width.
This mapping step can be crucial in practice. The WG will
need to analyze the different use profiles and consider
whether NFKC or NFC is a better normalization for each
profile.</t>
<t>For the purposes of evaluating an existing example of
Stringprep use, it is helpful to know whether it uses no
normalization, NFKC, or NFC.</t>
</section>
<section title="Character mapping" anchor="mapping">
<t>Along with the case mapping issues raised in <xref
target="case" />, there is the question of whether some
characters are mapped either to other characters or to nothing
during Stringprep. <xref target="RFC3454" />, Section 3,
outlines a number of characters that are mapped to nothing,
and also permits Stringprep profiles to define their own
mappings.</t>
</section>
<section title="Prohibited characters" anchor="prohibited">
<t>Along with case folding and other character mappings, many
protocols have characters that are simply disallowed. For
example, control characters and special characters such as "@"
or "/" may be prohibited in a protocol.</t>
<t>One of the primary changes of IDNA2008 is in the way it
approaches Unicode code points. IDNA2003 created an explicit
list of excluded or mapped-away characters; anything in
Unicode 3.2 that was not so listed could be assumed to be
allowed under the protocol. IDNA2008 begins instead from the
assumption that code points are disallowed, and then relies on
Unicode properties to derive whether a given code point
actually is allowed in the protocol.</t>
<t>Moreover, there is more than one class of "allowed in the
protocol". While some code points are disallowed outright,
some are allowed only in certain contexts. The reasons for
the context-dependent rules have to do with the way some
characters are used. For instance, the ZERO WIDTH JOINER
and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ, U+200C) are
allowed with contextual rules because they are required in
some circumstances, yet are considered punctuation by
Unicode and would therefore be DISALLOWED under the usual
IDNA2008 derivation rules. The goal is to provide the
widest possible repertoire of code points possible and
consistent with the traditional DNS, trusting to the
operators of individual zones to make sensible (and usually
more restrictive) policies for their zones.</t>
<t>IDNA2008 may be a poor model for what other protocols
ought to do in this case, because it is designed to support
an old protocol that is designed to operate on the scale of
the entire Internet. Moreover, IDNA2008 is intended to be
deployed without any change to the base DNS protocol. Other
protocols may aim at deployment in more local environments,
or may have protocol version negotiation built in.</t>
</section>
<section title="Internal structure, delimiters, and special characters">
<t>IDNA2008 has a special problem with delimiters, because
the delimiter "character" in the DNS wire format is not
really part of the data. In DNS, labels are not separated
exactly; instead, a label carries with it an indicator that
says how long the label is. When the label is presented in
presentation format as part of a fully qualified domain
name, the label separator FULL STOP, U+002E (.) is used to
break up the labels. But because that label separator does
not travel with the wire format of the domain name, there is
no way to encode a different, "internationalized" separator
in IDNA2008.</t>
<t>Other protocols may include characters with similar special
meaning within the protocol. Common characters for these
purposes include FULL STOP, U+002E (.); COMMERCIAL AT, U+0040
(@); HYPHEN-MINUS, U+002D (-); SOLIDUS, U+002F (/); and LOW
LINE, U+005F (_). The mere inclusion of such a character in
the protocol is not enough for it to be considered similar to
another protocol using the same character; instead, handling
of the character must be taken into consideration as well.</t>
<t>An important issue to tackle here is whether it is
valuable to map to or from these special characters as part
of the Stringprep replacement. In some locales, the
analogue to FULL STOP, U+002E is some other character, and
users may expect to be able to substitute their normal stop
for FULL STOP, U+002E. At the same time, there are
predictability arguments in favour of treating names with
FULL STOP, U+002E in them just the way they are treated
under IDNA2008.</t>
</section>
</section>
<section title="Where the data comes from and where it goes">
<section title="User input and the source of protocol elements">
<t>Some protocol elements are provided by users, and others
are not. Those that are not may presumably be subject to
greater restrictions, whereas those that users provide likely
need to permit the broadest range of code points. The
following questions are helpful:</t>
<t><list style="numbers">
<t>Do users input the strings directly?</t>
<t>If so, how? (keyboard, stylus, voice, copy-paste, etc.)</t>
<t>Where do we place the dividing line between user
interface and protocol? (see <xref target="RFC5895" />)</t>
</list></t>
</section>
<section title="User output">
<t>Just as only some protocol elements are expected to be
entered directly by users, only some protocol elements are
intended to be consumed directly by users. It is important
to know how users are expected to be able to consume the
protocol elements, because different environments present
different challenges. An element that is only ever
delivered as part of a vCard remains in machine-readable
format, so the problem of visual confusion is not a great
one. Is the protocol element published as part of a vCard,
a web directory, on a business card, or on "the side of a
bus"? Do users use the protocol element as an identifier
(which means that they might enter it again in some other
context)?</t>
</section>
<section title="Operations">
<t>Some strings are useful as part of the protocol but are
not used as input to other operations (for instance, purely
informative or descriptive text). Other strings are used
directly as input to other operations (such as cryptographic
hash functions), or are used together with other strings to
(such as concatenating a string with some others to form a
unique identifier).</t>
<section title="String classes">
<t>Strings often have a similar function in different
protocols. For instance, many different protocols contain
user identifiers or passwords. A single profile for all
such uses might be desirable.</t>
<t>Often, a string in a protocol is effectively a protocol
element from another protocol. For instance, different
systems might use the same credentials database for
authentication.</t>
</section>
<section title="Community considerations">
<t>A Stringprep replacement that does anything more than
just update Stringprep to the latest version of Unicode
will probably entail some changes. It is important to
identify the willingness of the protocol-using community
to accept backwards-incompatible changes. By the same
token, it is important to evaluate the desire of the
community for features not available under Stringprep.</t>
</section>
<section title="What to do about Unicode changes">
<t>IDNA2008 uses an algorithm to derive the validity of a
Unicode code point for use under IDNA2008. It does this
by using the properties of each code point to test its
validity.</t>
<t>This approach depends crucially on the idea that code
points, once valid for a protocol profile, will not later
be made invalid. That is not a guarantee currently
provided by Unicode. Properties of code points may change
between versions of Unicode. Rarely, such a change could
cause a given code point to become invalid under a
protocol profile, even though the code point would be
valid with an earlier version of Unicode. This is not
merely a theoretical possibility, because it has occurred
(<xref target='I-D.faltstrom-5892bis'/>).</t>
<t>Accordingly, a Stringprep replacement that intends to
be Unicode version agnostic will need to work out a
mechanism to address cases where incompatible changes
occur because of new Unicode versions.</t>
</section>
</section>
<section title="Some useful classes of strings" anchor="stringclass">
<t>With the above considerations in hand, we can usefully
classify strings into the following categories, inspired by
those outlined in <xref target="I-D.saintandre-xmpp-i18n"
/>:</t>
<t>
<list style="hanging">
<t hangText="Domainy strings">Strings that are intended
for use in a domain name slot, as defined in <xref
target="RFC5890" />. Note that domainy strings could be
used outside a domain name slot: the question here is what
the eventual intended use for the string is, and not
whether the string is actually functioning as a domain
name at any moment.</t>
<t hangText="Namey strings">Strings that are intended for
use as identifiers but that are not domainy strings.
Namey strings are normally public data within the protocol
where they are used: these are intended as identifiers
that can be passed around to identify something.</t>
<t hangText="Secretish strings">Strings that are intended
for use as passwords or passphrases or other such type of
token. Secretish strings are normally not public data
within the protocol where they are used: they function as
a token for authorization, and normally should not be
shared publicly.</t>
<t hangText="Protocolish strings">Strings that are
intended to be used by the protocol as free-form strings,
but that have some significant handling within the
protocol. For instance, a protocol slot that allows
free-form text where case is not preserved would need to
have case mapping rules applied; in this case, the string
would be a protocolish string.</t>
<t hangText="String blobs">Elements of the protocol that
look like strings to users, but that are passed around in
the protocol unchanged and that cannot be used for
comparison or other purposes. In effect, these are
strings that are part of a protocol payload, and are not
themselves part of the protocol at all.</t>
</list>
</t>
</section>
</section>
</section>
<section title="Considerations for Stringprep replacement">
<t>The above suggests the following direction for the working group:
<list style="symbols">
<t>A stringprep replacement should be defined.</t>
<t>The replacement should take an approach similar to IDNA2008,
in that it enables Unicode agility.</t>
<t>Protocols share similar characteristics of strings. Therefore,
defining i18n preparation algorithms for a (small) set of string
classes may be sufficient for most cases and provides the
coherence among a set of protocol friends.</t>
<t>The sets of string classes need to be evaluated according
to the considerations that make up the headings in <xref
target="topics" /></t>
<t>It is reasonable to limit scope to Unicode code points, and
rule the mapping of data from other character encodings
outside the scope of this effort.</t>
<t>Recommendations for handling protocol incompatibilities
resulting from changes to Unicode are required.</t>
</list>
</t>
<t>Existing deployments already depend on Stringprep profiles.
Therefore, the working group will need to consider the effects
of any new strategy on existing deployments. By way of
comparison, it is worth noting that some characters were
acceptable in IDNA labels under IDNA2003, but are not
protocol-valid under IDNA2008 (and conversely). Different
implementers may make different decisions about what to do in
such cases; this could have interoperability effects. The
working group will need to trade better support for different
linguistic environments against the potential side effects of
backward incompatibility.</t>
</section>
<section title="Security Considerations">
<t>This document merely states what problems are to be solved,
and does not define a protocol. There are undoubtedly security
implications of the particular results that will come from the
work to be completed.</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Discussion home for this draft">
<t>
This document is intended to define the problem space
discussed on the precis@ietf.org mailing list.
</t>
</section>
<section title="Acknowledgements">
<t>This document is the product of the PRECIS IETF Working
Group, and participants in that Working Group were helpful in
addressing issues with the text.</t>
<t>Specific contributions came from David Black, Alan DeKok,
Bill McQuillan, Alexey Melnikov, Peter Saint-Andre, Dave Thaler,
and Yoshiro Yoneya.</t>
<t>Dave Thaler provided the "buckets" insight in <xref
target="buckets" />, central to the organization of the
problem.</t>
</section>
</middle>
<back>
<references title="Informative References">
&bibxml2rfc-informative;
</references>
<section title="Protocols known to be using Stringprep"
anchor="knowncases">
<t>The known cases are here described in two ways. The types of
identifiers the protocol uses is first called out in the ID type
column (from <xref target="buckets" />), using the short forms
"a" for Absolute, "d" for Definite, and "i" for Indefinite.
Next, there is a column that contains an "i" if the protocol
string comes from user input, an "o" if the protocol string
becomes user-facing output, "b" if both are true, and "n" if
neither is true. The remaining columns have an "x" if and only
if the protocol uses that class, as described in <xref
target="stringclass" />. Values marked "-" indicate that an
answer is not useful; in this case, see detailed discussion in
<xref target = "det_discuss" />.</t>
<texttable anchor="knowncases_table">
<ttcol align="center">RFC</ttcol>
<ttcol align="center">IDtype</ttcol>
<ttcol align="center">User?</ttcol>
<ttcol align="center">Dom'y</ttcol>
<ttcol align="center">Nam'y</ttcol>
<ttcol align="center">Sec'ish</ttcol>
<ttcol align="center">Pro'ish</ttcol>
<ttcol align="center">Blob</ttcol>
<c>3722</c><c>a</c><c>o</c><c></c><c>x</c><c>x</c><c>x</c><c></c>
<c>3748</c><c>-</c><c>-</c><c>-</c><c>x</c><c>-</c><c>-</c><c>-</c>
<c>3920</c><c>a,d</c><c>b</c><c></c><c>x</c><c></c><c>x</c><c></c>
<c>4314</c><c>a,d</c><c>b</c><c></c><c>x</c><c>x</c><c>x</c><c></c>
<c></c><c></c><c></c><c></c><c></c><c></c><c></c><c></c>
</texttable>
<t><cref source="ajs@anvilwalrusden.com">The table still needs to be filled in, I am aware.</cref></t>
</section>
<section title="Detailed discussion of protocols under consideration" anchor="det_discuss">
<t>Below are detailed reviews of the protocols under
consideration (where such reviews are available). <cref
source="ajs@anvilwalrusden.com">These are to be cut and pasted
from the wiki.</cref></t>
</section>
<section title="Changes between versions">
<t>Note to RFC Editor: This section should be removed prior to publication.</t>
<section title="00">
<t>First WG version. Based on
draft-blanchet-precis-problem-statement-00.</t>
</section>
<section title="01">
<t><list style="symbols">
<t>Made clear that the document is talking only about
Unicode code points, and not any particular encoding.</t>
<t>Substantially reorganized the document along the lines of
the review template at <eref
target="http://trac.tools.ietf.org/wg/precis/trac/wiki/StringprepReviewTemplate"
/>.</t>
<t>Included specific questions for each topic for consideration.</t>
<t>Moved spot for individual protocol review to appendix.
Not populated yet.</t>
</list></t>
</section>
<section title="02">
<t><list style="symbols">
<t>Cleared up details of comparison classes</t>
<t>Added a section on changes in Unicode</t>
</list>
</t>
</section>
<section title="03">
<t><list style="symbols">
<t>Aligned comparison discussion with identifier discussion
from draft-iab-identifier-comparison-00</t>
<t>Added section on classes of strings ("Namey" and so
on)</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:16:51 |