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

"Paul Koning" <Paul_Koning@Dell.com> Thu, 25 March 2010 22:58 UTC

Return-Path: <Paul_Koning@Dell.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 BD9A83A67E4 for <storm@core3.amsl.com>; Thu, 25 Mar 2010 15:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.169
X-Spam-Level:
X-Spam-Status: No, score=-104.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 SOAWT-G3Jjad for <storm@core3.amsl.com>; Thu, 25 Mar 2010 15:58:55 -0700 (PDT)
Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by core3.amsl.com (Postfix) with ESMTP id B0D8C3A69B0 for <storm@ietf.org>; Thu, 25 Mar 2010 15:58:54 -0700 (PDT)
X-Loopcount0: from 12.110.134.31
X-IronPort-AV: E=Sophos;i="4.51,309,1267423200"; d="scan'208";a="414707957"
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 25 Mar 2010 17:59:16 -0500
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: Thu, 25 Mar 2010 18:59:12 -0400
Message-ID: <D8CEBB6AE9D43848BD2220619A43F32653907B@M31.equallogic.com>
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB020DB34E@CORPUSMX80B.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrLFYOv3uBjX3T+S0isPHnVyiushAAYL9owABv758AAIhPdwA==
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> <C2D311A6F086424F99E385949ECFEBCB020DB34E@CORPUSMX80B.corp.emc.com>
From: "Paul Koning" <Paul_Koning@Dell.com>
To: <Black_David@emc.com>, <julian.satran@gmail.com>
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 22:58:55 -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").

You're right, and my explanation was confused because I was thinking
about an implementation that does apply *prep at login.

The right way to describe it is that login passes the name and indicates
which prep was used to prep it.  So earlier (at config time) when the
user supplied name was prepped, the config machinery has to store not
just the resulting string (which is what's sent in login and compared
bitwise) but also which prep was used for it.

	paul