One document matched: draft-ietf-precis-mappings-04.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-06.xml">
]>
<?rfc toc="yes"?>
<rfc category="info" docName="draft-ietf-precis-mappings-04" 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. In the
framework, case mapping is defined because many protocols handle
case-sensitive or case-insensitive string comparison and therefore
preparation of the string is mandatory. As described in the mapping
for Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement,
mappings for
internationalized strings are not limited to case, but also width mapping and mapping of
delimiters and other specials 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 Additional 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 in general 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 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"/>, but
delimiter mapping, special mapping, and language dependent mapping are not defined.
Handling of mappings other than case and width is also important to increase chance of
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 here 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 mapping in the PRECIS framework.
</t>
</section>
<!-- NOTE FROM PETER: As I described in my message to the mailing list, I don't think we need the sections "Types of mapping" and "Protocol independent mapping" because width mapping is now described in the framework. Therefore I have included some changes for that, e.g., I commented out the next two sections. You can find my mailing list post at http://www.ietf.org/mail-archive/web/precis/current/msg00436.html -->
<!-- NOTE FROM NEMO: Alright! I changed the sections as following. -->
<!-- TEXT COMMENTED OUT IN XML...
<section title="Types of mapping" anchor="type">
<t>
This document defines two types of mapping. One is protocol independent mapping
that doesn't depend on protocol rules and the other is protocol dependent mapping that depend on protocol rules.
This document defines some mappings in these mapping types.
Authors of protocol profiles of PRECIS framework should need to give careful consideration to choice of mappings.
</t>
<t>
Each mapping type is described in following sections.
</t>
</section>
<section title="Protocol independent mapping" anchor="pim">
<t>
Protocol independent mapping is a mapping that doesn't depend on protocol rules.
</t>
<section title="Width mapping">
<t>
Fullwidth and halfwidth characters (those defined with
Decomposition Types <wide> and <narrow>) are mapped to
their decomposition mappings as shown in the Unicode character
database <xref target="Unicode"/>.
</t>
<t>
Width mapping will increase backward compatibility with Stringprep
<xref target="RFC3454"/> and PRECIS framework
<xref target="I-D.ietf-precis-framework"/>. Because in a
Stringprep profile which specifies Unicode normalization form KC
(NFKC) for normalization method, fullwidth/halfwidth characters
are mapped into its compatible form. If a PRECIS framework
profile specified NFKC (which is not recommended), width mapping
might not be useful.
</t>
</section>
</section>
END OF COMMENTED OUT TEXT -->
<section title="Protocol dependent mappings" anchor="pdm">
<t>
The PRECIS framework defines several protocol-independent mappings.
The additional mappings 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 use in such protocols,
but the delimiters are different for each protocols.
Therefore, the delimiter mapping table should be based on a
well-defined mapping table for each protocol.
</t>
<t>
<!-- NOTE FROM NEMO: I added from -->
<!--
Delimiter mapping is supposed for width compatible characters
that like '@' in mail address and ':' or '/' in URI.
Also Delimiter mapping is supposed for there may be protocols that use '+', '-', '' or '' as delimiters in the future.
For example, the FULL STOP
character (U+002E) is a delimiter in the visual presentation of a domain name. Some
IMEs generate a FULL STOP compatible character such as IDEOGRAPHIC
FULL STOP (U+3002) when a user types FULL STOP on the keyboard. Therefore, such
a character needs to be mapped to the FULL STOP character before passing the
string to the protocol.
-->
Delimiter mapping is supposed to map delimiter characters that have
compatible characters to canonical characters. For example, '@' in mail
address or ':' and '/' in URI has width compatible character. And '+',
'-', '<' and '>' may be such character. Another example is the FULL STOP
character (U+002E) which is a delimiter in the visual presentation of
domain names. Some IMEs generate semantic or width compatible character
of FULL STOP such as IDEOGRAPHIC FULL STOP (U+3002) when a user types FULL
STOP on the keyboard. Such FULL STOP compatible characters need to be mapped
to the FULL STOP before passing the string 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 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 matching-result from the comparison between uppercase and
lowercase characters, targeting locale and locale and context-dependent characters.
</t>
<t>
As an example of
locale and context-dependent mapping, LATIN CAPITAL LETTER I (U+0049) is
normally mapped to LATIN SMALL LETTER I ((U+0069); however, if the
language is Turkish (or one of several other languages), unless an I is before a dot_above, then the
character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
</t>
<!--t>
Local case mapping depends on locale or context. As an example of
locale-dependent mapping, LATIN CAPITAL LETTER I (U+0049) is
normally mapped to LATIN SMALL LETTER I ((U+0069); however, if the
language is Turkish (or one of several other languages), then the
character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
As an example of context-dependent mapping, GREEK CAPITAL LETTER
SIGMA (U+03A3) is mapped to GREEK SMALL LETTER SIGMA (U+03C3) if it
is followed by another letter, but is mapped to GREEK SMALL LETTER
FINAL SIGMA (U+03C2) if it is not followed by another letter.
</t-->
<!--t>
Local case mapping is case folding that depends on language and context.
For example, the mapping of LATIN CAPITAL LETTER I (U+0049) depends on the
language context of the user: if the language is Turkish (or one of several other languages), the character should be mapped into LATIN SMALL
LETTER DOTLESS I (U+0131) as this character's lower case equivalent.
</t-->
<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"/>.
</t>
<!--t>
Local case mapping targets only characters that get two different results to perform just casefolding
that is defined in the Casefolding.txt <xref target="Casefolding"/> and perform special casefolding
that is defined in the SpecialCasing.txt then casefolding, because PRECIS framework have casefolding.
</t>
<t>
There are two types casefoldings defined as Unconditional Mappings and Conditional Mappings in the SpecialCasing.txt file.
Conditional mappings have Language-Insensitive Mappings that target characters whose full case mappings do not depend on language, but do
depend on context. Language-Sensitive Mappings that these are characters whose full case mappings depend on language and perhaps also
context.
</t>
<t>
Of these mappings, characters with Unconditional Mappings or with Language-Insensitive Mappings in Conditional Mappings target are mapped into
same codepoint(s) with just casefolding or special casefolding then casefolding.
But characters with Language-Sensitive Mappings in Conditional Mappings targets are mapped into different codepoints.
Therefore this document defines characters that are a part of characters of Lithuanian(lt), Turkish(tr) and Azerbaijanian(az) that Language-Sensitive Mappings targets
as targets for local case mapping.
</t-->
<t>
The following are the methods to calculate codepoints that local case mapping targets.
Here 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>
<!-- NOTE FROM NEMO: I added a sentence for developers-->
<t>
Local case mapping can be selected only when case mapping is selected using the PRECIS Framework profile.
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 mapping in the PRECIS framework.
Basically, the mappings described in this document describes could be applied in any order.
However, this section specifies a particular order to minimize the effect of codepoint changes introduced by the mappings.
This mapping order is very general and was 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>
Followings are current open issues for this document.
<list style='numbers'>
<t>
Some protocols requires local case mapping as normative of the PRECIS framework.
Is it necessary to define the local case mapping in the framework document?
Issue here is that the local case mapping is for localizaion and the PRECIS
framework is for internationalization. Following to IDNA2008, PRECIS core
protocol should concentrate to internationalization, and localization should
be separated from the core protocol (like 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, 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 initials="" surname="The Unicode Consortium" fullname="">
<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 initials="" surname="" fullname="">
<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 initials="" surname="" fullname="">
<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[
+----------------------+-------------+-----------+------+---------+
| \ Type of mapping | Width | Delimiter | Case | Special |
| RFC \ | (NFKC) | | | |
+----------------------+-------------+-----------+------+---------+
| 3490 | - | o | - | - |
| 3491 | o | - | o | - |
| 3722 | o | - | o | - |
| 3748 | o | - | - | o |
| 4013 | o | - | - | o |
| 4314 | o | - | - | o |
| 4518 | o | - | o | o |
| 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="Code points list for local case mapping" anchor="LCM-list">
<t>
Followings are a list of characters that need Local case mapping.
Format:<vspace />
<Codepoint>; <Lowercase>; <Language> <Condition>; <Comments><vspace />
<Language> means the alpha-2 codes in <xref target="ISO.3166-1"/>.
</t>
<section title="Unicode 6.3">
<t>
<list>
<t>
0049; 0069 0307; lt More_Above; # LATIN CAPITAL LETTER I<vspace />
004A; 006A 0307; lt More_Above; # LATIN CAPITAL LETTER J<vspace />
00CC; 0069 0307 0300; lt; # LATIN CAPITAL LETTER I WITH GRAVE<vspace />
00CD; 0069 0307 0301; lt; # LATIN CAPITAL LETTER I WITH ACUTE<vspace />
0128; 0069 0307 0303; lt; # LATIN CAPITAL LETTER I WITH TILDE<vspace />
012E; 012F 0307; lt More_Above; # LATIN CAPITAL LETTER I WITH OGONEK<vspace />
0307; 0307; lt After_Soft_Dotted; # COMBINING DOT ABOVE<vspace />
0049; 0131; tr Not_Before_Dot; # LATIN CAPITAL LETTER I<vspace />
0130; 0069; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE<vspace />
0307; ; tr After_I; # COMBINING DOT ABOVE<vspace />
0049; 0131; az Not_Before_Dot; # LATIN CAPITAL LETTER I<vspace />
0130; 0069; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE<vspace />
0307; ; az After_I; # COMBINING DOT ABOVE<vspace />
</t>
<!--t>
lt; 0049; 0069 0307; LATIN CAPITAL LETTER I<vspace />
lt; 004A; 006A 0307; LATIN CAPITAL LETTER J<vspace />
lt; 012E; 012F 0307; LATIN CAPITAL LETTER I WITH OGONEK<vspace />
lt; 00CC; 0069 0307 0300; LATIN CAPITAL LETTER I WITH GRAVE<vspace />
lt; 00CD; 0069 0307 0301; LATIN CAPITAL LETTER I WITH ACUTE<vspace />
lt; 0128; 0069 0307 0303; LATIN CAPITAL LETTER I WITH TILDE<vspace />
tr; 0307; ; COMBINING DOT ABOVE #after I<vspace />
tr; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE<vspace />
tr; 0049; 0131; LATIN CAPITAL LETTER I #Not_Before_Dot<vspace />
az; 0307; ; COMBINING DOT ABOVE #after I.<vspace />
az; 0130; 0069; LATIN CAPITAL LETTER I WITH DOT ABOVE<vspace />
az; 0049; 0131; LATIN CAPITAL LETTER I #Not_Before_Dot
</t-->
</list>
</t>
</section>
</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>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:40:06 |