idnits 2.17.1 draft-ietf-ips-iscsi-string-prep-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC3491]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-10) exists of draft-ietf-ips-iscsi-name-disc-09 -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2044 (Obsoleted by RFC 2279) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2732 (Obsoleted by RFC 3986) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Bakke 3 Cisco 4 Standards Track 5 Expires February 2004 7 August 2003 9 String Profile for iSCSI Names 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The iSCSI protocol provides a way for hosts to access SCSI devices 39 over an IP network. The iSCSI end-points, called initiators and 40 targets, each have a globally-unique name that must be transcribable, 41 as well as easily compared. 43 This document describes how to prepare internationalized iSCSI names 44 to increase the likelihood that name input and comparison work in 45 ways that make sense for typical users throughout the world. 47 Acknowledgements 49 This draft was produced as a result of discussions on iSCSI name 50 formats with Joe Czap, Jim Hafner, Howard Hall, Jack Harwood, John 51 Hufferd, Marjorie Krueger, Lawrence Lamers, Todd Sperry, Joshua 52 Tseng, and Kaladhar Voruganti, as well as discussions on the 53 normalization of names into identifiers with Paul Hoffman and Marc 54 Blanchet. 56 Thanks also to Bob Snively for suggesting the use of the nameprep 57 process for iSCSI name normalization. 59 Most of this draft was copied from the stringprep profile for 60 Internationalized Domain Names [RFC3491], written by Paul Hoffman and 61 Marc Blanchet. 63 1. Introduction 65 The iSCSI protocol [iSCSI] provides a way for hosts to access SCSI 66 [SAM2] devices over an IP network. The iSCSI end-points, called 67 initiators and targets, each have a globally-unique name, defined in 68 [NDT]. 70 An iSCSI name is a string of UTF-8 [RFC2044] characters that includes 71 a type designator, a naming authority based on domain names, and a 72 unique part within the naming authority. The unique part may be 73 generated based on anything the naming authority deems useful, and 74 may include user input. 76 These names may need to be transcribed (sent between two 77 administrators via email, voice, paper, etc), so a case- insensitive 78 comparison would be desirable. However, these names must often be 79 compared by initiator and target implementations, most of which are 80 done in simple, embedded software. This makes case-sensitive 81 comparison highly desirable for these implementors. 83 However, a completely case-sensitive implementation would result in 84 identifiers such as "example-name" and "Example-Name" being 85 different, which could lead to confusion as these names are 86 transcribed. 88 The goal, then, is to generate iSCSI names that can be transcribed 89 and entered by users, and also compared byte-for-byte, with minimal 90 confusion. To attain these goals, iSCSI names are generalized using 91 a normalized character set (converted to lower case or equivalent), 92 with no white space allowed, and very limited punctuation. 94 For those using only ASCII characters (U+0000 to U+007F), the 95 following characters are allowed: 97 - ASCII dash character ('-' = U+002d) 98 - ASCII dot character ('.' = U+002e) 99 - ASCII colon character (':' = U+003a) 100 - ASCII lower-case characters ('a'..'z' = U+0061..U+007a) 101 - ASCII digit characters ('0'..'9' = U+0030..U+0039) 103 In addition, any upper-case characters input via a user interface 104 should be mapped to their lower-case equivalents. 106 This document specifies the valid character set for iSCSI names, 107 along with the rules for normalizing and generating iSCSI names based 108 on user input or other information that contains international 109 characters. 111 In particular, it defines the following, as required by [RFC3454]: 113 - The intended applicability of the profile: internationalized iSCSI 114 names. 116 - The character repertoire that is the input and output to 117 stringprep: Unicode 3.2, specified in section 3. 119 - The mappings used: specified in section 4. 121 - The Unicode normalization used: specified in section 5. 123 - The characters that are prohibited as output: specified in section 124 6. 126 This profile MUST be used with the iSCSI protocol. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 Examples in this document use the notation for code points and names 135 from the Unicode Standard [Unicode3.2] and ISO/IEC 10646 [ISO10646]. 136 For example, the letter "a" may be represented as either "U+0061" or 137 "LATIN SMALL LETTER A". In the lists of prohibited characters, the 138 "U+" is left off to make the lists easier to read. The comments for 139 character ranges are shown in square brackets (such as "[SYMBOLS]") 140 and do not come from the standards. 142 3. Character Repertoire 144 This profile uses Unicode 3.2, as defined in [RFC3454] Appendix A. 146 4. Mapping 148 This profile specifies mapping using the following tables from 149 [RFC3454]. The following mapping tables MUST be used when generating 150 iSCSI names from Unicode characters. 152 Table B.1 153 Table B.2 155 5. Normalization 157 Unicode normalization form KC MUST be used with this profile, as 158 described in [RFC3454]. 160 6. Prohibited Output 162 This profile specifies prohibiting using the following tables from 163 [stringprep]. Characters appearing within these tables MUST NOT be 164 used within an iSCSI name. 166 Table C.1.1 167 Table C.1.2 168 Table C.2.1 169 Table C.2.2 170 Table C.3 171 Table C.4 172 Table C.5 173 Table C.6 174 Table C.7 175 Table C.8 176 Table C.9 178 Important note: this profile MUST be used with the iSCSI protocol. 179 The iSCSI protocol has additional naming rules that are checked 180 outside of this profile. 182 In addition, this profile adds the following prohibitions. The full 183 set of prohibited characters are those from the tables above plus 184 those listed individually below. 186 6.1. Inappropriate Characters from Common Input Mechanisms 188 u+3002 is used as if it were u+002e in many domain name input 189 mechanisms used by applications, particularly in Asia. The character 190 u+3002 MUST NOT be used in an iSCSI name. 192 3002; ideographic full stop 194 6.2. Currently-prohibited ASCII characters 196 Some of the ASCII characters that are currently prohibited in iSCSI 197 names by [NDT] are also used in protocol elements such as URIs. Some 198 examples are described in [RFC2396] and [RFC2732]. Note that there 199 are many other RFCs that define additional URI schemes. 201 The other characters in the range U+0000 to U+007F that are not 202 currently allowed are prohibited in iSCSI names to reserve them for 203 future use in protocol elements. Note that the dash (U+002D), dot 204 (U+002E), and colon (U+003A) are not prohibited. 206 The following characters MUST NOT be used in iSCSI names: 208 0000-002C; [ASCII CONTROL CHARACTERS and SPACE through ,] 209 002F; [ASCII /] 210 003B-0040; [ASCII ; through @] 211 005B-0060; [ASCII [ through `] 212 007B-007F; [ASCII { through DEL] 214 7. Bidirectional Characters 216 This profile specifies checking bidirectional strings as described in 217 [RFC3454] section 6. 219 8. Unassigned Code Points in Internationalized Domain Names 221 If the processing in [iSCSI] specifies that a list of unassigned code 222 points be used, the system uses table A.1 from [RFC3454] as its list 223 of unassigned code points. 225 9. Security Considerations 227 ISO/IEC 10646 has many characters that look similar. In many cases, 228 users of security protocols might do visual matching, such as when 229 comparing the names of trusted third parties. This profile does 230 nothing to map similar-looking characters together. 232 iSCSI names may be used by an initiator to verify that a target it 233 has discovered is the correct one, and by a target to verify that an 234 initiator is to be allowed access. If these names are interpreted 235 and compared differently by different iSCSI implementations, an 236 initiator could gain access to the wrong target, or could be denied 237 access to a legitimate target. 239 10. IANA Considerations 241 This is a profile of stringprep. When it has been reviewed and 242 approved by the IESG, it should be registered in the IANA "Stringprep 243 Profiles" registry. This process is described in the IANA 244 Considerations section of [RFC3454]. 246 11. Summary 248 This document describes a stringprep profile to be used with programs 249 generating names for iSCSI initiators and targets. 251 12. Normative References 253 [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate 254 Requirement Levels", RFC 2119, March 1997. 256 [RFC3454] Paul Hoffman and Marc Blanchet, "Preparation of 257 Internationalized Strings ("stringprep")", RFC 3454, 258 December 2002. 260 [iSCSI] J. Satran, et. al. "iSCSI", Work In Progress, draft-ietf- 261 ips-iscsi-20.txt, January 2003. 263 13. Informative References 265 [NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", Work in 266 Progress, draft-ietf-ips-iscsi-name-disc-09, March 2003. 268 [RFC3491] P. Hoffman and M. Blanchet, "Nameprep: A Stringprep Profile 269 for Internationalized Domain Names", RFC 3491, March 2003. 271 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 273 [RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and 274 ISO 10646", RFC 2044, October 1996. 276 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 277 Identifiers", RFC 2396, August 1998. 279 [RFC2732] R. Hindon, B. Carpenter, L Masinter, "Format for Literal 280 IPv6 Addresses in URLs", RFC 2732, December 1999. 282 [Unicode3.2] 283 The Unicode Standard, Version 3.2.0: The Unicode Consortium. 284 The Unicode Standard, Version 3.2.0 is defined by The 285 Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 286 2000. ISBN 0-201-61633-5), as amended by the Unicode 287 Standard Annex #27: Unicode 3.1 288 (http://www.unicode.org/unicode/reports/tr27/) and by the 289 Unicode Standard Annex #28: Unicode 3.2 290 (http://www.unicode.org/unicode/reports/tr28/). 292 [ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information 293 technology -- Universal Multiple-Octet Coded Character Set 294 (UCS) -- Part 1: Architecture and Basic Multilingual Plane. 296 14. Author Contact Information 298 Mark Bakke 299 Cisco Systems, Inc. 300 6450 Wedgwood Road 301 Maple Grove, MN 302 USA 55311 304 Voice: +1 763-398-1000 305 E-Mail: mbakke@cisco.com 307 15. Full Copyright Notice 309 Copyright (C) The Internet Society (2001). All Rights Reserved. 311 This document and translations of it may be copied and furnished to 312 others, and derivative works that comment on or otherwise explain it 313 or assist in its implementation may be prepared, copied, published 314 and distributed, in whole or in part, without restriction of any 315 kind, provided that the above copyright notice and this paragraph are 316 included on all such copies and derivative works. However, this 317 document itself may not be modified in any way, such as by removing 318 the copyright notice or references to the Internet Society or other 319 Internet organizations, except as needed for the purpose of 320 developing Internet standards in which case the procedures for 321 copyrights defined in the Internet Standards process must be 322 followed, or as required to translate it into languages other than 323 English. 325 The limited permissions granted above are perpetual and will not be 326 revoked by the Internet Society or its successors or assigns. 328 This document and the information contained herein is provided on an 329 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 330 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 331 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 332 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 333 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Acknowledgement 337 Funding for the RFC Editor function is currently provided by the 338 Internet Society.