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

<Black_David@emc.com> Thu, 25 March 2010 06:48 UTC

Return-Path: <Black_David@emc.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7133A6CA8 for <storm@core3.amsl.com>; Wed, 24 Mar 2010 23:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.59
X-Spam-Level:
X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI8EBm5hjval for <storm@core3.amsl.com>; Wed, 24 Mar 2010 23:48:09 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5A51C3A6CA5 for <storm@ietf.org>; Wed, 24 Mar 2010 23:48:07 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o2P6mRqD026106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Mar 2010 02:48:27 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 25 Mar 2010 02:48:14 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2P6mDo4025956; Thu, 25 Mar 2010 02:48:14 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 02:48:13 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Mar 2010 02:48:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <C2D311A6F086424F99E385949ECFEBCB020DB34E@CORPUSMX80B.corp.emc.com>
In-Reply-To: <D8CEBB6AE9D43848BD2220619A43F326538FB5@M31.equallogic.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
thread-index: AcrLFYOv3uBjX3T+S0isPHnVyiushAAYL9owABv758A=
References: <C2D311A6F086424F99E385949ECFEBCB01FA6ADD@CORPUSMX80B.corp.emc.com><D8CEBB6AE9D43848BD2220619A43F326538EF2@M31.equallogic.com><C2D311A6F086424F99E385949ECFEBCB020DAA1B@CORPUSMX80B.corp.emc.com><D8CEBB6AE9D43848BD2220619A43F326538F55@M31.equallogic.com><C2D311A6F086424F99E385949ECFEBCB020DACD8@CORPUSMX80B.corp.emc.com><539DC7A9-D167-4606-A479-B229A0308AF4@gmail.com> <D8CEBB6AE9D43848BD2220619A43F326538FB5@M31.equallogic.com>
From: <Black_David@emc.com>
To: <Paul_Koning@Dell.com>, <julian.satran@gmail.com>
X-OriginalArrivalTime: 25 Mar 2010 06:48:13.0871 (UTC) FILETIME=[24335BF0:01CACBE7]
X-EMM-EM: Active
Cc: storm@ietf.org
Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 06:48:10 -0000

Paul,

<WG chair hat off>

> For existing names, a name lookup is done by the matching rules for
the
> encoding that was given.  (For example, a request for "straBe" when
> there is an existing name "strasse" will match that names if the
> requested encoding was UTF8-stringprep, and will fail (no such name)
if
> the requested encoding was UTF8-newprep.

That concerns me.  One of the benefits we obtain from stringprep is that
we don't have any Unicode handling functionality on login - the iSCSI
names are just compared for equality (stringprep has to be done before
the names get to iSCSI).  I view that comparison as robust, and hence
would prefer not to move away from it at the iSCSI protocol level unless
there is no other alternative (i.e., my preference would be that if
"straBe" is allowed, then it is *always* different from "strasse").

Thanks,
--David

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
Of Paul Koning
> Sent: Wednesday, March 24, 2010 1:27 PM
> To: Julian Satran; Black, David
> Cc: storm@ietf.org
> Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
> 
> > 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
> 
> That sounds promising.  It effectively creates two encodings: one is
> UTF8-stringprep and the other is UTF8-newprep.
> 
> The hard part is to figure out what to do with names that are handled
> differently by the two rules.  The question applies to new names
(names
> added after this machinery is put in) and old names.
> 
> For new names, I think you'd want to use these rules:
> 
> a. A new name is legal only if both stringprep and newprep consider it
> legal
> b. A name is unique (i.e., allowed to name a new object distinct from
> existing objects) only if it is distinct by both the stringprep and
> newprep rules.
> 
> For example, using the example that David mentioned (German sharp s,
> written here as B for ASCIIness): stringprep maps StraBe to strasse,
> while newprep uses the separate Unicode character.  So if I have an
> existing iSCSI name "strasse" and I propose to create a new name
> "straBe" this will be rejected because it isn't unique by both
> stringprep and newprep rules (only newprep calls it unique).
> 
> For existing names, a name lookup is done by the matching rules for
the
> encoding that was given.  (For example, a request for "straBe" when
> there is an existing name "strasse" will match that names if the
> requested encoding was UTF8-stringprep, and will fail (no such name)
if
> the requested encoding was UTF8-newprep.
> 
> 	paul
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm