Re: [storm] iSCSI and Unicode (newprep BOF)

<> Wed, 24 March 2010 02:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD3B43A694C for <>; Tue, 23 Mar 2010 19:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.086
X-Spam-Status: No, score=-4.086 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nxc+6s18loDh for <>; Tue, 23 Mar 2010 19:59:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 37AB83A690A for <>; Tue, 23 Mar 2010 19:59:21 -0700 (PDT)
Received: from ( []) by (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2O2xcHx012251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 22:59:39 -0400
Received: from ( []) by (RSA Interceptor); Tue, 23 Mar 2010 22:59:25 -0400
Received: from ( []) by (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2O2xPhh031398; Tue, 23 Mar 2010 22:59:25 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 22:59:25 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Mar 2010 22:59:15 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrKL8paRodDqgKHQVq2eNKhUajyAQASD8BAAAuYuMAABglLsAAPJ18A
References: <> <> <> <>
From: <>
To: <>, <>
X-OriginalArrivalTime: 24 Mar 2010 02:59:25.0371 (UTC) FILETIME=[02F6C0B0:01CACAFE]
X-EMM-EM: Active
Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Mar 2010 02:59:22 -0000

Bad news - we are going to have unavoidable incompatibility problems,
courtesy of domain name changes in how Unicode is handled.  There are
four characters that cause these problems, of which the easiest to
explain is the German eszett or sharp s (looks like a Greek beta
character for those not familiar with German):

This is often changed to a pair of ordinary s characters (e.g. StraBe
vs. Strasse), but that change is not always correct.  Stringprep mapped
sharp s to ss, but the new 2008 domain name specifications apparently
allow the Unicode character to be used - LATIN SMALL LETTER SHARP S'
(U+00DF).  Any IQN constructed from such a domain name would be
corrupted by stringprep mapping sharp s to ss.

While easiest to explain, this is not the worst problem - the worst
problem involves some non-printing format characters that stringprep
ignores in a fashion that causes serious problems (meaning changes) in
languages such as Persian.

More details on the newprep BOF coming in a later message. 


> -----Original Message-----
> From: Paul Koning []
> Sent: Tuesday, March 23, 2010 3:34 PM
> To: Black, David;
> Subject: RE: [storm] iSCSI and Unicode (newprep BOF)
> > > Re "Any update SHOULD be backward compatible with RFC 3722" -- I
> > don't understand the "SHOULD".  The
> > > obvious word is "MUST".  More precisely -- and maybe this is where
> > the "SHOULD" came in? -- an IQN
> > > that was legal under RFC 3722 must still be legal, and two names
> that
> > under the old rules were
> > > considered different must still be different.
> >
> > The "SHOULD" is there to a significant extent so that I can plead
> > not a Unicode expert" ;-).  At the iSCSI protocol level, I expect
> > everything to be backwards-compatible because iSCSI names aren't
> > checked for stringprep compliance on login (the iSCSI name string
> > comparison for equality is basically opaque wrt Unicode issues).
> >
> > Moving up to the iSCSI name input level (human involvement), it is
> > possible that things have changed in Unicode so that the same
> > input string will need to map to a different newprep output string
> > stringprep output string for reasons involving Unicode.  If that's
> > case (and especially if some previously valid inputs have to be
> > prohibited), then everything will need to be carefully explained and
> > documented with advice on how to cope ... but I hesitate to lead
> a
> > "MUST", as the IDN folks have much deeper knowledge of what's going
> > here, what needed to be done with Unicode domain names, and why (a
> > "MUST" risks freezing iSCSI @ an old version of Unicode).
> If so, then so be it.  I really do want MUST here.
> Consider a simple example.  To avoid getting deep into Unicode, let's
> use an ASCII analogy.  Let's say the old rule is that names are
> by tolower() and the new rule says they are prepped by toupper().  And
> let's assume that this operation is done only when the target name is
> mentioned in some management UI as you suggested.  (I think we might
> it also at login, but it doesn't actually affect the outcome of the
> example in a way that matters.)
> Ok, so in the old version, the admin asked me to create target Foo,
> which I prepped to "foo", so we now have that target.  Next the user
> tells the initiator to log in to Foo and the initiator preps that to
> "foo" which comes across the login protocol exchange and all is well.
> Now we go to the new rule.  The admin sets up a new initiator, and
> it to connect to Foo.  That initiator UI preps the string, which
> in "FOO".  That comes across in the login.  We do binary compare at
> login time, so the result of the login operation is "no such target".
> You might think you can cure this problem by re-prepping all
> stored names with the new rules.  That works ONLY if (a) all
> valid names are still valid, (b) all previously distinct names are
> distinct.
> We clearly can't have a case where an existing iSCSI target becomes
> inaccessible because of new name rules; this is my reason for saying
> that any newprep changes MUST not have such an effect.
> 	paul