Re: [nfsv4] work items to complete rfc3530bis (what are they?)

<Black_David@emc.com> Wed, 31 March 2010 18:42 UTC

Return-Path: <Black_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 5FCC53A6A50 for <nfsv4@core3.amsl.com>; Wed, 31 Mar 2010 11:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.844
X-Spam-Level:
X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=0.625, 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 vjpb74XphYC9 for <nfsv4@core3.amsl.com>; Wed, 31 Mar 2010 11:42:16 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D8B4D3A6A2F for <nfsv4@ietf.org>; Wed, 31 Mar 2010 11:42:15 -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 o2VIgkPh024162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Wed, 31 Mar 2010 14:42:46 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Wed, 31 Mar 2010 14:42:39 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2VIgTCJ009154 for <nfsv4@ietf.org>; Wed, 31 Mar 2010 14:42:36 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 14:41:01 -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: Wed, 31 Mar 2010 14:41:00 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB021F28F9@CORPUSMX80B.corp.emc.com>
In-Reply-To: <20100331175032.GO4225@Sun.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] work items to complete rfc3530bis (what are they?)
thread-index: AcrQ+u63s0+trbtxT2mBgBigZ3mxiwABKhXA
References: <20100330223502.GB21244@Sun.COM> <20100330224425.GA18810@fieldses.org> <20100330224913.GC21244@Sun.COM> <1269989661.10906.1.camel@localhost.localdomain> <20100330230250.GF21244@Sun.COM> <1269990565.10906.6.camel@localhost.localdomain> <20100330231828.GC4225@Sun.COM> <DB6FE7BD-6984-422B-920B-5411F00A7A01@gmail.com> <20100330232929.GD4225@Sun.COM> <C2D311A6F086424F99E385949ECFEBCB021F24B9@CORPUSMX80B.corp.emc.com> <20100331175032.GO4225@Sun.COM>
From: Black_David@emc.com
To: nfsv4@ietf.org
X-OriginalArrivalTime: 31 Mar 2010 18:41:01.0342 (UTC) FILETIME=[B6140BE0:01CAD101]
X-EMM-EM: Active
Cc: Black_David@emc.com
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: Wed, 31 Mar 2010 18:42:17 -0000

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