doc: Add RFC documents

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]
+