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

[<[e-mail]>]

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):

	http://en.wikipedia.org/wiki/%C3%9F

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. 

Thanks,
--David

> -----Original Message-----
> From: Paul Koning [mailto:[e-mail]]
> Sent: Tuesday, March 23, 2010 3:34 PM
> To: Black, David; [e-mail]
> 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
"I'm
> > 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
Unicode
> > input string will need to map to a different newprep output string
vs.
> > stringprep output string for reasons involving Unicode.  If that's
the
> > 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
with
> a
> > "MUST", as the IDN folks have much deeper knowledge of what's going
on
> > 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
prepped
> 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
do
> 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
tell
> it to connect to Foo.  That initiator UI preps the string, which
results
> 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
previously
> stored names with the new rules.  That works ONLY if (a) all
previously
> valid names are still valid, (b) all previously distinct names are
still
> 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
>