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

[Julian Satran <[e-mail]>]

A way out that would enable things to coexist would be to negotiate  
stringprep or nameprep with stringprep mandatory and default and  
nameprep only when the two parties have it. It may not be a major  
issue for a while (or till we learn to live in Babylon :-)).

Regards,
Julo

On 24/03/2010, at 04:59, <[e-mail]> wrote:

> 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
>>
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm