Re: [storm] iSCSI and Unicode (newprep BOF)
"Paul Koning" <Paul_Koning@Dell.com> Wed, 24 March 2010 17:26 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 15B593A6D4C for <storm@core3.amsl.com>; Wed, 24 Mar 2010 10:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.869
X-Spam-Level:
X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 q4Z-34WAyo-M for <storm@core3.amsl.com>; Wed, 24 Mar 2010 10:26:46 -0700 (PDT)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 792573A6D37 for <storm@ietf.org>; Wed, 24 Mar 2010 10:26:35 -0700 (PDT)
X-Loopcount0: from 12.110.134.31
X-IronPort-AV: E=Sophos;i="4.51,301,1267423200"; d="scan'208";a="438794377"
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 24 Mar 2010 12:26:55 -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: Wed, 24 Mar 2010 13:26:52 -0400
Message-ID: <D8CEBB6AE9D43848BD2220619A43F326538FB5@M31.equallogic.com>
In-Reply-To: <539DC7A9-D167-4606-A479-B229A0308AF4@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI and Unicode (newprep BOF)
Thread-Index: AcrLFYOv3uBjX3T+S0isPHnVyiushAAYL9ow
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>
From: Paul Koning <Paul_Koning@Dell.com>
To: Julian Satran <julian.satran@gmail.com>, Black_David@emc.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: Wed, 24 Mar 2010 17:26:47 -0000
> 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] iSCSI and Unicode (newprep BOF) Black_David
- Re: [storm] iSCSI and Unicode (newprep BOF) Mark Bakke (mbakke)
- Re: [storm] iSCSI and Unicode (newprep BOF) Paul Koning
- Re: [storm] iSCSI and Unicode (newprep BOF) Black_David
- Re: [storm] iSCSI and Unicode (newprep BOF) Paul Koning
- Re: [storm] iSCSI and Unicode (newprep BOF) Black_David
- Re: [storm] iSCSI and Unicode (newprep BOF) Peter Saint-Andre
- Re: [storm] iSCSI and Unicode (newprep BOF) Black_David
- Re: [storm] iSCSI and Unicode (newprep BOF) Julian Satran
- Re: [storm] iSCSI and Unicode (newprep BOF) Paul Koning
- Re: [storm] iSCSI and Unicode (newprep BOF) Julian Satran
- Re: [storm] iSCSI and Unicode (newprep BOF) Black_David
- Re: [storm] iSCSI and Unicode (newprep BOF) Paul Koning