draft-ietf-precis-problem-statement-06.txt   draft-ietf-precis-problem-statement-07.txt 
Network Working Group M. Blanchet Network Working Group M. Blanchet
Internet-Draft Viagenie Internet-Draft Viagenie
Intended status: Informational A. Sullivan Intended status: Informational A. Sullivan
Expires: January 10, 2013 Dyn, Inc. Expires: February 4, 2013 Dyn, Inc.
July 9, 2012 August 3, 2012
Stringprep Revision and PRECIS Problem Statement Stringprep Revision and PRECIS Problem Statement
draft-ietf-precis-problem-statement-06.txt draft-ietf-precis-problem-statement-07.txt
Abstract Abstract
If a protocol expects to compare two strings and is prepared only for If a protocol expects to compare two strings and is prepared only for
those strings to be ASCII, then using Unicode codepoints in those those strings to be ASCII, then using Unicode codepoints in those
string requires they be prepared somehow. Internationalizing Domain strings requires they be prepared somehow. Internationalizing Domain
Names in Applications (here called IDNA2003) defined and used Names in Applications (here called IDNA2003) defined and used
Stringprep and Nameprep. Other protocols subsequently defined Stringprep and Nameprep. Other protocols subsequently defined
Stringprep profiles. A new approach different from Stringprep and Stringprep profiles. A new approach different from Stringprep and
Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other
Stringprep profiles need to be similarly updated or a replacement of Stringprep profiles need to be similarly updated or a replacement of
Stringprep needs to be designed. This document outlines the issues Stringprep needs to be designed. This document outlines the issues
to be faced by those designing a Stringprep replacement. to be faced by those designing a Stringprep replacement.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013. This Internet-Draft will expire on February 4, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Stringprep Profiles Limitations . . . . . . . . . . . . . . . 8 3. Stringprep Profiles Limitations . . . . . . . . . . . . . . . 6
4. Major Topics for Consideration . . . . . . . . . . . . . . . . 10 4. Major Topics for Consideration . . . . . . . . . . . . . . . . 8
4.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 10 4.1.1. Types of Identifiers . . . . . . . . . . . . . . . . . 8
4.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 10 4.1.2. Effect of comparison . . . . . . . . . . . . . . . . . 8
4.2. Dealing with characters . . . . . . . . . . . . . . . . . 10 4.2. Dealing with characters . . . . . . . . . . . . . . . . . 8
4.2.1. Case folding, case sensitivity, and case 4.2.1. Case folding, case sensitivity, and case
preservation . . . . . . . . . . . . . . . . . . . . . 11 preservation . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 11 4.2.2. Stringprep and NFKC . . . . . . . . . . . . . . . . . 9
4.2.3. Character mapping . . . . . . . . . . . . . . . . . . 11 4.2.3. Character mapping . . . . . . . . . . . . . . . . . . 9
4.2.4. Prohibited characters . . . . . . . . . . . . . . . . 12 4.2.4. Prohibited characters . . . . . . . . . . . . . . . . 10
4.2.5. Internal structure, delimiters, and special 4.2.5. Internal structure, delimiters, and special
characters . . . . . . . . . . . . . . . . . . . . . . 12 characters . . . . . . . . . . . . . . . . . . . . . . 10
4.2.6. Restrictions because of glyph similarity . . . . . . . 13 4.2.6. Restrictions because of glyph similarity . . . . . . . 11
4.3. Where the data comes from and where it goes . . . . . . . 13 4.3. Where the data comes from and where it goes . . . . . . . 11
4.3.1. User input and the source of protocol elements . . . . 13 4.3.1. User input and the source of protocol elements . . . . 11
4.3.2. User output . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. User output . . . . . . . . . . . . . . . . . . . . . 11
4.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Operations . . . . . . . . . . . . . . . . . . . . . . 12
5. Considerations for Stringprep replacement . . . . . . . . . . 16 5. Considerations for Stringprep replacement . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Discussion home for this draft . . . . . . . . . . . . . . . . 19 8. Discussion home for this draft . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 21 10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Classification of Stringprep Profiles . . . . . . . . 25 Appendix A. Classification of Stringprep Profiles . . . . . . . . 18
Appendix B. Evaluation of Stringprep Profiles . . . . . . . . . . 26 Appendix B. Evaluation of Stringprep Profiles . . . . . . . . . . 19
B.1. iSCSI Stringprep Profiles: RFC3722, RFC3721, RFC3720 . . . 26 B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721,
RFC3720) . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: B.2. SMTP/POP3/ManageSieve Stringprep Profiles:
RFC4954,RFC5034,RFC 5804 . . . . . . . . . . . . . . . . . 28 RFC4954,RFC5034,RFC 5804 . . . . . . . . . . . . . . . . . 20
B.3. IMAP Stringprep Profiles: RFC5738, RFC4314: Usernames . . 30 B.3. IMAP Stringprep Profiles: RFC5738, RFC4314: Usernames . . 22
B.4. IMAP Stringprep Profiles: RFC5738: Passwords . . . . . . . 31 B.4. IMAP Stringprep Profiles: RFC5738: Passwords . . . . . . . 23
B.5. Anonymous SASL Stringprep Profiles: RFC4505 . . . . . . . 33 B.5. Anonymous SASL Stringprep Profiles: RFC4505 . . . . . . . 25
B.6. XMPP Stringprep Profiles: RFC3920 Nodeprep . . . . . . . . 35 B.6. XMPP Stringprep Profiles: RFC3920 Nodeprep . . . . . . . . 26
B.7. XMPP Stringprep Profiles: RFC3920 Resourceprep . . . . . . 36 B.7. XMPP Stringprep Profiles: RFC3920 Resourceprep . . . . . . 27
B.8. EAP Stringprep Profiles: RFC3748 . . . . . . . . . . . . . 37 B.8. EAP Stringprep Profiles: RFC3748 . . . . . . . . . . . . . 28
Appendix C. Changes between versions . . . . . . . . . . . . . . 39 Appendix C. Changes between versions . . . . . . . . . . . . . . 29
C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.3. 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.3. 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.4. 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.4. 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.5. 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.5. 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.6. 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.6. 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C.7. 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 C.7. 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Internationalizing Domain Names in Applications (here called Internationalizing Domain Names in Applications (here called
IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a
mechanism for encoding Unicode labels making up Internationalized mechanism for encoding Unicode labels making up Internationalized
Domain Names (IDNs) as standard DNS labels. The labels were Domain Names (IDNs) as standard DNS labels. The labels were
processed using a method called Nameprep [RFC3491] and Punycode processed using a method called Nameprep [RFC3491] and Punycode
[RFC3492]. That method was specific to IDNA2003, but is generalized [RFC3492]. That method was specific to IDNA2003, but is generalized
as Stringprep [RFC3454]. The general mechanism is used by other as Stringprep [RFC3454]. The general mechanism is used by other
skipping to change at page 7, line 8 skipping to change at page 6, line 36
derive whether a given code point actually is allowed in the derive whether a given code point actually is allowed in the
protocol. protocol.
This document lists the shortcomings and issues found by protocols This document lists the shortcomings and issues found by protocols
listed above that defined Stringprep profiles. It also lists the listed above that defined Stringprep profiles. It also lists the
requirements for any potential replacement of Stringprep. requirements for any potential replacement of Stringprep.
2. Conventions 2. Conventions
A single Unicode code point in this memo is denoted by "U+" followed A single Unicode code point in this memo is denoted by "U+" followed
by four to six hexadecimal digits. Compare to [Unicode61], Appendix by four to six hexadecimal digits, as used in [Unicode61], Appendix
A. A.
3. Stringprep Profiles Limitations 3. Stringprep Profiles Limitations
During IETF 77, a BOF discussed the current state of the protocols During IETF 77 (March 2010), a BOF discussed the current state of the
that have defined Stringprep profiles [NEWPREP]. The main protocols that have defined Stringprep profiles [NEWPREP]. The main
conclusions from that discussion were as follows: conclusions from that discussion were as follows:
o Stringprep is bound to version 3.2 of Unicode. Stringprep has not o Stringprep is bound to version 3.2 of Unicode. Stringprep has not
been updated to new versions of Unicode. Therefore, the protocols been updated to new versions of Unicode. Therefore, the protocols
using Stringprep are stuck to Unicode 3.2. using Stringprep are stuck at Unicode 3.2, and their
specifications need to be updated to support new versions of
Unicode.
o The protocols need to be updated to support new versions of o The protocols would like to not be bound to a specific version of
Unicode. The protocols would like to not be bound to a specific Unicode, but rather have better Unicode version agility in the way
version of Unicode, but rather have better Unicode agility in the of IDNA2008. This is important partly because it is usually
way of IDNA2008. This is important partly because it is usually
impossible for an application to require Unicode 3.2; the impossible for an application to require Unicode 3.2; the
application gets whatever version of Unicode is available on the application gets whatever version of Unicode is available on the
host. host.
o The protocols require better bidirectional support (bidi) than o The protocols require better bidirectional support (bidi) than
currently offered by Stringprep. currently offered by Stringprep.
o If the protocols are updated to use a new version of Stringprep or o If the protocols are updated to use a new version of Stringprep or
another framework, then backward compatibility is an important another framework, then backward compatibility is an important
requirement. For example, Stringprep is based on and profiles may requirement. For example, Stringprep is based on and profiles may
use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15]. use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15].
o Identifiers are passed between protocols. For example, the same o Identifiers are passed between protocols. For example, the same
username string of codepoints may be passed between SASL, XMPP, username string of codepoints may be passed between SASL, XMPP,
LDAP and EAP. Therefore, common set of rules or classes of LDAP and EAP. Therefore, common set of rules or classes of
strings are preferred over specific rules for each protocol. strings are preferred over specific rules for each protocol.
Without real planning in advance, many stringprep profiles reuse Without real planning in advance, many stringprep profiles reuse
other profiles, so this goal was accomplished by accident with other profiles, so this goal was accomplished by accident with
Stringprep. Stringprep.
Protocols that use Stringprep profiles use strings for different Protocols that use Stringprep profiles use strings for different
purposes: purposes:
skipping to change at page 8, line 41 skipping to change at page 7, line 27
o Identifiers are passed between protocols. For example, the same o Identifiers are passed between protocols. For example, the same
username string of codepoints may be passed between SASL, XMPP, username string of codepoints may be passed between SASL, XMPP,
LDAP and EAP. Therefore, common set of rules or classes of LDAP and EAP. Therefore, common set of rules or classes of
strings are preferred over specific rules for each protocol. strings are preferred over specific rules for each protocol.
Without real planning in advance, many stringprep profiles reuse Without real planning in advance, many stringprep profiles reuse
other profiles, so this goal was accomplished by accident with other profiles, so this goal was accomplished by accident with
Stringprep. Stringprep.
Protocols that use Stringprep profiles use strings for different Protocols that use Stringprep profiles use strings for different
purposes: purposes:
o XMPP uses a different Stringprep profile for each part of the XMPP o XMPP uses a different Stringprep profile for each part of the XMPP
address (JID): a localpart which is similar to a username and used address (JID): a localpart which is similar to a username and used
for authentication, a domainpart which is a domain name and a for authentication, a domainpart which is a domain name and a
resource part which is less restrictive than the localpart. resource part which is less restrictive than the localpart.
o iSCSI uses a Stringprep profile for the names of protocol
o iSCSI uses a Stringprep profile for the IQN, which is very similar participants (called initiators and targets). The IQN format of
to (often is) a DNS domain name. iSCSI names contains a reversed DNS domain name.
o SASL and LDAP uses a Stringprep profile for usernames. o SASL and LDAP uses a Stringprep profile for usernames.
o LDAP uses a set of Stringprep profiles. o LDAP uses a set of Stringprep profiles.
The apparent judgement of the BOF attendees [NEWPREP] was that it The apparent judgement of the BOF attendees [NEWPREP] was that it
would be highly desirable to have a replacement of Stringprep, with would be highly desirable to have a replacement of Stringprep, with
similar characteristics to IDNA2008. That replacement should be similar characteristics to IDNA2008. That replacement should be
defined so that the protocols could use internationalized strings defined so that the protocols could use internationalized strings
without a lot of specialized internationalization work, since without a lot of specialized internationalization work, since
internationalization expertise is not available in the respective internationalization expertise is not available in the respective
protocols or working groups. Accordingly, the IESG formed the PRECIS protocols or working groups. Accordingly, the IESG formed the PRECIS
working group to undertake the task. working group to undertake the task.
skipping to change at page 25, line 20 skipping to change at page 18, line 38
called out in the ID type column (from Section 4.1.1), using the called out in the ID type column (from Section 4.1.1), using the
short forms "a" for Absolute, "d" for Definite, and "i" for short forms "a" for Absolute, "d" for Definite, and "i" for
Indefinite. Next, there is a column that contains an "i" if the Indefinite. Next, there is a column that contains an "i" if the
protocol string comes from user input, an "o" if the protocol string protocol string comes from user input, an "o" if the protocol string
becomes user-facing output, "b" if both are true, and "n" if neither becomes user-facing output, "b" if both are true, and "n" if neither
is true. is true.
+------+--------+-------+ +------+--------+-------+
| RFC | IDtype | User? | | RFC | IDtype | User? |
+------+--------+-------+ +------+--------+-------+
| 3722 | a | o | | 3722 | a | b |
| | | |
| 3748 | - | - | | 3748 | - | - |
| | | |
| 3920 | a,d | b | | 3920 | a,d | b |
| | | |
| 4505 | a | i | | 4505 | a | i |
| | | |
| 4314 | a,d | b | | 4314 | a,d | b |
| | | |
| 4954 | a,d | b | | 4954 | a,d | b |
| | | |
| 5034 | a,d | b | | 5034 | a,d | b |
| | | |
| 5804 | a,d | b | | 5804 | a,d | b |
+------+--------+-------+ +------+--------+-------+
Table 1 Table 1
Appendix B. Evaluation of Stringprep Profiles Appendix B. Evaluation of Stringprep Profiles
This section is a summary of evaluation of Stringprep profiles that This section is a summary of evaluation of Stringprep profiles that
was done to get a good understanding of the usage of Stringprep. was done to get a good understanding of the usage of Stringprep.
This summary is by no means normative nor the actual evaluations This summary is by no means normative nor the actual evaluations
themselves. A template was used for reviewers to get a coherent view themselves. A template was used for reviewers to get a coherent view
of all evaluations. of all evaluations.
B.1. iSCSI Stringprep Profiles: RFC3722, RFC3721, RFC3720 B.1. iSCSI Stringprep Profile: RFC3722 (and RFC3721, RFC3720)
Description: An iSCSI session consists of an Initiator (i.e., host Description: An iSCSI session consists of an initiator (i.e., host
or server that uses storage) communicating with a target (i.e., a or server that uses storage) communicating with a target (i.e., a
storage array or other system that provides storage). Both the storage array or other system that provides storage). Both the
iSCSI initiator and target are named by iSCSI Names. The iSCSI iSCSI initiator and target are named by iSCSI Names. The iSCSI
stringprep profile is used for iSCSI names. stringprep profile is used for iSCSI names.
How it is used iSCSI initiators and targets (see above). They can How it is used iSCSI initiators and targets (see above). They can
also be used to identify SCSI ports (these are software entities also be used to identify SCSI ports (these are software entities
in the iSCSI protocol, not hardware ports), and iSCSI logical in the iSCSI protocol, not hardware ports), and iSCSI logical
units (storage volumes), although both are unusual in practice. units (storage volumes), although both are unusual in practice.
What entities create these identifiers? Generally a Human user (1) What entities create these identifiers? Generally a Human user (1)
configures an Automated system (2) that generates the names. configures an Automated system (2) that generates the names.
Advance configuration of the system is required due to the Advance configuration of the system is required due to the
embedded use of external unique identifier (from the DNS or IEEE). embedded use of external unique identifier (from the DNS or IEEE).
How is the string input in the system? Keyboard and copy-paste are How is the string input in the system? Keyboard and copy-paste are
common. Copy-paste is common because iSCSI names are long enough common. Copy-paste is common because iSCSI names are long enough
to be problematic for humans to remember, causing use of email, to be problematic for humans to remember, causing use of email,
sneaker-net, text files, etc. to avoid mistype mistakes. sneaker-net, text files, etc. to avoid mistype mistakes.
Where do we place the dividing line between user interface and Where do we place the dividing line between user interface and
protocol? The iSCSI protocol requires that all internationalization protocol? The iSCSI protocol requires that all internationalization
string preparation occur in the user interface. The iSCSI string preparation occur in the user interface. The iSCSI
protocol treats iSCSI names as opaque identifiers that are protocol treats iSCSI names as opaque identifiers that are
compared byte-by-byte for equality. iSCSI names are generally not compared byte-by-byte for equality. iSCSI names are generally not
checked for correct formatting by the protocol. checked for correct formatting by the protocol.
What entities enforce the rules? There are no iSCSI-specific What entities enforce the rules? There are no iSCSI-specific
enforcement entities, although the use of unique identifier enforcement entities, although the use of unique identifier
information in the names relies on DNS registrars and the IEEE information in the names relies on DNS registrars and the IEEE
Registration Authority. Registration Authority.
Comparison Byte-by-byte Comparison Byte-by-byte
Case Folding, Sensitivity, Preservation Case folding is required for Case Folding, Sensitivity, Preservation Case folding is required for
the code blocks specified in RFC 3454, Table B.2. The overall the code blocks specified in RFC 3454, Table B.2. The overall
iSCSI naming system (UI + protocol) is case-insensitive. iSCSI naming system (UI + protocol) is case-insensitive.
What is the impact if the comparison results in a false positive? What is the impact if the comparison results in a false positive?
Potential access to the wrong storage. - If the initiator has no Potential access to the wrong storage. - If the initiator has no
access to the wrong storage, an authentication failure is the access to the wrong storage, an authentication failure is the
probable result. - If the initiator has access to the worng probable result. - If the initiator has access to the wrong
storage, the resulting mis-identificaiton could result in use of storage, the resulting mis-identification could result in use of
the wrong data and possible corruption of stored data. the wrong data and possible corruption of stored data.
What is the impact if the comparison results in a false negative? What is the impact if the comparison results in a false negative?
Denial of authorized storage access. Denial of authorized storage access.
What are the security impacts? iSCSI names may be used as the
What are the security impacts? iSCSI names are often used as the
authentication identities for storage systems. Comparison authentication identities for storage systems. Comparison
problems could result in authentication problems, although note problems could result in authentication problems, although note
that authentication failure ameliorates some of the false positive that authentication failure ameliorates some of the false positive
cases. cases.
Normalization NFKC, as specified by RFC 3454. Normalization NFKC, as specified by RFC 3454.
Mapping Yes, as specified by table B.1 in RFC 3454 Mapping Yes, as specified by table B.1 in RFC 3454
Disallowed Characters Only the following characters are allowed: - Disallowed Characters Only the following characters are allowed: -
ASCII dash, dot, colon - ASCII lower case letters and digits - ASCII dash, dot, colon - ASCII lower case letters and digits -
Unicode lower case characters as specified by RFC 3454 All other Unicode lower case characters as specified by RFC 3454 All other
characters are disallowed. characters are disallowed.
Which other strings or identifiers are these most similar to? None - Which other strings or identifiers are these most similar to? None -
iSCSI names are unique to iSCSI. iSCSI names are unique to iSCSI.
Are these strings or identifiers sometimes the same as strings or Are these strings or identifiers sometimes the same as strings or
identifiers from other protocols? No identifiers from other protocols? No
Does the identifier have internal structure that needs to be Does the identifier have internal structure that needs to be
respected? Yes - ASCII dot, dash and colon are used for internal respected? Yes - ASCII dot, dash and colon are used for internal
name structure. These are not reserved characters in that they name structure. These are not reserved characters in that they
can occur in the name in locations other than those used for can occur in the name in locations other than those used for
structuring purposes (e.g., only the first occurrence of a colon structuring purposes (e.g., only the first occurrence of a colon
character is structural, others are not). character is structural, others are not).
How are users exposed to these strings? How are they published? How are users exposed to these strings? How are they published?
iSCSI names appear in server and storage system configuration iSCSI names appear in server and storage system configuration
interfaces. They also appear in system logs. interfaces. They also appear in system logs.
Is the string / identifier used as input to other operations? Is the string / identifier used as input to other operations?
Effectively, no. The rarely used port and logical unit names Effectively, no. The rarely used port and logical unit names
involve concatenation, which effectively extends a unique iSCSI involve concatenation, which effectively extends a unique iSCSI
Name for a target to uniquely identify something within that Name for a target to uniquely identify something within that
target. target.
How much tolerance for change from existing stringprep approach? How much tolerance for change from existing stringprep approach?
Good tolerance; the community would prefer that Good tolerance; the community would prefer that
internationalization experts solve internationalization problems internationalization experts solve internationalization problems.
;-).
How strong a desire for change (e.g., for Unicode agility)? Unicode How strong a desire for change (e.g., for Unicode agility)? Unicode
agility is desired in principle as long as nothing significant agility is desired in principle as long as nothing significant
breaks. breaks.
B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC4954,RFC5034,RFC B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC4954,RFC5034,RFC
5804 5804
Description: Authorization identity (user identifier) exchanged Description: Authorization identity (user identifier) exchanged
during SASL authentication: AUTH (SMTP/POP3) or AUTHENTICATE during SASL authentication: AUTH (SMTP/POP3) or AUTHENTICATE
(ManageSieve) command. (ManageSieve) command.
 End of changes. 47 change blocks. 
99 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/