summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3722.txt')
-rw-r--r--doc/rfc/rfc3722.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3722.txt b/doc/rfc/rfc3722.txt
new file mode 100644
index 0000000..0eb44ff
--- /dev/null
+++ b/doc/rfc/rfc3722.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group M. Bakke
+Request for Comments: 3722 Cisco
+Category: Standards Track April 2004
+
+
+ String Profile for Internet Small Computer
+ Systems Interface (iSCSI) Names
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes how to prepare internationalized iSCSI names
+ to increase the likelihood that name input and comparison work in
+ ways that make sense for typical users throughout the world.
+
+ The Internet Small Computer Systems Interface (iSCSI) protocol
+ provides a way for hosts to access SCSI devices over an IP network.
+ The iSCSI end-points, called initiators and targets, each have a
+ globally-unique name that must be transcribable, as well as easily
+ compared.
+
+1. Introduction
+
+ The iSCSI protocol [RFC3720] provides a way for hosts to access SCSI
+ [SAM2] devices over an IP network. The iSCSI end-points, called
+ initiators and targets, each have a globally-unique name, defined in
+ [RFC3721].
+
+ An iSCSI name is a string of UTF-8 [RFC3629] characters that includes
+ a type designator, a naming authority based on domain names, and a
+ unique part within the naming authority. The unique part may be
+ generated based on anything the naming authority deems useful, and
+ may include user input.
+
+ These names may need to be transcribed (sent between two
+ administrators via email, voice, paper, etc), so a case-insensitive
+ comparison would be desirable. However, these names must often be
+
+
+
+Bakke Standards Track [Page 1]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+ compared by initiator and target implementations, most of which are
+ done in simple, embedded software. This makes case-sensitive
+ comparison highly desirable for these implementors.
+
+ However, a completely case-sensitive implementation would result in
+ identifiers such as "example-name" and "Example-Name" being
+ different, which could lead to confusion as these names are
+ transcribed.
+
+ The goal, then, is to generate iSCSI names that can be transcribed
+ and entered by users, and also compared byte-for-byte, with minimal
+ confusion. To attain these goals, iSCSI names are generalized using
+ a normalized character set (converted to lower case or equivalent),
+ with no white space allowed, and very limited punctuation.
+
+ For those using only ASCII characters (U+0000 to U+007F), the
+ following characters are allowed:
+
+ - ASCII dash character ('-' = U+002d)
+ - ASCII dot character ('.' = U+002e)
+ - ASCII colon character (':' = U+003a)
+ - ASCII lower-case characters ('a'..'z' = U+0061..U+007a)
+ - ASCII digit characters ('0'..'9' = U+0030..U+0039)
+
+ In addition, any upper-case characters input via a user interface
+ MUST be mapped to their lower-case equivalents.
+
+ This document specifies the valid character set for iSCSI names,
+ along with the rules for normalizing and generating iSCSI names based
+ on user input or other information that contains international
+ characters.
+
+ In particular, it defines the following, as required by [RFC3454]:
+
+ - The intended applicability of the profile: internationalized iSCSI
+ names.
+
+ - The character repertoire that is the input and output to
+ stringprep: Unicode 3.2, specified in section 3.
+
+ - The mappings used: specified in section 4.
+
+ - The Unicode normalization used: specified in section 5.
+
+ - The characters that are prohibited as output: specified in section
+ 6.
+
+ This profile MUST be used with the iSCSI protocol.
+
+
+
+Bakke Standards Track [Page 2]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Examples in this document use the notation for code points and names
+ from the Unicode Standard [Unicode3.2] and ISO/IEC 10646 [ISO10646].
+ For example, the letter "a" may be represented as either "U+0061" or
+ "LATIN SMALL LETTER A". In the lists of prohibited characters, the
+ "U+" is left off to make the lists easier to read. The comments for
+ character ranges are shown in square brackets (such as "[SYMBOLS]")
+ and do not come from the standards.
+
+3. Character Repertoire
+
+ This profile uses Unicode 3.2, as defined in [RFC3454] Appendix A.
+
+4. Mapping
+
+ This profile specifies mapping using the following tables from
+ [RFC3454]. The following mapping tables MUST be used when generating
+ iSCSI names from Unicode characters.
+
+ Table B.1
+ Table B.2
+
+5. Normalization
+
+ Unicode normalization form KC MUST be used with this profile, as
+ described in [RFC3454].
+
+6. Prohibited Output
+
+ This profile specifies prohibiting using the following tables from
+ [RFC3454]. Characters appearing within these tables MUST NOT be used
+ within an iSCSI name.
+
+ Table C.1.1
+ Table C.1.2
+ Table C.2.1
+ Table C.2.2
+ Table C.3
+ Table C.4
+ Table C.5
+ Table C.6
+
+
+
+
+
+Bakke Standards Track [Page 3]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+ Table C.7
+ Table C.8
+ Table C.9
+
+ Important note: this profile MUST be used with the iSCSI protocol.
+ The iSCSI protocol has additional naming rules that are checked
+ outside of this profile.
+
+ In addition, this profile adds the following prohibitions. The full
+ set of prohibited characters are those from the tables above plus
+ those listed individually below.
+
+6.1. Inappropriate Characters from Common Input Mechanisms
+
+ u+3002 is used as if it were u+002e in many domain name input
+ mechanisms used by applications, particularly in Asia. The character
+ u+3002 MUST NOT be used in an iSCSI name.
+
+ 3002; ideographic full stop
+
+6.2. Currently-prohibited ASCII characters
+
+ Some of the ASCII characters that are currently prohibited in iSCSI
+ names by [RFC3721] are also used in protocol elements such as URIs.
+ Some examples are described in [RFC2396] and [RFC2732]. Note that
+ there are many other RFCs that define additional URI schemes.
+
+ The other characters in the range U+0000 to U+007F that are not
+ currently allowed are prohibited in iSCSI names to reserve them for
+ future use in protocol elements. Note that the dash (U+002D), dot
+ (U+002E), and colon (U+003A) are not prohibited.
+
+ The following characters MUST NOT be used in iSCSI names:
+
+ 0000-002C; [ASCII CONTROL CHARACTERS and SPACE through ,]
+ 002F; [ASCII /]
+ 003B-0040; [ASCII ; through @]
+ 005B-0060; [ASCII [ through `]
+ 007B-007F; [ASCII { through DEL]
+
+7. Bidirectional Characters
+
+ This profile specifies checking bidirectional strings as described in
+ [RFC3454] section 6.
+
+
+
+
+
+
+
+Bakke Standards Track [Page 4]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+8. Unassigned Code Points in Internationalized Domain Names
+
+ If the processing in [RFC3720] specifies that a list of unassigned
+ code points be used, the system uses table A.1 from [RFC3454] as its
+ list of unassigned code points.
+
+9. Security Considerations
+
+ ISO/IEC 10646 has many characters that look similar. In many cases,
+ users of security protocols might do visual matching, such as when
+ comparing the names of trusted third parties. This profile does
+ nothing to map similar-looking characters together.
+
+ iSCSI names may be used by an initiator to verify that a target it
+ has discovered is the correct one, and by a target to verify that an
+ initiator is to be allowed access. If these names are interpreted
+ and compared differently by different iSCSI implementations, an
+ initiator could gain access to the wrong target, or could be denied
+ access to a legitimate target.
+
+10. IANA Considerations
+
+ This is a profile of stringprep. It has been registered in the IANA
+ "Stringprep Profiles" registry. This process is described in the
+ IANA Considerations section of [RFC3454].
+
+11. Summary
+
+ This document describes a stringprep profile to be used with programs
+ generating names for iSCSI initiators and targets.
+
+12. Acknowledgements
+
+ This document was produced as a result of discussions on iSCSI name
+ formats with Joe Czap, Jim Hafner, Howard Hall, Jack Harwood, John
+ Hufferd, Marjorie Krueger, Lawrence Lamers, Todd Sperry, Joshua
+ Tseng, and Kaladhar Voruganti, as well as discussions on the
+ normalization of names into identifiers with Paul Hoffman and Marc
+ Blanchet.
+
+ Thanks also to Bob Snively for suggesting the use of the nameprep
+ process for iSCSI name normalization.
+
+ Most of this document was copied from the stringprep profile for
+ Internationalized Domain Names [RFC3491], written by Paul Hoffman and
+ Marc Blanchet.
+
+
+
+
+
+Bakke Standards Track [Page 5]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+13. References
+
+13.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M.
+ and E. Zeidner, "Internet Small Computer Systems
+ Interface (iSCSI)", RFC 3720, April 2004.
+
+13.2. Informative References
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+ Resource Identifiers", RFC 2396, August 1998.
+
+ [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
+ Literal IPv6 Addresses in URL's", RFC 2732, December
+ 1999.
+
+ [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+ Profile for Internationalized Domain Names", RFC 3491,
+ March 2003.
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and M.
+ Krueger, "Internet Small Computer Systems Interface
+ (iSCSI) Naming and Discovery", RFC 3721, April 2004.
+
+ [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
+
+ [Unicode3.2] The Unicode Standard, Version 3.2.0: The Unicode
+ Consortium. The Unicode Standard, Version 3.2.0 is
+ defined by The Unicode Standard, Version 3.0 (Reading,
+ MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
+ amended by the Unicode Standard Annex #27: Unicode 3.1
+ (http://www.unicode.org/unicode/reports/tr27/) and by
+ the Unicode Standard Annex #28: Unicode 3.2
+ (http://www.unicode.org/unicode/reports/tr28/).
+
+
+
+
+
+
+
+Bakke Standards Track [Page 6]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+ [ISO10646] ISO/IEC 10646-1:2000. International Standard --
+ Information technology -- Universal Multiple-Octet Coded
+ Character Set (UCS) -- Part 1: Architecture and Basic
+ Multilingual Plane.
+
+14. Author's Address
+
+ Mark Bakke
+ Cisco Systems, Inc.
+ 6450 Wedgwood Road
+ Maple Grove, MN
+ USA 55311
+
+ Voice: +1 763-398-1000
+ EMail: mbakke@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke Standards Track [Page 7]
+
+RFC 3722 String Profile for iSCSI Names April 2004
+
+
+15. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Bakke Standards Track [Page 8]
+