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

Julian Satran <julian.satran@gmail.com> Thu, 25 March 2010 06:39 UTC

Return-Path: <julian.satran@gmail.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 6492F3A6C63 for <storm@core3.amsl.com>; Wed, 24 Mar 2010 23:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.24
X-Spam-Level:
X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 TCJ3kkA2RRwt for <storm@core3.amsl.com>; Wed, 24 Mar 2010 23:39:51 -0700 (PDT)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 358233A6452 for <storm@ietf.org>; Wed, 24 Mar 2010 23:39:50 -0700 (PDT)
Received: by bwz3 with SMTP id 3so7093296bwz.29 for <storm@ietf.org>; Wed, 24 Mar 2010 23:40:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=UKLThVESk+3+eiKCzFrPpqI1EWFzKoTHubjfVSmfjf4=; b=ulGYsV+PKf1watMOpuJ9/QqFClfZscCbiGyOjxvcHd81Rb2hv1FmaZPSMgv6a79HWF Q7O0+AWi8qTUlcbrQCpWvVOs9K63HLMLleD01yCirUzCnqrzJg0kWiczQP9OVOgj6Ng+ 4e3DC8RdqFStkoF1bN+PK0snPeUS265YEfhyM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=pxpQFNWB+nTbkOSDKgSPB/2/T5q4nWIpVHpCDL3hascTwPmmHlvDzXJfUoB52WhmJC iLfCW88r6fKc4wBx87z+C6vG6AimLgj7pvlzCDwh7L0mhQEMA9pccDxS4IsdmmgEisON RkPKI1JfnrS+437a6RJEvQmUtXZi6LNEsnnVo=
Received: by 10.204.4.139 with SMTP id 11mr3087209bkr.27.1269499206483; Wed, 24 Mar 2010 23:40:06 -0700 (PDT)
Received: from [10.180.144.111] ([192.118.11.118]) by mx.google.com with ESMTPS id 24sm7197522bkr.12.2010.03.24.23.40.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 23:40:05 -0700 (PDT)
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>
Message-Id: <BE762ADA-7FF5-4B3C-9805-68A2653141F6@gmail.com>
From: Julian Satran <julian.satran@gmail.com>
To: Paul Koning <Paul_Koning@Dell.com>
In-Reply-To: <D8CEBB6AE9D43848BD2220619A43F326538FB5@M31.equallogic.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7D11)
Mime-Version: 1.0 (iPhone Mail 7D11)
Date: Thu, 25 Mar 2010 08:40:02 +0200
Cc: "<Black_David@emc.com>" <Black_David@emc.com>, "<storm@ietf.org>" <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:39:52 -0000

Paul,

I think we should be slightly more lenient and to this end David's  
should may come in handy. We should not prevent an administrator that  
whishes to enforce the new naming (rules) and is prepared to pay for  
it to do so. Making/requiring the names to be unique on both or not  
should be left to the administrators. I suppose we may require the  
nameprep team to specify transliteration rules to ease the burden of  
administrators and implementors and mandate those (or one pf those)  
for iSCSI.

Regards,
Julo

On 24/03/2010, at 19:26, "Paul Koning" <Paul_Koning@Dell.com> wrote:

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