RE: iSCSI NDT: Nameprep additions

[Robert Snively <rsnively@Brocade.COM>]

It was my assumption that we are striving for international
localization capabilities.  If that is so, an underscore looks
somewhat like the number 1 in the Chinese character set.
I haven't the foggiest idea how it might be interpreted
in other character sets, some of which have strongly
horizontal-oriented marks.

I would expect that domain names will eventually pick up the same
freedom in international character sets. 

Besides that, I have always hated having to use underscores 
and dashes in names.  Perhaps that is my Apple-user 
background coming out, or maybe it is my having to reach 
two directions with my little fingers to hit underscore on 
a QWERTY keyboard.

Bob

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, August 21, 2001 7: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.
> 
> 
> 
>