idnits 2.17.1 draft-blanchet-precis-problem-statement-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2010) is 5042 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: 'UAX15' is mentioned on line 134, but not defined -- 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 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational July 5, 2010 5 Expires: January 6, 2011 7 Stringprep Revision Problem Statement 8 draft-blanchet-precis-problem-statement-00.txt 10 Abstract 12 Using Unicode codepoints in protocol strings requires preparation of 13 the string. Internationalized Domain Names(idn) initial work defined 14 and used Stringprep and Nameprep. Other protocols have defined 15 Stringprep profiles. A new approach different from Stringprep/ 16 Nameprep is used for a revision of IDN. The Stringprep profiles need 17 to be updated or a replacement of Stringprep need to be designed. 18 This document summarizes the findings of the current usage of 19 Stringprep and identifies directions for a new Stringprep replacement 20 protocol. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 6, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Usage and Issues of Stringprep . . . . . . . . . . . . . . . . 4 70 3. Considerations for Stringprep replacement . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 6. Discussion home for this draft . . . . . . . . . . . . . . . . 6 74 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 As part of the Internationalized Domain Names(idn) initial work 80 [RFC3490][RFC3491][RFC3492], the Unicode-based strings needed to be 81 prepared and normalized to enable their use in the DNS with exact 82 match mechanism. The method, called Nameprep [RFC3491], is specific 83 to idn, but is generalized as Stringprep [RFC3454], to help other 84 protocols with similar needs, but with different constraints than 85 idn. 87 Strinprep defines a framework where protocols defines their 88 Stringprep profiles. Known IETF specifications using Strinprep are: 89 o The Nameprep profile[RFC3490] for use in Internationalized Domain 90 Names (IDNs) 91 o The iSCSI profile [RFC3722] for use in Internet Small Computer 92 Systems Interface (iSCSI) Names 93 o The Nodeprep and Resourceprep profiles [RFC3920] for use in the 94 Extensible Messaging and Presence Protocol (XMPP) 95 o The Policy MIB profile [RFC4011] for use in the Simple Network 96 Management Protocol (SNMP) 97 o The SASLprep profile [RFC4013] for use in the Simple 98 Authentication and Security Layer (SASL) 99 o The trace profile [RFC4505] for use with the SASL ANONYMOUS 100 mechanism 101 o The LDAP profile [RFC4518] for use with LDAP 103 Based on findings [RFC4690] on early deployments of idn, IDNs 104 specifications have been updated /* note to add ref to idnabis RFCs*/ 105 and do not use stringprep/nameprep anymore. Instead, an algorithm 106 based on Unicode properties of codepoints is defined. That algorithm 107 generates a stable and complete table of the supported Unicode 108 codepoints. This algorithm is based on an inclusion-based approach, 109 instead of the exclusion-based approach of Stringprep/Nameprep. 111 This document lists the shortcomings and issues found by protocols 112 listed above that defined Stringprep profiles. It also lists some 113 early conclusions and requirements for a potential replacement of 114 Stringprep. 116 2. Usage and Issues of Stringprep 118 During IETF 77, a BOF discussed the current state of the protocols 119 that have defined Stringprep profiles. The main conclusions are /* 120 ref meeting notes */: 121 o Stringprep is bound to a specific version of Unicode: 3.2. 122 Stringprep has not been updated to new versions of Unicode. 123 Therefore, the protocols using Stringprep are stuck to Unicode 124 3.2. 125 o The protocols need to be updated to support new versions of 126 Unicode. The protocols would like to not be bound to a specific 127 version of Unicode, but rather have better Unicode agility as 128 IDNAbis. 129 o The protocols require better bidirectional support (bidi) than 130 currently offered by Stringprep. 131 o If the protocols are updated to use a new version of Stringprep or 132 another framework, then backward compatibility is an important 133 requirement. For example, Stringprep uses NFKC[UAX15], while 134 IDNAbis uses NFC[UAX15]. 135 o protocols are using each other, for example, a protocol can use 136 user identifiers that are later passed to SASL, LDAP or another 137 authentication mechanism. Therefore, common set of rules or 138 classes of strings are preferred over specific rules for each 139 protocol. 141 Stringprep profiles protocols use strings for different purposes: 142 o XMPP uses a different Stringprep profiles for each part of the 143 XMPP address (JID): a localpart which is similar to a username and 144 used for authentication, a domainpart which is a domain name and a 145 resource part which is less restrictive than the localpart. 146 o iSCSI uses a Stringprep profile for the IQN which is essentially a 147 domain name. 148 o SASL and LDAP uses a Stringprep profile for usernames. 149 o LDAP uses a set of Stringprep profiles. 151 During the newprep BOF, it was the concensus of the attendees that 152 the Stringprep profiles protocols would highly prefer to have a 153 replacement of Stringprep, with similar characteristics as the 154 IDNA2008. That replacement should be defined so that the protocols 155 would not have to "deal" with i18n strings in too much details since 156 i18n expertise is not available in the respective protocols or 157 working groups. 159 3. Considerations for Stringprep replacement 161 From the findings about, the following directions are proposed: 162 o A stringprep replacement should be defined. 163 o The replacement should take an approach similar to IDNA2008, 164 enabling Unicode agility. 165 o Protocols share similar characteristics of strings. Therefore, 166 defining i18n preparation algorithms for a small set of string 167 classes may be sufficient for most cases and provides the 168 coherence among a set of protocol friends. 170 4. Security Considerations 172 TBD 174 5. IANA Considerations 176 This document has no actions for IANA. 178 6. Discussion home for this draft 180 This document is intended to define the problem space discussed in 181 the precis@ietf.org mailing list. 183 7. Informative References 185 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 186 Internationalized Strings ("stringprep")", RFC 3454, 187 December 2002. 189 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 190 "Internationalizing Domain Names in Applications (IDNA)", 191 RFC 3490, March 2003. 193 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 194 Profile for Internationalized Domain Names (IDN)", 195 RFC 3491, March 2003. 197 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 198 for Internationalized Domain Names in Applications 199 (IDNA)", RFC 3492, March 2003. 201 [RFC3722] Bakke, M., "String Profile for Internet Small Computer 202 Systems Interface (iSCSI) Names", RFC 3722, April 2004. 204 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 205 Protocol (XMPP): Core", RFC 3920, October 2004. 207 [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based 208 Management MIB", RFC 4011, March 2005. 210 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 211 and Passwords", RFC 4013, February 2005. 213 [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and 214 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 216 [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol 217 (LDAP): Internationalized String Preparation", RFC 4518, 218 June 2006. 220 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and 221 Recommendations for Internationalized Domain Names 222 (IDNs)", RFC 4690, September 2006. 224 Author's Address 226 Marc Blanchet 227 Viagenie 228 2600 boul. Laurier, suite 625 229 Quebec, QC G1V 4W1 230 Canada 232 Email: Marc.Blanchet@viagenie.ca 233 URI: http://viagenie.ca