One document matched: draft-ietf-precis-mappings-08.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc5895 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml">
<!ENTITY rfc3454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3454.xml">
<!ENTITY rfc4518 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4518.xml">
<!ENTITY rfc3722 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3722.xml">
<!ENTITY rfc4013 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4013.xml">
<!ENTITY rfc6120 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6122.xml">
<!ENTITY rfc3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc4314 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4314.xml">
<!ENTITY rfc3490 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
<!ENTITY rfc3491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3491.xml">
<!ENTITY rfc6885 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6885.xml">
<!ENTITY I-D.ietf-precis-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-precis-framework-14.xml">
]>
<?rfc toc="yes"?>
<rfc category="info" docName="draft-ietf-precis-mappings-08" ipr="trust200902">
<front>
<title abbrev="precis mapping">Mapping characters for PRECIS classes</title>
<author fullname="Yoshiro YONEYA" initials="Y" surname="YONEYA">
<organization>JPRS</organization>
<address>
<postal>
<street>Chiyoda First Bldg. East 13F</street>
<street>3-8-1 Nishi-Kanda</street>
<city>Chiyoda-ku</city>
<region>Tokyo</region>
<code>101-0065</code>
<country>Japan</country>
</postal>
<phone>+81 3 5215 8451</phone>
<email>yoshiro.yoneya@jprs.co.jp</email>
</address>
</author>
<author fullname="Takahiro Nemoto" initials="T" surname="Nemoto">
<organization>Keio University</organization>
<address>
<postal>
<street>Graduate School of Media Design</street>
<street>4-1-1 Hiyoshi, Kohoku-ku</street>
<city>Yokohama</city>
<region>Kanagawa</region>
<code>223-8526</code>
<country>Japan</country>
</postal>
<phone>+81 45 564 2517</phone>
<email>t.nemo10@kmd.keio.ac.jp</email>
</address>
</author>
<date/>
<!-- NOTE FROM PETER: We don't put actual references (xref...) in the abstract. -->
<!-- Thank you! -->
<abstract>
<t>
The framework for preparation and comparison of internationalized strings ("PRECIS")
<!-- NOTE FROM PETER: I prefer PRECIS in all caps. :-) -->
<!-- NOTE FROM NEMO: I modified them. :) -->
defines
several classes of strings for preparation and comparison.
Case mapping is defined because many protocols perform
case-sensitive or case-insensitive string comparison and so
preparation of the string is mandatory.
The Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement
describes mappings for
internationalized strings that are not limited to case, but include width mapping and mapping of
delimiters and other specials that can be taken into consideration.
This document provides guidelines for authors of protocol profiles of the PRECIS framework
and describes several mappings that can be applied between receiving user input and passing
permitted code points to internationalized protocols.
<!-- The mappings described here are expected to be applied before the rules specified in the PRECIS framework. -->
The mappings described here are expected to be applied as an additional mapping and locale-/context-dependent case mapping.
<!--and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework.-->
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
In many cases, user input of internationalized strings is generated
through the use of an input method editor ("IME") or through copy-and-paste from free text.
Users generally do not care about the case and/or width of input characters because they consider those
characters to be functionally equivalent or visually identical. Furthermore, users rarely
switch the IME state to input special characters such as protocol
elements. For Internationalized Domain Names ("IDNs"), the IDNA Mapping
specification <xref target="RFC5895"/> describes methods for handling these issues.
For PRECIS strings, case mapping and width mapping are defined in the PRECIS
framework specification <xref target="I-D.ietf-precis-framework"/>.
<!--
Delimiter mapping, special mapping, and local case mapping, however, are not defined.
The handling of mappings other than case and width is also important in order to increase the probability that
strings match as users expect.
-->
Further, the handling of mappings other than case and width, such as
delimiter, special, and local case, are also important in order to
increase the probability that strings match as users expect.
<!--This document provides guidelines for authors of protocol profiles of the PRECIS framework
and describes mappings that can be applied
between receiving user input and passing permitted code points to
internationalized protocols.
The mappings described in this document are expected to be applied as additional mapping and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework.-->
This document
provides guidelines for authors of protocol profiles of the PRECIS
framework and describes several mappings that can be applied between
receiving user input and passing permitted code points to
internationalized protocols. The delimiter mapping and special mapping
rules described here are applied as "additional mappings" beyond those
defined in the PRECIS framework, <!--whereas the "local case mapping" rule
is applied as an option of methods that handles some locale-dependent
and context-dependent mappings, which is the case mapping rule
specified in the PRECIS framework.-->
whereas the "local case mapping" rule
provides an alternative to the case mapping rule
specified in the PRECIS framework since it
handles some locale-dependent and context-dependent
mappings.
</t>
</section>
<section title="Protocol dependent mappings" anchor="pdm">
<t>
The PRECIS framework defines several protocol-independent mappings.
The <!--Two--> additional mappings and local case mapping<!--and one alternative mapping--> defined in this document are protocol-dependent,
i.e., they depend on the rules for a particular application protocol.
</t>
<section title="Delimiter mapping">
<t>
Some application protocols define delimiters for their own use,
resulting in the fact that the delimiters are different for each protocol.
The delimiter mapping table should therefore be based on a well-defined
mapping table for each protocol.
</t>
<t>
Delimiter mapping is used to map characters that are similar to
protocol delimiters into the canonical delimiter characters. For
example, there are width-compatible characters that correspond to the
'@' in email addresses and the ':' and '/' in URIs. The '+', '-', '<' and '>'
characters are other common delimiters that might require
such mapping. For the FULL STOP character (U+002E), a delimiter in
the visual presentation of domain names, some IMEs produce a character
such as IDEOGRAPHIC FULL STOP (U+3002) when a user types FULL STOP on
the keyboard. In all these cases, the visually similar characters
that can come from user input need to be mapped to the correct protocol
delimiter characters before the string is passed to the protocol.
</t>
</section>
<section title="Special mapping" anchor="spm">
<t>
Aside from delimiter characters, certain protocols have characters which need to be mapped in ways that are different from the rules specified in the PRECIS framework (e.g., mapping non-ASCII space characters to ASCII space).
In this document, these mappings are called "special mappings". They are different for each protocol.
Therefore, the special mapping table should be based on a well-defined mapping table for each protocol.
Examples of special mapping are the following;
<list style='symbols'>
<t>White spaces are mapped to SPACE (U+0020)</t>
<t>Some characters such as control characters are mapped to nothing (Deletion)</t>
</list>
As examples, EAP <xref target="RFC3748"/>, SASLprep <xref target="RFC4013"/>, IMAP4 ACL <xref target="RFC4314"/> and LDAPprep <xref target="RFC4518"/>
define the rule that some codepoints for the non-ASCII space are mapped to SPACE (U+0020).
</t>
</section>
<section title="Local case mapping" anchor="lcm">
<t>
The purpose of local case mapping is to increase the probability
of a matching result from the comparison between uppercase and
lowercase characters, targeting characters which mapping depends on locale or locale and context.
</t>
<!-- ayashii point start-->
<t>
As an example of
locale and context-dependent mapping, LATIN CAPITAL LETTER I ("I", U+0049) is
normally mapped to LATIN SMALL LETTER I ("i", U+0069); however, if the case of
Turkish (or one of several other languages), unless an I is before a dot_above, the
character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
</t>
<!-- ayashii point start-->
<t>
<!--
To solve such problems for PRECIS framework,
this document defines characters that need local case mapping based on
the SpecialCasing.txt <xref target="Specialcasing"/> file in section 3.13
of the Unicode Standard <xref target="Unicode"/>.
This document defines the target characters of local case mapping as characters that are described in the SpecialCasing.txt.
-->
Case mapping using Unicode Default Case Folding in PRECIS framework does not consider such locale or
context because it is a common framework for internationalization.
Local case mapping defined in this document corresponds to demands
from applications which supports users' locale and/or context.
The target characters of local case mapping are characters defined
in the SpecialCasing.txt <xref target="Specialcasing"/> file in section 3.13 of the
Unicode Standard <xref target="Unicode"/>.
</t>
<!--t>
The following are the methods to calculate codepoints that local case mapping targets.
Here cp means an Unicode codepoint, Casefolding() means full casefolding described in the CaseFolding.txt file <xref target="Casefolding"/>,
and Specialcasing() means specialcasing described in the SpecialCasing.txt file <xref target="Specialcasing"/>.
</t>
<t>
If Casefolding(Specialcasing(cp)) != Casefolding(cp)<vspace/>
Then cp is a target<vspace/>
Else cp is not a target;<vspace/>
</t-->
<t>
<!--If a codepoint is a target, it is necessary to perform the specialcasing described in the SpecialCasing.txt file.>
If a codepoint is a target, the case folding method for the codepoint is mapping into lower case SpecialCasing.txt defines.
<On the other hand, if a codepoint is not a target, it is necessary to perform the full casefolding described in the CaseFolding.txt file.>
On the other hand, if a codepoint is not a target, the case folding method for the codepoint is Default Case Folding unicode defines in chapter 3 (Show the section 4.3 of the framework document).
This is a <an alternative to the full casefolding inside the framework, Therefore the full casefolding should be not performed.>
local case mapping provides alternative case folding method to Case mapping in the PRECIS framework, therefore if a PRECIS profile choose the Local case mapping it should not choose the Case mapping.-->
<!--If a codepoint is a target, the case folding method for the codepoint is mapping into lower case as defined in SpecialCasing.txt.
On the other hand, if a codepoint is not a target, the case folding method for the codepoint is the same with case mapping in PRECIS framework--><!--Default Case Folding as defined in chapter 3 (Show the section 4.3 of the framework document).-->
<!--This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping.
The reason for this is written in the <xref target="vs"/>.-->
The case folding method for a target character is to map into lower case
as defined in SpecialCasing.txt. The case folding method for all other,
non-target characters is as specified in Section 4.1.3 of the PRECIS
framework (i.e., It is RECOMMENDED to use Unicode Default Case Folding for all
non-target characters). If an application supports users' locale and/or
context <!--and gets them information from user input,-->, local case mapping
can increase the probability of getting matching-results from the comparison
between strings.
</t>
<t>
If Unicode Default Case Folding is selected as "Case Mapping" in PRECIS profiles registry,
PRECIS profile designers may consider whether local case mapping can be applied.
And if it can be applied, it is better to add "local case mapping is applicable alternatively"
after "Unicode Default Case Folding" for note to application developers.
The reason why local case mapping is alternative to Unicode Default Case Folding is written in the <xref target="vs"/>.
<!--
For non-target characters, full case mapping in the local case mapping must be performed instead.
The profile that selects local case mapping must not select non-local case mapping in the framework.
Local case mapping can be selected only when case mapping is selected using the PRECIS framework profile.
-->
</t>
<!--t>
Application developers should calculate codepoints that local case mapping targets by using the latest Casefolding.txt and SpecialCasing.txt.
<xref target="LCM-list"/> "Code points list for local case mapping" lists codepoints in Unicode 6.3 calculated by this method.
</t-->
</section>
</section>
<!-- ******************************************************************************* -->
<!-- NOTE FROM NEMO: Thanks to modify the section title from "Applying order of mapping" to "Order of operations". -->
<section title="Order of operations" anchor="aom">
<t>
<!--The mappings described in this document are expected to be applied before the rules specified in the PRECIS framework.-->
<!--The mappings described in this document are expected to be applied as additional mappings and alternative to Unicode Default Case Folding as case mapping in the PRECIS framework.
The mappings described in this document--> <!--describes--> <!--could be applied in any order.
This section specifies a particular order to minimize the effect of codepoint changes introduced by the mappings.
This mapping order is very general and has been designed to be acceptable to the widest user community.-->
Delimiter mapping and special mapping described in this document are expected to be applied as
additional mappings in the PRECIS framework. The mappings described in
this document could be applied in any order. This section specifies
a particular order to minimize the effect of codepoint changes
introduced by the mappings. This mapping order is very general and
has been designed to be acceptable to the widest user community.
<list style='numbers'>
<!--<t>Width mapping</t>-->
<t>Delimiter mapping</t>
<t>Special mapping</t>
<!--<t>Local case mapping</t>-->
<!--<t>Non-local case mapping</t>-->
<!--<t>Normalization</t-->
<!--<t>PRECIS protocol</t-->
</list>
</t>
</section>
<!-- ******************************************************************************* -->
<!-- NOTE FROM PETER: I think the following issues are now closed. -->
<!-- NOTE FROM NEMO: Yoneya-san and I think too. So I remove the section "Open Issues"-->
<!-- NOTE FROM NEMO: I removed "Open Issues" for ver.03. -->
<!-- TEXT COMMENTED OUT IN XML... -->
<!-- -->
<!--section title="Open issues" anchor="oi">
<t>
This verstion(-06) changed the definition of local case mapping.
There were comments in IETF88 stating that there are cases in which GREEK SMALL LETTER FINAL SIGMA (U+03C2)
(hereinafter referred to as "final sigma") and LATIN SMALL LETTER SHARP S (U+00DF) (hereinafter referred to as "eszett")
are mapped into characters that are not intended by the users, and this is undesirable.
Until the last version(-05), selecting local case mapping followed by case mapping in the PRECIS framework was allowed.
Taking the above mentioned comments into consideration, this version(-06) defines local case mapping as alternative to case mapping in the PRECIS framework.
For this reason, eszett is no longer mapped to another characters. But this is inapplicable to final sigma
as the context dependent mapping does not exist in the table and definition of the SpecialCasing.txt.
(Followings are comments in SpecialCasing.txt.)
<list>
<t>
# Note: the following cases are not included, since they would case-fold in lowercasing<vspace />
# 03C3; 03C2; 03A3; 03A3; Final_Sigma; # GREEK SMALL LETTER SIGMA<vspace />
# 03C2; 03C3; 03A3; 03A3; Not_Final_Sigma; # GREEK SMALL LETTER
</t>
</list>
We have come up with 2 ways to solve this issue.
However, the decision of which of them should be taken is an open issue.
<list style='numbers'>
<t>
Define extra mapping table inside this document.
</t>
<t>
Leave the solution for final sigma issue to Unicode's definition, and mark this issue as "not supported" in the appendix section of this document.
</t>
</list>
</t>
</section-->
<!-- -->
<!-- END OF COMMENTED OUT TEXT -->
<section title="Security Considerations" anchor="sec">
<t>
As well as Mapping Characters for IDNA2008 <xref target="RFC5895"/>, this document suggests creating mappings that might cause confusion for some users while alleviating confusion in other users.
Such confusion is not covered in any depth in this document.
</t>
</section>
<!-- NOTE FROM PETER: IANA Considerations go after Security Considerations. -->
<!-- NOTE FROM NEMO: Thanks! -->
<section title="IANA Considerations" anchor="iana">
<t>
This document has no actions for the IANA.
</t>
</section>
<section title="Acknowledgment" anchor="ack">
<t>
Martin Dürst suggested a need for the case folding about the mapping (map final sigma to sigma, German sz to ss,.).
</t>
<t>
Alexey Melnikov, Andrew Sullivan, Barry Leiba, Heather Flanagan, Joe Hildebrand, John Klensin, Marc Blanchet, Pete Resnick and Peter Saint-Andre, et al. gave important suggestion for this document during at WG meeting and WG LC.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-precis-framework;
<reference anchor="Unicode">
<front>
<title>The Unicode Standard, Version 6.3.0</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="" value="<http://www.unicode.org/versions/Unicode6.3.0/>"/>
</reference>
<reference anchor="Casefolding">
<front>
<title>CaseFolding-6.3.0.txt</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year=""/>
</front>
<seriesInfo name="Unicode Character Database, July 2011," value="<http://www.unicode.org/Public/6.3.0/ucd/CaseFolding.txt>"/>
</reference>
<reference anchor="Specialcasing">
<front>
<title>SpecialCasing-6.3.0.txt</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year=""/>
</front>
<seriesInfo name="Unicode Character Database, July 2011," value="<http://www.unicode.org/Public/6.3.0/ucd/SpecialCasing.txt>"/>
</reference>
</references>
<references title="Informative References">
&rfc3454;
&rfc3490;
&rfc3491;
&rfc3722;
&rfc3748;
&rfc4013;
&rfc4314;
&rfc4518;
&rfc5895;
&rfc6120;
&rfc6885;
<reference anchor="ISO.3166-1">
<front>
<title>Codes for the representation of names of countries and their subdivisions - Part 1: Country codes</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date year="1997" />
</front>
<seriesInfo name="ISO Standard 3166-" value="1:1997"/>
</reference>
</references>
<!-- NOTE FROM PETER: see my post to the mailing list about the appendices. You can find my mailing list post at http://www.ietf.org/mail-archive/web/precis/current/msg00436.html -->
<section title="Mapping type list each protocol" anchor="maplist">
<section title="Mapping type list for each protocol" anchor="maptype">
<t>
This table is the mapping type list for each protocol.
Values marked "o" indicate that the protocol use the type of mapping.
Values marked "-" indicate that the protocol doesn't use the type of mapping.
</t>
<figure>
<artwork><![CDATA[
+----------------------+-------------+-----------+------+---------+
| Protocol and | Width | Delimiter | Case | Special |
| mapping RFC | (NFKC) | | | |
+----------------------+-------------+-----------+------+---------+
| IDNA (RFC 3490) | - | o | - | - |
| IDNA (RFC 3491) | o | - | o | - |
| iSCSI (RFC 3722) | o | - | o | - |
| EAP (RFC 3748) | o | - | - | o |
| SASL (RFC 4013) | o | - | - | o |
| IMAP (RFC 4314) | o | - | - | o |
| LDAP (RFC 4518) | o | - | o | o |
| XMPP (RFC 6120) | - | - | o | - |
+----------------------+-------------+-----------+------+---------+
]]></artwork>
</figure>
</section>
</section>
<!-- TEXT COMMENTED OUT IN XML...
<section title="Codepoints which need special mapping" anchor="list_sp">
<section title="RFC3748" anchor="cplist3748">
<t>
Non-ASCII space characters [StringPrep, C.1.2] that can be mapped to SPACE (U+0020).
</t>
</section>
<section title="RFC4013" anchor="cplist4013">
<t>
Non-ASCII space characters [StringPrep, C.1.2] that can be mapped to SPACE (U+0020).
</t>
</section>
<section title="RFC4314" anchor="cplist4314">
<t>
Non-ASCII space characters [StringPrep, C.1.2] that can be mapped to SPACE (U+0020).
</t>
</section>
<section title="RFC4518" anchor="cplist4518">
<t>
Codepoints mapped to SPACE (U+0020) are following;
</t>
<t>
U+0009 (CHARACTER TABULATION)<vspace />
U+000A (LINE FEED (LF))<vspace />
U+000B (LINE TABULATION)<vspace />
U+000C (FORM FEED (FF))<vspace />
U+000D (CARRIAGE RETURN (CR))<vspace />
U+0085 (NEXT LINE (NEL))<vspace />
U+0020 (SPACE)<vspace />
U+00A0 (NO-BREAK SPACE)<vspace />
U+1680 (OGHAM SPACE MARK)<vspace />
U+2000 (EN QUAD)<vspace />
U+2001 (EM QUAD)<vspace />
U+2002 (EN SPACE)<vspace />
U+2003 (EM SPACE)<vspace />
U+2004 (THREE-PER-EM SPACE)<vspace />
U+2005 (FOUR-PER-EM SPACE)<vspace />
U+2006 (SIX-PER-EM SPACE)<vspace />
U+2007 (FIGURE SPACE)<vspace />
U+2008 (PUNCTUATION SPACE)<vspace />
U+2009 (THIN SPACE)<vspace />
U+200A (HAIR SPACE)<vspace />
U+2028 (Line Separator)<vspace />
U+2029 (Paragraph Separator)<vspace />
U+202F (NARROW NO-BREAK SPACE)<vspace />
U+205F (MEDIUM MATHEMATICAL SPACE)<vspace />
U+3000 (IDEOGRAPHIC SPACE)<vspace />
</t>
<t>
All other control code (e.g., Cc) points or code points with a
control function (e.g., Cf) are mapped to nothing.
Codepoints mapped to nothing that aren't specified by Stringprep are following;
</t>
<t>
U+0000-0008<vspace />
U+000E-001F<vspace />
U+007F-0084<vspace />
U+0086-009F<vspace />
U+06DD<vspace />
U+070F<vspace />
U+180E<vspace />
U+200E-200F<vspace />
U+202A-202E<vspace />
U+2061-2063<vspace />
U+206A-206F<vspace />
U+FFF9-FFFB<vspace />
U+1D173-1D17A<vspace />
U+E0001<vspace />
U+E0020-E007F<vspace />
</t>
</section>
</section>
END OF COMMENTED OUT TEXT -->
<section title="The reason why local case mapping is alternative to case mapping in PRECIS framework" anchor="vs">
<t>
One outstanding issue regarding full case folding for characters is, the
character "LATIN SMALL LETTER SHARP S" (U+00DF) (hereinafter referred to as "eszett") becomes two "LATIN SMALL
LETTER S"s (U+0073 U+0073) by performing the case mapping using Unicode Default Case Folding in the
PRECIS framework. If local case mapping in this document is not an alternative to case mapping in PRECIS framework,
PRECIS profile designers can select both mappings, therefore, German's eszett can not keep the locale
if the case mapping in the PRECIS framework was performed after the local case mapping.
</t>
</section>
<section title="Limitation to local case mapping" anchor="sigma">
<t>
As described in section <xref target="lcm"/>, target characters of local case mapping are characters defined in SpecialCasing.txt.
The Unicode Standard (at least, up to version 6.3.0) does not define mappings between "GREEK SMALL LETTER SIGMA" (U+03C3)
(hereinafter referred to as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) (hereinafter referred to as "final sigma") depend on context.
Thus, final sigma is always mapped to small sigma by local case mapping.
(Cf. Followings are comments in SpecialCasing.txt.)
<list>
<t>
# Note: the following cases are not included, since they would case-fold in lowercasing<vspace />
# 03C3; 03C2; 03A3; 03A3; Final_Sigma; # GREEK SMALL LETTER SIGMA<vspace />
# 03C2; 03C3; 03A3; 03A3; Not_Final_Sigma; # GREEK SMALL LETTER
</t>
</list>
Local case mapping follows Unicode definition, so mapping of small sigma and final sigma is up to the definition.
</t>
</section>
<section title="Change Log" anchor="changes">
<section title="Changes since -00">
<t>
<list style="symbols">
<t>
Modify the Section 4.3 "Local case mapping" to specify the method to calculate codepoints that local case mapping targets.
</t>
<t>
Add the Section 6 "Open issues".
</t>
<t>
Modify the Section 7 "IANA Considerations".
</t>
<t>
Modify the Section 8 "Security Considerations".
</t>
<t>
Remove the "The initial PRECIS local case mapping registrations".
</t>
<t>
Add the Appendix C "Code points list for local case mapping".
</t>
<t>
Add the Appendix D "Change Log".
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.02. -->
<section title="Changes since -01">
<t>
<list style="symbols">
<t>
Unified PRECIS notation in all capital letters as well as other documents.
</t>
<t>
Removed the Section 1 "Types of mapping" and the Section 2 "Protocol independent mapping" because width mapping is now in framework document.
</t>
<t>
Added relationship between the framework document and this document in the Section 3 "Order of operations".
</t>
<t>
Updated the Section 4 "Open issues" to address new issue raised on mailing list.
</t>
<t>
Move the Section 6 "IANA Considerations" after the Section 5 "Security Considerations".
</t>
<t>
Remove the Appendix B "Codepoints which need special mapping" and mentioned related documents in the Section 2.2 .
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.03. -->
<section title="Changes since -02">
<t>
<list style="symbols">
<t>
Removed the "Open issues".
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.04. -->
<section title="Changes since -03">
<t>
<list style="symbols">
<t>
Modify the Section 1 "Introduction" in more clear text.
</t>
<t>
Modify the Section 2.3 "Local case mapping" to clarify the purpose of the local case mapping and an example, and add restriction to use with PRECIS framework.
</t>
<t>
Change the format in the Appendix B "Code points list for local case mapping".
</t>
<t>
Split the Section 7 "References" into "Normative References" and "Informative References"
</t>
<t>
Update the Unicode version 6.2 to 6.3 in this document.
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.05. -->
<section title="Changes since -04">
<t>
<list style="symbols">
<t>
Correct a sentence in the Section 2.3 "Local case mapping".
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.06. -->
<section title="Changes since -05">
<t>
<list style="symbols">
<t>
Correct some sentences in this document.
</t>
<t>
Modify the local case mapping's rule and target characters in Section 2.3 "Local case mapping".
This is to avoid user's confusion towards Greek's final sigma and German's eszett.
</t>
<t>
Add the Section 4 "Open issues".
</t>
<t>
Modify the Section 8 "Security Considerations".
</t>
<t>
Modify the table format in the Appendix A. "Mapping type list each protocol".
</t>
<t>
Removed the Appendix B "Code points list for local case mapping".
</t>
<t>
Add the Appendix B "Local case mapping vs Case mapping".
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.07. -->
<section title="Changes since -06">
<t>
<list style="symbols">
<t>
Removed the Section 4 "Open issues".
</t>
<t>
Change the title of the Appendix B "Local case mapping vs Case mapping" to "The reason why local case mapping is alternative to case mapping in PRECIS framework".
</t>
<t>
Add the Appendix C "Limitation to local case mapping".
</t>
</list>
</t>
</section>
<!-- NOTE FROM NEMO: I added the "Changes" for ver.08. -->
<section title="Changes since -07">
<t>
<list style="symbols">
<t>
Modify the Section 1 "Introduction".
</t>
<t>
Modify the local case mapping's rule and target characters in Section 2.3 "Local case mapping".
</t>
<t>
Modify the Section 3 "Order of operations".
</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:37:59 |