|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI NDT: Nameprep additionsJim Hafner wrote: > > Bob, > > The short answer to this is not an extraordinarily strong argument, > however..., it was felt that these names should follow many of the rules of > domain names. It was also felt that in many cases, the names might be > embedded in URLs (and the like). Also, since one of the naming conventions > is derived from domain names, there didn't seem a strong reason to allow > for any extra characters. So, the simpler the allowed set of > non-alpha-numeric characters (punctuation, whitespace, etc). the easier to > process, embed, extend, etc. I agree. The more we following domain names, the better. > On the other hand, doesn't an "underscore" accomplish much of what a > "white-space" character does for readability? The dash is the white-space substitute used in domain names and such; underscores are not allowed. In an iSCSI name, a dot can also be used as a separator. Like domain names, I would recommend using the dash to denote word or other separation within a hierarchical component of a name, and the dot to denote separation between different parts of a hierarchy. > > Jim Hafner > > Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 08/20/2001 12:27:24 pm > > Sent by: owner-ips@ece.cmu.edu > > To: "'Mark Bakke'" <mbakke@cisco.com>, Kaladhar > Voruganti/Almaden/IBM@IBMUS, IPS <ips@ece.cmu.edu> > cc: > Subject: RE: iSCSI NDT: Nameprep additions > > Mark, > > Why did we want to prohibit a properly normalized > white-space character? I have > always felt that spaces are useful supplements to readability, > especially for symbolic character sets. > > Bob > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Thursday, August 16, 2001 2:20 PM > To: Kaladhar Voruganti; IPS > Subject: iSCSI NDT: Nameprep additions > > Kaladhar- > > Here are some modifications to make to the NDT doc to > add nameprep. For now, these changes will assume that > nameprep will become an RFC before we do; if this is > a problem, we will do some more cut-and-paste later. > > -- > Mark > > Replace: > > 3. iSCSI names must be transcribable by humans. iSCSI names should > be kept as simple as possible, and should not use more than a > few special characters. They must also be case-insensitive, and > cannot include white space. > > With: > > 3. iSCSI names must be transcribable by humans. iSCSI names should > be kept as simple as possible, and should not use more than a > few special characters. They must provide for the use of > international character sets, and must not allow the use of > different names that would be identical except for their case. > Whitespace characters must not be allowed. > > Replace: > > The iSCSI Name may be displayed by user interfaces, but is generally > uninterpreted and used as an opaque, case-sensitive string for > comparison with other iSCSI Name values. > > With: > > The iSCSI Name may be displayed by user interfaces, but is generally > uninterpreted and used as an opaque string for comparison with other > iSCSI Name values. > > Replace: > > An iSCSI name can be any Unicode character string with the following > properties: > > - it is in Normalization Form C (see Unicode Standard Annex #15, > "Unicode Normalization Forms" at > http://www.unicode.org/unicode/reports/15) > > - it contains only the ASCII dash character ('-'=U+002d) or the > ASCII dot character ('.'=U+002e) or is in one of the following > Unicode General Categories: > > a) Lu (Letter, Uppercase) > b) Ll (Letter, Lowercase) > c) Lt (Letter, Titlecase) > d) Lm (Letter, Modifier) > e) Lo (Letter, Other) > f) Nd (Number, Decimal Digit) > g) Nl (Number, Letter) > > h) No (Number, Other) > > - when encoded in UTF-8, it is no more than 255 bytes > > In particular, white space, punctuation (except as noted), marks and > symbols are not allowed. > > With: > > An iSCSI name can be any Unicode character string with the following > properties: > > - it is in Normalization Form C (see Unicode Standard Annex #15, > "Unicode Normalization Forms" at > http://www.unicode.org/unicode/reports/15) > > - it contains only the following types of characters: > > - ASCII dash character ('-'=U+002d) > - ASCII dot character ('.'=U+002e) > - Any character allowed by the output of the nameprep > process > > - when encoded in UTF-8, it is no more than 255 bytes > > The output of the nameprep process is described in [NAMEPREP]. Nameprep > is a method designed by the Internationalized Domain Name (IDN) working > group to translate human-typed strings into a format that can be > compared > as opaque strings, and does not include punctuation, spacing, dicritical > marks, or other characters that could get in the way of > transcribability. > It also converts everything into its equivalent of lower case. > > Note that in most cases, the nameprep process does not need to be > implemented: > > - If the names are just generated using lower-case (in any > character set) plus digits, no normalization is required. > > - If the names are generated from some other all-ASCII string, > tolower() normalizes and isalnum() verifies. > > - If the names are generated from more general, internationalized > text, either the equivalent of tolower() and isalnum() appropriate > to the character set may be used, or the full nameprep procedure > can be used. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054
Home Last updated: Tue Sep 04 01:03:58 2001 6315 messages in chronological order |