Re: [nfsv4] work items to complete rfc3530bis (what are they?)
<Noveck_David@emc.com> Thu, 01 April 2010 18:00 UTC
Return-Path: <Noveck_David@emc.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7833A6A9D for <nfsv4@core3.amsl.com>; Thu, 1 Apr 2010 11:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.169
X-Spam-Level:
X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 L2fR4WIFjtoj for <nfsv4@core3.amsl.com>; Thu, 1 Apr 2010 11:00:03 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id EE6163A6A94 for <nfsv4@ietf.org>; Thu, 1 Apr 2010 11:00:02 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o31I0Yxg010368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Thu, 1 Apr 2010 14:00:34 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Thu, 1 Apr 2010 14:00:28 -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 o31I0JQ5002152 for <nfsv4@ietf.org>; Thu, 1 Apr 2010 14:00:27 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.39]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 14:00:18 -0400
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, 01 Apr 2010 14:00:18 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D802771EF@CORPUSMX50A.corp.emc.com>
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB021F29A5@CORPUSMX80B.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] work items to complete rfc3530bis (what are they?)
Thread-Index: AcrQ+u63s0+trbtxT2mBgBigZ3mxiwABKhXAAAH76fAAAFS5EAAsasiQ
From: Noveck_David@emc.com
To: Black_David@emc.com, nfsv4@ietf.org
X-OriginalArrivalTime: 01 Apr 2010 18:00:18.0774 (UTC) FILETIME=[309B7F60:01CAD1C5]
X-EMM-EM: Active
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 18:00:05 -0000
> An easy example to explain is the German ezsett character > (aka 'sharp s')- this character resembles a Greek beta and > is pronounced as if it were double-s. The existing approach > is to map ezsett to double-s, and the results of that mapping > are *not* always easily invertible. For example, after mapping > a certain German street name, "passstrasse" is the result - a > native speaker of German knows what the correct input string > was (only the last double-s was an ezsett), but computers don't > tend to be native speakers of German ;-). This mapping of ezsett > to double-s is now wrong according to German language experts > (it's apparently as wrong in German as mis-spelling "receive" > as "recieve" would be in English), Or saying "for him and I" :-) > hence ezsett will become an allowed Unicode character in domain > names. OK. That's the easy example to explain. Thanks, David. So they made a mistake and need to fix the mistake and it appears they are willing to fix the mistake. So far, so good. > If I read Nico's note correctly that NFSv4 uses stringprep > for some strings, My understanding is that we were essentially told that we had to in RFC3530. Spencer can confirm or deny. I think it was part of this whole you-don't-want-to-deal-with-this-stuff-on-your-own line of thought which makes perfect sense until the reality of what having others dealing with it for you involves. > then this change will likely have to be dealt with, It has to be dealt with by somebody but why does it have to be dealt with by us? We specified what we were told/asked to. Our expertise regarding German characters is limited (as it is for Greek, Arabic, Hebrew, Syriac, Devanagari, etc. characters). There needs to be a way to address mistakes like this found after RFC publication that doesn't force the users of stringprep (for example) to care or modify their specs. We do not want to have to do RFC3530tris, RFC3530tetrakis, etc, to address future such issues that come up. > and not > doing so results in implicitly specifying that NFSv4 not deal > correctly with some German strings. I understand the specification issue, but for practical purposes it really doesn't matter. People will do what they choose, with customer requirements having a major role in what characters, including ezsett or not, are accepted. We can't even get some clients and servers to use UTF-8 for their filenames. People are not struggling to avoid arousing the ire of an all-powerful All-IETF Extraordinary Commission to Combat Specification Non-compliance. That's a good thing in general but it means that there is no overriding need to make the specification perfect on matters like this, especially since perfection is moving target. As you indicated, we don't want to deal with this stuff ourselves, so we should just point at the latest extant set of specs in this area, that we can easily point to without rewriting the string-handling section, and then say people MAY make generally accepted character mapping changes. They're going to do it anyway. -----Original Message----- From: Black, David Sent: Wednesday, March 31, 2010 4:13 PM To: Noveck, David; 'nfsv4@ietf.org' Subject: RE: [nfsv4] work items to complete rfc3530bis (what are they?) Dave, > > It's also the situation that > > at least for stringprep, there are four Unicode input characters whose > > on-the-wire representation changes incompatibly due to character mapping > > changes. > > Will someone wake me up from this nightmare? > > Suppose I decided that we should swap ASCII a and b, also c and d. I know the existing mapping has > served us well, and it is used in many existing files, but it really gets boring to stick to the same > old mapping. Perhaps that sounds a little "drbzy"? English doesn't have character mapping issues, hence there are no good English examples to explain what happened. It's not a matter of swapping characters - it's a matter of what appear (in 20/20 hindsight) to be mapping mistakes for non-ASCII characters in languages that have larger alphabets. An easy example to explain is the German ezsett character (aka 'sharp s')- this character resembles a Greek beta and is pronounced as if it were double-s. The existing approach is to map ezsett to double-s, and the results of that mapping are *not* always easily invertible. For example, after mapping a certain German street name, "passstrasse" is the result - a native speaker of German knows what the correct input string was (only the last double-s was an ezsett), but computers don't tend to be native speakers of German ;-). This mapping of ezsett to double-s is now wrong according to German language experts (it's apparently as wrong in German as mis-spelling "receive" as "recieve" would be in English), hence ezsett will become an allowed Unicode character in domain names. If I read Nico's note correctly that NFSv4 uses stringprep for some strings, then this change will likely have to be dealt with, and not doing so results in implicitly specifying that NFSv4 not deal correctly with some German strings. Caveat: I don't know all the NFSv4 details here, and to some extent I'm reasoning by analogy from iSCSI where stringprep is used for on-the-wire strings that are compared for equality (and hence these mapping changes will have to be dealt with). Thanks, --David > -----Original Message----- > From: Noveck, David > Sent: Wednesday, March 31, 2010 3:30 PM > To: Black, David; nfsv4@ietf.org > Cc: Black, David > Subject: RE: [nfsv4] work items to complete rfc3530bis (what are they?) > > > It's also the situation that > > at least for stringprep, there are four Unicode input characters whose > > on-the-wire representation changes incompatibly due to character mapping > > changes. > > Will someone wake me up from this nightmare? > > Suppose I decided that we should swap ASCII a and b, also c and d. I know the existing mapping has > served us well, and it is used in many existing files, but it really gets boring to stick to the same > old mapping. Perhaps that sounds a little "drbzy"? > > -----Original Message----- > From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of Black_David@emc.com > Sent: Wednesday, March 31, 2010 2:41 PM > To: nfsv4@ietf.org > Cc: Black, David > Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?) > > Nico, > > > IDNAbis doesn't radically change IDNA, at least not in ways that > matter > > to NFSv4. There's still A-labels and U-labels (new terminology) and > > IDN-aware and IDN-unaware domainname slots, and we still need to > decide > > whether NFSv4 domainname slots are IDN-aware or not. > > Unfortunately the IDNAbis mappings draft is Dead, and that's a source of > incompatibilities if IDNs are currently being used with NFSv4. One > potential problem area is that IDNAbis has no notion of case > folding/conversion (e.g., to lower case). It's also the situation that > at least for stringprep, there are four Unicode input characters whose > on-the-wire representation changes incompatibly due to character mapping > changes. > > > The Newprep BoF isn't relevant to the IDNAbis work, but it is > > potentially relevant to any protocol that uses stringprep profiles for > > anything other than a domainname slot (that includes NFSv4). > > I would suggest that *if* NFSv4 cares about Unicode issues, *then* > it(we) should join the newprep effort. Any decision about whether to > adopt the stringprep-bis approach that is likely to emerge from newprep > can be deferred until that result is better understood. The alternative > of NFSv4 tackling Unicode issues on its own is unappealing, IMHO ... and > I would hazard a guess that the responsible ADs will use even more > negative language on this topic if asked ;-). > > Thanks, > --David > > > -----Original Message----- > > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > > Sent: Wednesday, March 31, 2010 1:51 PM > > To: Black, David > > Cc: spencer.shepler@gmail.com; bfields@fieldses.org; > Thomas.Haynes@sun.com; nfsv4@ietf.org; > > trond.myklebust@fys.uio.no > > Subject: Re: [nfsv4] work items to complete rfc3530bis (what are > they?) > > > > On Tue, Mar 30, 2010 at 08:56:59PM -0400, Black_David@emc.com wrote: > > > > Search the RFC DB for "IDN" and "IDNA" and "Internationalized > Domain > > > Names". > > > > > > It gets worse ... Anyone who believes they understand how Unicode > works > > > in IDN needs to go look @ the proceedings of the newprep BOF in > Anaheim. > > > There are IDN changes coming (approved Internet-Drafts that are not > yet > > > published as RFCs). > > > > All of these IDNAbis I-Ds are on the RFC-Editor queue right now: > > > > - draft-ietf-idnabis-protocol-18 > > - draft-ietf-idnabis-rationale-17 > > - draft-ietf-idnabis-defs-13 > > - draft-ietf-idnabis-bidi-07 > > - draft-ietf-idnabis-mappings-05 > > - draft-ietf-idnabis-tables-09 > > > > https://datatracker.ietf.org/doc/draft-ietf-idnabis-protocol/ > > https://datatracker.ietf.org/doc/.../ > > > > The Newprep BoF isn't relevant to the IDNAbis work, but it is > > potentially relevant to any protocol that uses stringprep profiles for > > anything other than a domainname slot (that includes NFSv4). > > > > IDNAbis doesn't radically change IDNA, at least not in ways that > matter > > to NFSv4. There's still A-labels and U-labels (new terminology) and > > IDN-aware and IDN-unaware domainname slots, and we still need to > decide > > whether NFSv4 domainname slots are IDN-aware or not. > > > > Nico > > -- > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] work items to complete rfc3530bis (what a… Spencer Shepler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Tom Haynes
- Re: [nfsv4] work items to complete rfc3530bis (wh… Tigran Mkrtchyan
- Re: [nfsv4] work items to complete rfc3530bis (wh… Spencer Shepler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck, Dave
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck, Dave
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Spencer
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Black_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Black_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Black_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… James Lentini
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… J. Bruce Fields
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Eisler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Chuck Lever
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Eisler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Eisler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David
- Re: [nfsv4] Dealing with IDN in rfc3530bis Noveck_David
- Re: [nfsv4] Dealing with IDN in rfc3530bis Mike Eisler
- Re: [nfsv4] What to do about stringprep for RFC35… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] What to do about stringprep for RFC35… Spencer
- Re: [nfsv4] What to do about stringprep for RFC35… Nicolas Williams
- Re: [nfsv4] What to do about stringprep for RFC35… Mike Eisler
- Re: [nfsv4] What to do about stringprep for RFC35… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Eisler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] What to do about stringprep for RFC35… Mike Eisler
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Eisler
- Re: [nfsv4] What to do about stringprep for RFC35… Noveck_David
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Trond Myklebust
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Mike Mackovitch
- Re: [nfsv4] work items to complete rfc3530bis (wh… Nicolas Williams
- Re: [nfsv4] work items to complete rfc3530bis (wh… Noveck_David