|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI NDT: Nameprep additionsI want to second Jim's comments. This class of i18n issues can be like the proverbial Adventure game "maze of little twisty passages, all different", and following as closely as we can what the domain naming folks are doing is the easiest way to avoid spending an extended amount of time in this quagmire. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Tuesday, August 21, 2001 10:58 AM > To: Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI NDT: Nameprep additions > > > > 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. > > On the other hand, doesn't an "underscore" accomplish much of what a > "white-space" character does for readability? > > 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. > > >
Home Last updated: Tue Sep 04 01:03:58 2001 6315 messages in chronological order |