RFC 3722

RFC 3722: String Profile for Internet Small Computer Systems Interface (iSCSI) Names 💖

okay so, title block time! 🎀 This one is from the Network Working Group, it's RFC 3722, and it was written by Mark Bakke (M. Bakke) at Cisco 💅. It's on the Standards Track and it came out in April 2004 🦋. There's no Obsoletes or Updates line, so it doesn't replace or change any other RFC. Iconic, honestly 👑.

---

Status of this Memo ✨

bestie, this part is the legal-ish bit, but it's short 💜. This is an Internet standards track protocol document for the Internet community, and it's asking for discussion and suggestions for improvements 🌸. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🫶.

Copyright Notice 🌈

Copyright (C) The Internet Society (2004). All Rights Reserved. 🔒

Abstract 🦋

okay so the big idea is this: this doc explains how to prepare internationalized iSCSI names so that typing them in and comparing them makes sense for people all over the world 🌍✨. iSCSI lets hosts reach SCSI devices over an IP network 🔥. Its end-points (initiators and targets) each have a globally-unique name, and that name has to be easy to transcribe and easy to compare 💖.

1. Introduction ✨

The iSCSI protocol [RFC3720] lets hosts access SCSI [SAM2] devices over an IP network 🌐. The end-points, initiators and targets, each have a globally-unique name, which is defined in [RFC3721] 🎀.

An iSCSI name is a string of UTF-8 [RFC3629] characters 💅. It has a type designator, a naming authority that's based on domain names, and a unique part inside that naming authority 🧚. The naming authority can make the unique part from anything it finds useful, and that can include user input 🙈.

Names get passed around between admins by email, voice, paper, and so on 📧, so case-insensitive comparison would be nice 💜. BUT the initiator and target implementations do the comparing, and most of those are tiny embedded software 🤖. For those implementors, case-sensitive comparison is highly desirable 🔥.

Here's the tricky part: if everything were fully case-sensitive, then example-name and Example-Name would count as different, and that's a recipe for confusion when people transcribe names 💀.

So the goal is names that people can transcribe and type in, that can also be compared byte-for-byte, with as little confusion as possible 🫶. To get there, iSCSI names are generalized using a normalized character set (converted to lower case or something equivalent) ✨, with no white space allowed and only a very limited amount of punctuation 🍓.

For anyone using only ASCII characters (U+0000 to U+007F) 🌸, these are the allowed characters:

• 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)

Also, any upper-case characters input via a user interface MUST be mapped to their lower-case equivalents 💅. That MUST is non-negotiable, bestie 🙅‍♀️.

This document lays out the valid character set for iSCSI names, plus the rules for normalizing and generating names from user input or other info that has international characters 🌈.

Specifically, following what [RFC3454] requires, it defines the following 📋:

• 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 💖.

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] 🎀. (Yes, those are the official BCP 14 key words, and yes they're capitalized on purpose 💅.)

Examples in this doc use the notation for code points and names from the Unicode Standard [Unicode3.2] and ISO/IEC 10646 [ISO10646] 🔤. For example, the letter "a" can be written as either "U+0061" or "LATIN SMALL LETTER A" ✨. In the lists of prohibited characters, the "U+" is left off so they're easier to read 👀. The comments for character ranges are in square brackets (like "[SYMBOLS]") and they 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 that show up in 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
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, and those get checked outside of this profile 👀.

On top of those tables, this profile adds its own prohibitions 🔥. The full set of prohibited characters is everything from the tables above PLUS the ones listed individually below 💜.

6.1. Inappropriate Characters from Common Input Mechanisms 🙈

u+3002 gets used as if it were u+002e in lots of domain name input mechanisms that apps use, especially in Asia 🌏. So u+3002 MUST NOT be used in an iSCSI name 💀.

3002; ideographic full stop

6.2. Currently-prohibited ASCII characters 🎀

Some ASCII characters are currently prohibited in iSCSI names by [RFC3721], and they're also used in protocol elements like URIs 🌐. Examples are described in [RFC2396] and [RFC2732] 📚. Heads up: lots of other RFCs define extra URI schemes too 🧚.

The other characters in the range U+0000 to U+007F that aren't currently allowed are prohibited in iSCSI names, so they stay reserved 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]

15. Full Copyright Statement ✨

Okay so this part is the legal stuff, but make it cute 🎀. The copyright belongs to The Internet Society (2004) 💜. This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 📜.

Now the disclaimer, which is in all caps because it's SERIOUS 😭. This document and the info in it 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 🙈. That includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 💅.

Intellectual Property 🦋

Here's the vibe: the IETF takes no position on whether any Intellectual Property Rights (or other rights that might be claimed) are valid or how far they reach, and it doesn't say whether any license might be available for the tech described here 🌸. It also doesn't claim it has made any independent effort to find those rights ✨. If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79 💜.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found from the IETF on its online IPR repository at:

http://www.ietf.org/ipr

The IETF also invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 🫶. Send that info to the IETF at:

ietf-ipr@ietf.org

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💖.