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