idnits 2.17.1 draft-ietf-precis-mappings-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2015) is 3096 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-precis-framework' is mentioned on line 546, but not defined == Unused Reference: 'Casefolding' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC3454' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC3722' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC6122' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC6885' is defined on line 334, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7564 (Obsoleted by RFC 8264) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 6122 (Obsoleted by RFC 7622) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. YONEYA 3 Internet-Draft JPRS 4 Intended status: Informational T. Nemoto 5 Expires: May 4, 2016 Keio University 6 November 1, 2015 8 Mapping characters for PRECIS classes 9 draft-ietf-precis-mappings-12 11 Abstract 13 The framework for preparation, enforcement, and comparison of 14 internationalized strings ("PRECIS") defines several classes of 15 strings for use in application protocols. Because many protocols 16 perform case-sensitive or case-insensitive string comparison, it 17 necessary to define methods for case mapping. In addition, both the 18 Internationalized Domain Names in Applications (IDNA) and the PRECIS 19 problem statement describe mappings for internationalized strings 20 that are not limited to case, but include width mapping and mapping 21 of delimiters and other special characters that can be taken into 22 consideration. This document provides guidelines for designers of 23 PRECIS profiles and describes several mappings that can be applied 24 between receiving user input and passing permitted code points to 25 internationalized protocols. In particular, this document describes 26 both locale-dependent and context-depending case mappings as well as 27 additional mappings for delimiters and special characters. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 4, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Protocol dependent mappings . . . . . . . . . . . . . . . . . 3 65 2.1. Delimiter mapping . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Special mapping . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Local case mapping . . . . . . . . . . . . . . . . . . . 4 68 3. Order of operations . . . . . . . . . . . . . . . . . . . . . 5 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Appendix A. Mapping type list each protocol . . . . . . . . . . 8 76 A.1. Mapping type list for each protocol . . . . . . . . . . . 8 77 Appendix B. The reason why local case mapping is alternative to 78 case mapping in PRECIS framework . . . . . . . . . . 8 79 Appendix C. Limitation to local case mapping . . . . . . . . . . 9 80 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 9 81 D.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 9 82 D.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 9 83 D.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 10 84 D.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 10 85 D.5. Changes since -04 . . . . . . . . . . . . . . . . . . . . 10 86 D.6. Changes since -05 . . . . . . . . . . . . . . . . . . . . 10 87 D.7. Changes since -06 . . . . . . . . . . . . . . . . . . . . 11 88 D.8. Changes since -07 . . . . . . . . . . . . . . . . . . . . 11 89 D.9. Changes since -08 . . . . . . . . . . . . . . . . . . . . 11 90 D.10. Changes since -09 . . . . . . . . . . . . . . . . . . . . 11 91 D.11. Changes since -10 . . . . . . . . . . . . . . . . . . . . 12 92 D.12. Changes since -11 . . . . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 In many cases, user input of internationalized strings is generated 98 through the use of an input method editor ("IME") or through copy- 99 and-paste from free text. Users generally do not care about the case 100 and/or width of input characters because they consider those 101 characters to be functionally equivalent or visually identical. 102 Furthermore, users rarely switch the IME state to input special 103 characters such as protocol elements. For Internationalized Domain 104 Names ("IDNs"), the IDNA Mapping specification [RFC5895] describes 105 methods for handling these issues. For PRECIS strings, case mapping 106 and width mapping are defined in the PRECIS framework specification 107 [RFC7564]. The case and width mappings defined in the PRECIS 108 framework do not handle other mappings such as delimiter characters, 109 special characters, and locale-dependent or context-dependent case; 110 these mappings are also important in order to increase the 111 probability that the resulting strings compare as users expect. This 112 document provides guidelines for authors of protocol profiles of the 113 PRECIS framework and describes several mappings that can be applied 114 between receiving user input and passing permitted code points to 115 internationalized protocols. The delimiter mapping and special 116 mapping rules described here are applied as "additional mappings" 117 beyond those defined in the PRECIS framework, whereas the "local case 118 mapping" rule provides locale-dependent and context-dependent 119 alternative case mappings for specific target characters. 121 2. Protocol dependent mappings 123 The PRECIS framework defines several protocol-independent mappings. 124 The additional mappings and local case mapping defined in this 125 document are protocol-dependent, i.e., they depend on the rules for a 126 particular application protocol. 128 2.1. Delimiter mapping 130 Some application protocols define delimiters for their own use, 131 resulting in the fact that the delimiters are different for each 132 protocol. The delimiter mapping table should therefore be based on a 133 well-defined mapping table for each protocol. 135 Delimiter mapping is used to map characters that are similar to 136 protocol delimiters into the canonical delimiter characters. For 137 example, there are width-compatible characters that correspond to the 138 '@' in email addresses and the ':' and '/' in URIs. The '+', '-', 139 '<' and '>' characters are other common delimiters that might require 140 such mapping. For the FULL STOP character (U+002E), a delimiter in 141 the visual presentation of domain names, some IMEs produce a 142 character such as IDEOGRAPHIC FULL STOP (U+3002) when a user types 143 FULL STOP on the keyboard. In all these cases, the visually similar 144 characters that can come from user input need to be mapped to the 145 correct protocol delimiter characters before the string is passed to 146 the protocol. 148 2.2. Special mapping 150 Aside from delimiter characters, certain protocols have characters 151 which need to be mapped in ways that are different from the rules 152 specified in the PRECIS framework (e.g., mapping non-ASCII space 153 characters to ASCII space). In this document, these mappings are 154 called "special mappings". They are different for each protocol. 155 Therefore, the special mapping table should be based on a well- 156 defined mapping table for each protocol. Examples of special mapping 157 are the following; 159 o White spaces such as CHARACTER TABULATION(U+0009) or IDEOGRAPHIC 160 SPACE(U+3000) are mapped to SPACE (U+0020) 162 o Some characters such as control characters are mapped to nothing 163 (Deletion) 165 As examples, EAP [RFC3748], SASLprep [RFC4013], IMAP4 ACL [RFC4314] 166 and LDAPprep [RFC4518] define the rule that some codepoints for the 167 non-ASCII space are mapped to SPACE (U+0020). 169 2.3. Local case mapping 171 The purpose of local case mapping is to increase the probability of 172 results that users expect when character case is changed (e.g., map 173 uppercase to lowercase) between input and use in a protocol. Local 174 case mapping selectively affects characters whose case mapping 175 depends on locale and/or context. 176 (Note: The term "locale" in this document practically means 177 "language" or "language and region" because the locale based on that 178 language configuration of applications on POSIX is selected by 179 "locale" information and referred "Note" in section 2.1.1 of BCP 47 180 [RFC5646].) 182 As an example of locale and context-dependent mapping, LATIN CAPITAL 183 LETTER I ("I", U+0049) is normally mapped to LATIN SMALL LETTER I 184 ("i", U+0069); however, if the language is Turkish (or one of several 185 other languages), unless an I is before a dot_above, the character 186 should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131). 188 Case mapping using Unicode Default Case Folding in the PRECIS 189 framework does not consider such locale or context because it is a 190 common framework for internationalization. Local case mapping 191 defined in this document corresponds to demands from applications 192 which supports users' locale and/or context. The complete set of 193 possible target characters for local case mapping are the characters 194 specified in the SpecialCasing.txt [Specialcasing] file in the 195 Section 3.13 of the Unicode Standard [Unicode], but the specific set 196 of target characters selected for local case mapping depends on 197 locale and/or context, as further explained in the SpecialCasing.txt 198 file. 200 The case folding method for a selected target character is to map 201 into lower case as defined in SpecialCasing.txt. The case folding 202 method for all other, non-target characters is as specified in the 203 Section 5.2.3 of the PRECIS framework . When an application supports 204 users' locale and/or context, use of local case mapping can increase 205 the probability that string comparisons yield the results that users 206 expect. 208 If a PRECIS profile selects Unicode Default Case Folding as the 209 preferred method of case mapping, the profile designers may consider 210 whether local case mapping can be applied. And if it can be applied, 211 it is better to add "alternatively, local case mapping might be 212 applicable" after "Unicode Default Case Folding" so that application 213 developers are aware of the alternative. See the Appendix B for a 214 description of why local case mapping can be an alternative. 216 3. Order of operations 218 Delimiter mapping and special mapping as described in this document 219 are expected to be applied as the "Additional Mapping Rule" mentioned 220 in the Section 5.2.2 of the PRECIS framework. Although the delimited 221 mapping and special mapping could be applied in either order, this 222 document recommends the following order to minimize the effect of 223 code point changes introduced by the mappings and to be acceptable to 224 the widest user community: 226 1. Delimiter mapping 228 2. Special mapping 230 4. Security Considerations 232 Detailed security considerations for PRECIS strings are discussed in 233 the PRECIS framework specification [RFC7564]. This document inherits 234 the considerations as well. 236 As with Mapping Characters for IDNA2008 [RFC5895], this document 237 suggests creating mappings that might cause confusion for some users 238 while alleviating confusion in other users. Such confusion is not 239 covered in any depth in this document. 241 5. IANA Considerations 243 This document has no actions for the IANA. 245 6. Acknowledgment 247 Martin Duerst suggested a need for the case folding about the mapping 248 (map final sigma to sigma, German sz to ss,.). 250 Alexey Melnikov, Andrew Sullivan, Barry Leiba, David Black, Heather 251 Flanagan, Joe Hildebrand, John Klensin, Marc Blanchet, Pete Resnick 252 and Peter Saint-Andre, et al. gave important suggestion for this 253 document during working group discussions. 255 7. References 257 7.1. Normative References 259 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 260 Preparation, Enforcement, and Comparison of 261 Internationalized Strings in Application Protocols", 262 RFC 7564, DOI 10.17487/RFC7564, May 2015, 263 . 265 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 266 7.0.0", , 267 2012. 269 [Casefolding] 270 The Unicode Consortium, "CaseFolding-7.0.0.txt", Unicode 271 Character Database, July 2011, 272 . 274 [Specialcasing] 275 The Unicode Consortium, "SpecialCasing-7.0.0.txt", Unicode 276 Character Database, July 2011, 277 . 280 7.2. Informative References 282 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 283 Internationalized Strings ("stringprep")", RFC 3454, 284 DOI 10.17487/RFC3454, December 2002, 285 . 287 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 288 "Internationalizing Domain Names in Applications (IDNA)", 289 RFC 3490, DOI 10.17487/RFC3490, March 2003, 290 . 292 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 293 Profile for Internationalized Domain Names (IDN)", 294 RFC 3491, DOI 10.17487/RFC3491, March 2003, 295 . 297 [RFC3722] Bakke, M., "String Profile for Internet Small Computer 298 Systems Interface (iSCSI) Names", RFC 3722, 299 DOI 10.17487/RFC3722, April 2004, 300 . 302 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 303 Levkowetz, Ed., "Extensible Authentication Protocol 304 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 305 . 307 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 308 and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 309 2005, . 311 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 312 RFC 4314, DOI 10.17487/RFC4314, December 2005, 313 . 315 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 316 (LDAP): Internationalized String Preparation", RFC 4518, 317 DOI 10.17487/RFC4518, June 2006, 318 . 320 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 321 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 322 September 2009, . 324 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 325 Internationalized Domain Names in Applications (IDNA) 326 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 327 . 329 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 330 Protocol (XMPP): Address Format", RFC 6122, 331 DOI 10.17487/RFC6122, March 2011, 332 . 334 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 335 Problem Statement for the Preparation and Comparison of 336 Internationalized Strings (PRECIS)", RFC 6885, 337 DOI 10.17487/RFC6885, March 2013, 338 . 340 [ISO.3166-1] 341 International Organization for Standardization, "Codes for 342 the representation of names of countries and their 343 subdivisions - Part 1: Country codes", ISO Standard 344 3166- 1:1997, 1997. 346 Appendix A. Mapping type list each protocol 348 A.1. Mapping type list for each protocol 350 This table is the mapping type list for each protocol. Values marked 351 "o" indicate that the protocol use the type of mapping. Values 352 marked "-" indicate that the protocol doesn't use the type of 353 mapping. 355 +----------------------+-------------+-----------+------+---------+ 356 | Protocol and | Width | Delimiter | Case | Special | 357 | mapping RFC | (NFKC) | | | | 358 +----------------------+-------------+-----------+------+---------+ 359 | IDNA (RFC 3490) | - | o | - | - | 360 | IDNA (RFC 3491) | o | - | o | - | 361 | iSCSI (RFC 3722) | o | - | o | - | 362 | EAP (RFC 3748) | o | - | - | o | 363 | IMAP (RFC 4314) | o | - | - | o | 364 | LDAP (RFC 4518) | o | - | o | o | 365 +----------------------+-------------+-----------+------+---------+ 367 Appendix B. The reason why local case mapping is alternative to case 368 mapping in PRECIS framework 370 Local case mapping is alternative to Unicode Default Case Folding 371 instead of being applied sequentially. Because, one outstanding 372 issue regarding full case folding for characters is, some lowercase 373 characters like "LATIN SMALL LETTER SHARP S" (U+00DF) (hereinafter 374 referred to as "eszett") and ligatures like "LATIN SMALL LIGATURE FF" 375 (U+FB00) that described in section Unconditional mappings of 376 SpecialCasing.txt become a different codepoint by performing the case 377 mapping using Unicode Default Case Folding in the PRECIS framework. 378 In particular, German's eszett can not keep the locale because eszett 379 becomes two "LATIN SMALL LETTER S"s (U+0073 U+0073) by performing the 380 case mapping using Unicode Default Case Folding. On the other hand, 381 eszett doesn't become a different codepoint by performing the case 382 mapping in SpecialCasing.txt. Therefore, if it is necessary to keep 383 locale of characters, PRECIS profile designers should select local 384 case mapping as alternative to Unicode Default Case Folding. 386 Appendix C. Limitation to local case mapping 388 As described in the section Section 2.3, the possible target 389 characters of local case mapping are specified in SpecialCasing.txt. 390 The Unicode Standard (at least, up to version 7.0.0) does not define 391 any context-dependent mappings between "GREEK SMALL LETTER SIGMA" 392 (U+03C3) (hereinafter referred to as "small sigma") and "GREEK SMALL 393 LETTER FINAL SIGMA" (U+03C2) (hereinafter referred to as "final 394 sigma"). Thus, local case mapping is not applicable to small sigma 395 or final sigma, so case mapping in the PRECIS framework always maps 396 final sigma to small sigma, independent of context, as also specified 397 by Unicode Default Case Folding. (Note: Following comments are from 398 SpecialCasing.txt.) 400 # Note: the following cases are not included, since they would 401 case-fold in lowercasing 402 # 03C3; 03C2; 03A3; 03A3; Final_Sigma; # GREEK SMALL LETTER SIGMA 403 # 03C2; 03C3; 03A3; 03A3; Not_Final_Sigma; # GREEK SMALL LETTER 405 Appendix D. Change Log 407 D.1. Changes since -00 409 o Modify the Section 4.3 "Local case mapping" to specify the method 410 to calculate codepoints that local case mapping targets. 412 o Add the Section 6 "Open issues". 414 o Modify the Section 7 "IANA Considerations". 416 o Modify the Section 8 "Security Considerations". 418 o Remove the "The initial PRECIS local case mapping registrations". 420 o Add the Appendix C "Code points list for local case mapping". 422 o Add the Appendix D "Change Log". 424 D.2. Changes since -01 426 o Unified PRECIS notation in all capital letters as well as other 427 documents. 429 o Removed the Section 1 "Types of mapping" and the Section 2 430 "Protocol independent mapping" because width mapping is now in 431 framework document. 433 o Added relationship between the framework document and this 434 document in the Section 3 "Order of operations". 436 o Updated the Section 4 "Open issues" to address new issue raised on 437 mailing list. 439 o Move the Section 6 "IANA Considerations" after the Section 5 440 "Security Considerations". 442 o Remove the Appendix B "Codepoints which need special mapping" and 443 mentioned related documents in the Section 2.2 . 445 D.3. Changes since -02 447 o Removed the "Open issues". 449 D.4. Changes since -03 451 o Modify the Section 1 "Introduction" in more clear text. 453 o Modify the Section 2.3 "Local case mapping" to clarify the purpose 454 of the local case mapping and an example, and add restriction to 455 use with PRECIS framework. 457 o Change the format in the Appendix B "Code points list for local 458 case mapping". 460 o Split the Section 7 "References" into "Normative References" and 461 "Informative References" 463 o Update the Unicode version 6.2 to 6.3 in this document. 465 D.5. Changes since -04 467 o Correct a sentence in the Section 2.3 "Local case mapping". 469 D.6. Changes since -05 471 o Correct some sentences in this document. 473 o Modify the local case mapping's rule and target characters in the 474 Section 2.3 "Local case mapping". This is to avoid user's 475 confusion towards Greek's final sigma and German's eszett. 477 o Add the Section 4 "Open issues". 479 o Modify the Section 8 "Security Considerations". 481 o Modify the table format in the Appendix A. "Mapping type list 482 each protocol". 484 o Removed the Appendix B "Code points list for local case mapping". 486 o Add the Appendix B "Local case mapping vs Case mapping". 488 D.7. Changes since -06 490 o Removed the Section 4 "Open issues". 492 o Change the title of the Appendix B "Local case mapping vs Case 493 mapping" to "The reason why local case mapping is alternative to 494 case mapping in PRECIS framework". 496 o Add the Appendix C "Limitation to local case mapping". 498 D.8. Changes since -07 500 o Modify the Section 1 "Introduction". 502 o Modify the local case mapping's rule and target characters in the 503 Section 2.3 "Local case mapping". 505 o Modify the Section 3 "Order of operations". 507 D.9. Changes since -08 509 o Updated the Unicode version 6.3 to 7.0 in this document. 511 D.10. Changes since -09 513 o Modify the Section 1 "Introduction" to clarify to the discussion 514 of string matching and the use of mappings from the 515 SpecialCasing.txt. 517 o Modify the Section 2.3 "Local case mapping" to clarify to the 518 discussion of string matching and the use of mappings from the 519 SpecialCasing.txt. 521 o Modify the Appendix B "The reason why local case mapping is 522 alternative to case mapping in PRECIS framework" to state the 523 result of the case mapping in SpecialCasing.txt of eszett. 525 o Clarify the Appendix C "Limitation to local case mapping". 527 D.11. Changes since -10 529 o Modify the "Abstract" to clarify to sentences. 531 o Modify the Section 1 "Introduction" to clarify to a sentence. 533 o Modify the Section 2.2 "Special mapping" to add examples. 535 o Modify the Section 2.3 "Local case mapping" to clarify to 536 sentences. And add a note to explain the term "locale" in this 537 document. 539 o Modify the Section 3 "Order of operations" to clarify to 540 sentences. 542 o Correct a sentence in the Section 4 "Security Considerations". 544 o Modify a sentence in the Section 6 "Acknowledgment". 546 o Change the references from [I-D.ietf-precis-framework] to 547 [RFC7564] in the Section 7 "Normative References". 549 o Removed SASL and XMPP in the table of the Appendix A. "Mapping 550 type list each protocol". 552 o Modify the Appendix B "The reason why local case mapping is 553 alternative to case mapping in PRECIS framework" to clarify to 554 sentences. 556 o Modify the Appendix C "Limitation to local case mapping" to 557 clarify to sentences. 559 D.12. Changes since -11 561 o Correct a few sentence in the Section 2.3 "Local case mapping" to 562 address comments by the IESG review. 564 o Removed citation part which includes "RECOMMENDED" (RFC 2119 word) 565 in the Section 2.3 "Local case mapping" to avoid readers' 566 confusion. 568 o Modify the Section 4 "Security Considerations" to add a reference 569 to RFC7564. 571 Authors' Addresses 573 Yoshiro YONEYA 574 JPRS 575 Chiyoda First Bldg. East 13F 576 3-8-1 Nishi-Kanda 577 Chiyoda-ku, Tokyo 101-0065 578 Japan 580 Phone: +81 3 5215 8451 581 Email: yoshiro.yoneya@jprs.co.jp 583 Takahiro Nemoto 584 Keio University 585 Graduate School of Media Design 586 4-1-1 Hiyoshi, Kohoku-ku 587 Yokohama, Kanagawa 223-8526 588 Japan 590 Phone: +81 45 564 2517 591 Email: t.nemo10@kmd.keio.ac.jp