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

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 15:30:45 -0400

On Fri, Sep 18, 2009 at 01:51:47PM -0400, Trond Myklebust wrote:
> There's the unimplemented-by-everybody mandatory UTF-8 formatting of
> filenames...

I also wonder what (if anything) people are doing about non-UTF-8 user
names.

(And also domain names: I'm assuming that they should be ascii (so in
the case of internationalized domain names, you should see punycode on
the wire, not non-ascii characters).  Is that right?)

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 14:48:06 -0500

> > There's the unimplemented-by-everybody mandatory UTF-8 formatting of

OpenSolaris and the Sun Storage 7xxx NAS appliance most certainly
support mandatory UTF-8 formatting of filenames.  They also support
turning that off, in case a customer really needs non-UTF-8.

> the wire, not non-ascii characters).  Is that right?)

IIRC it's all Unicode, all the time in NFSv4 on the wire for user, group
and domainnames in attributes (ACLs).  This came up recently in a FedFS
concall and someone asserted as much.

Nico
--

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 17:05:54 -0400

It's all UTF-8 on the wire for these, but if we use the Wikipedia
example for Punycode, if we want to have a domain which consists of the
German word for "books" (b u-umlaut cher) followed by ".com", I don't
see where RFC 3530 tells us whether it is encoded as:

     b\337\400cher.com

Or
   
     bcher.com-kva

Both are valid UTF8 unless I messed up and even if I did there is some
valid string corresponding to each of these approaches.

It sounds like there needs to be some guidance about which of these is
right.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nicolas Williams
Sent: Tuesday, March 30, 2010 3:48 PM
To: J. Bruce Fields
Cc: Tom Haynes; [email-masked]; Trond Myklebust
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)

Nico
-- 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 16:23:56 -0500

> It sounds like there needs to be some guidance about which of these is

RFC3530 does not refer to "domainname" nor "domainname slot", much less
to "IDN-aware domain name slot".  However, the last two paragraphs of
RFC3490, section 2, would seem to imply that RFC3530 domainname slots,
being intended to carry UTF-8, should probably be considered "IDN-aware
domain name slots", meaning they carry UTF-8, non-ACE domainname
labels.  But really, the NFSv4 base spec should say.

What servers could, and probably SHOULD do is be prepared to apply
ToUnicode() to any ACE labels sent by clients.  Clients also SHOULD
(MUST?) apply ToUnicode() to any ACE labels provided by client
applications.  Finally, in the worst case, clients should probably be
prepared to deal with servers that appear to be IDN-unaware.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 17:47:57 -0400

> It sounds like there needs to be some guidance about which of these is

Yes, exactly my question.

I'm assuming that the latter is what everyone actually handles.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 18:08:31 -0400

> prepared to deal with servers that appear to be IDN-unaware.

I'll go google for the jargon, but would it be possible for you to
rewrite the above without it?  (E.g. with reference to Dave's example
above?)

Note domain names are also used, for example, in referrals.

Does any current implementation use or expect non-ascii domain names on
the wire?

The linux referral implementation, for example, is by default passing
hostnames to /usr/bin/getent.  From my quick check:

	bfields@pig:linux-2.6$ getent hosts bücher.com
	bfields@pig:linux-2.6$ getent hosts xn--bcher-kva.com
	82.98.86.165    xn--bcher-kva.com

it seems to want the ascii name.

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 17:16:40 -0500

> rewrite the above without it?  (E.g. with reference to Dave's example

I probably couldn't explain the jargon better than the references that I
listed do.  If you're going to deal with IDN (Internationalized Domain
Names) then you have to be familiar with the relevant specs.

> Note domain names are also used, for example, in referrals.

Right.  Same deal.

> Does any current implementation use or expect non-ascii domain names on

I don't think ours does.  But I've not tested that.  (Also, we're
constrained to supporting only Active Directory domains and one ad-hoc
Unix domain.  I'm not sure what AD's support for IDN is nowadays.)

> it seems to want the ascii name.

getent(1) is clearly broken (in the context of RFC3490) in your system.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 17:19:09 -0500

> getent(1) is clearly broken (in the context of RFC3490) in your system.

Well, so is Solaris', and in exactly the same way :(

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 18:30:46 -0400

> Well, so is Solaris', and in exactly the same way :(

Just looking at the first couple paragraphs of the introduction to rfc
3490, this looks more-or-less like what's expected; applications that
want to deal in internationalized domain names can do the punycode
translation, but the basic infrastructure (under which I'd include
long-standing system interfaces and user commands like getent), isn't
expected to change.

OK, so at this point: I'll happily bet one (1) Arbor Brewing Company
pint (or equivalent), redeemable at the next testing event, to anyone
that can find an existing NFS implementation that expects non-ascii
domain-names on the wire.

Assuming that's the state of things, that's what the spec should say,
absent some overwhelming argument to the contrary....

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 17:29:12 -0500

> Names) then you have to be familiar with the relevant specs.

What the hey.  Very, very roughly:

 - a domainname slot is any place in any protocol where domainnames go;
 - an IDN-aware domainname slot is a domainname slot where you can put
   domainnames in their ToUnicode() form;
 - an IDN-unaware domainname slot is a domainname slot where you can
   only put ASCII, so you should apply ToASCII() to non-ASCII inputs
   before placing them here;
 - ToASCII() and ToUnicode() are functions that apply to individual
   domainname labels (the strings between periods) and which convert
   to/from ACE form (which uses punycode).

There's subleties.  For example, a single protocol element might carry
username@domain, as, in fact, we do in NFSv4, but only that part to the
right of the '@' is a domainname slot -- IDN does not tell you what to
do with the LHS.  There's rules for what components do what conversions.

Start with RFC3490.  Search the RFC DB for "IDN" and "IDNA" and
"Internationalized Domain Names".

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 17:35:02 -0500

> long-standing system interfaces and user commands like getent), isn't

It's more complex than that.  See the distinction between IDN-aware and
IDN-unaware domainname slots in protocols.

The question is: which kind is each of NFSv4's domainname slots?  I
believe the answer should be: all NFSv4 domainname slots are IDN-aware
ones.  That means that servers should expect UTF-8 and clients are
responsible for any and all ToASCII()/ToUnicode() applications.  But
it's possible that given current deployments we might have to conclude
that they are IDN-unaware slots -- unlikely, IMO, but possible.

> domain-names on the wire.

That's not what's interesting.  What's interesting whether there exist
server implementations that cannot handle domainnames with ACE-encoded
labels and there exist servers that cannot handle non-ASCII,
non-ACE-encoded, UTF-8 labels.  If you can find one of each then we've
got a problem.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 18:44:25 -0400

> IDN-unaware domainname slots in protocols.

My comment above was about the getent behavior.

> non-ACE-encoded, UTF-8 labels.  If you can find one of each then we've

If a server returns a client a non-ascii domainname as the target of a
referral, no current client will be able to use that referral.

Don't you agree that's worth documenting?

--b.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 17:49:13 -0500

> referral, no current client will be able to use that referral.

Only if the client doesn't know to apply ToASCII().  Any such clients
have a bug.  We could workaround that bug by declaring it to be a
server-side bug, but it's gonna be a bug for someone to fix anyways.  In
this case I'd rather say it's the client that's buggy.

> Don't you agree that's worth documenting?

I think we should document what clients and servers MUST/SHOULD/MAY do.
Going further to describe how things might break in the presence of
specific bugs may be useful, but not required.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Mar 2010 18:56:11 -0400

On Tue, Mar 30, 2010 at 05:49:13PM -0500, Nicolas Williams wrote:
> Only if the client doesn't know to apply ToASCII().

And that appears to describe every client.

> Any such clients have a bug.

We haven't yet determined that this is incorrect.

--b.

> We could workaround that bug by declaring it to be a

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Mar 2010 18:54:21 -0400

> this case I'd rather say it's the client that's buggy.

Why is that? AFAICR the whole point of punycode was to avoid ever
sending non-ascii domain names over the wire. It is up to browsers and
other user applications to call ToASCII()/ToUnicode() in order to
perform the cosmetic translation between the two.

Trond

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Mar 2010 19:02:22 -0400

> turning that off, in case a customer really needs non-UTF-8.

We will not ever support that in the Linux client whether or not
OpenSolaris servers try to enforce it.

Trond

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 18:02:51 -0500

> perform the cosmetic translation between the two.

Not quite.  There's IDN-aware and IDN-unaware domainname slots.
Pre-RFC3490 domainname slots are all IDN-unaware and may carry only
ASCII.  Post-RFC3490 domainname slots... must be specified as one or the
other.  RFC3530 didn't specify, so: which are they?

Perhaps by the logic of RFC3490 NFSv4's domainname slots are as if they
pre-dated RFC3490 and, therefore are IDN-unaware domainname slots.
However, I think we need an update to the spec (unless v4.1 clarifies
this), including an IETF Last Call, to resolve this.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 18:06:19 -0500

> > turning that off, in case a customer really needs non-UTF-8.

I should have mentioned that our implementations also support
normalization-insensitive-but-preserving file names.

> OpenSolaris servers try to enforce it.

Ok.  Can users work around this by using UTF-8 locales?  Is the problem
something to do with the complexity of normalization?  Politics?  (Our
implementation of kernel-mode normalization is surprisingly less complex
that one might have thought.)  What can we do to further the adoption of
UTF-8, or should we give up and tag strings in the protocol with
codesets?

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Mar 2010 19:09:25 -0400

> this), including an IETF Last Call, to resolve this.

AFAIK there is nothing in v4.1 to clarify either way. However since
RFC3530 is an update to RFC3010 (which is clearly pre-RFC3490) and it
does nothing to update the status of domain names, then I'd say we
should treat NFSv4 domain names as pre-RFC3490.

Trond

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Mar 2010 19:12:04 -0400

> UTF-8, or should we give up and tag strings in the protocol with

If applications specify UTF-8 filenames (which they should in the case
of a UTF-8 locale) then we dutifully pass that along to the NFS server.
However the kernel will not edit the filename string on its way down to
the filesystem. This is fully consistent with POSIX practice, which
states that all filename strings are valid as long as they do not
contain the characters '/' and '\0'.

Trond

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 18:16:51 -0500

> contain the characters '/' and '\0'.

That's also true for Solaris.  The NFSv4 server, however, can and does
reject non-UTF-8 path names (unless this behavior is disabled for the
containing filesystem).

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 18:18:29 -0500

> should treat NFSv4 domain names as pre-RFC3490.

To my knowledge RFC3010 was never implemented and deployed, and RFC3530
isn't an update to RFC3010: it obsoletes RFC3010.  So I don't think the
answer is all that clear cut.

Nico
--

---

From: Spencer <[email-masked]>
Date: Tue, 30 Mar 2010 18:22:43 -0500

> answer is all that clear cut.

Not sure if the semantic variance is important in this discussion
but RFC3530 does obsolete RFC3010.

Spencer

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 30 Mar 2010 18:29:29 -0500

> but RFC3530 does obsolete RFC3010.

Actual usage in practice will probably be more definitive.

The problem is that it isn't just clients that need to handle the IDN
issues, but also servers, since both will need to do things with
domainnames.

Clients need to resolve domainnames in referrals.  Clients and servers
both may also need to resolve domainnames in [ACE, owner, group]
subjects.  ADMIN servers will need to resolve domainnames as well.

Declaring the domainname slots in NFSv4 to be IDN-unaware doesn't really
solve any problems because in all cases IDN-unaware NFSv4
implementations will have to become aware regardless of whether the
slots themselves are IDN-aware or not.

We really should consider switching to using SIDs instead of
name@domain.  Eventually being able to deprecate name@domain in favor of
SIDs will eventually simplify server implementations greatly.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Mar 2010 20:36:38 -0400

> but RFC3530 does obsolete RFC3010.

However it offers no new guidance on this particular issue...

Trond

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 20:56:59 -0400

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

Thanks,
--David

Of Nicolas Williams
> Sent: Tuesday, March 30, 2010 7:29 PM
> To: Spencer
> Cc: J. Bruce Fields; [email-masked]; [email-masked]; Trond
Myklebust

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 12:45:36 -0400

> However it offers no new guidance on this particular issue... 

Instead, it takes some old guidance away :-(

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Trond Myklebust
Sent: Tuesday, March 30, 2010 8:37 PM
To: Spencer
Cc: J. Bruce Fields; [email-masked]; [email-masked]; Nicolas
Williams
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)

Trond

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 12:06:09 -0500

> Instead, it takes some old guidance away :-(

This is a fairly hard problem because there's a very large set of
domainname slots in the fairly large set of protocols that clients and
servers _both_ need to speak:

 - domainname slots in DNS (IDN-unaware; DNS servers need know nothing
   about IDN)

 - domainname slots in LDAP (e.g., for user/groupname@domain resolution)
   (IDN-aware? domainname -> naming context mapping is purely by
   convention or worse, you need to know a priori)

 - domainname slots in other name services?

 - domainname slots in the ADMIN protocol and in the NSDB (LDAP!)

 - domainname slots in NFSv4 itself

I think it's very likely that we can't avoid making the server be
IDN-aware because of LDAP.  If I'm wrong about that we could say all
NFSv4 domainname slotes are IDN-unaware and absolve the server of all
IDN responsibility.

One obvious thing to do is to say that you can put ACE-encoded and UTF-8
labels both in domainname slots in NFSv4, and clients and servers both
need to apply ToASCII() and ToUnicode() as necessary.

Nico
--

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 13:19:00 -0400

What does "as necessary" mean here if it applies to both clients and
servers?  In particular, if the receiver has to accept either, then it
is never necessary for the sender to translate.  So referrals can be in
either format and it is up to the receiver (in this case the client) to
translate if he needs to use it with some service that wants the
alternate format.

    Sender can send either.
    Up to Receiver to deal with it.

At least this is understandable.  I'm not sure if it stays workable once
those RFC's that David Black warned us about come out.   

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, March 31, 2010 1:06 PM
To: Noveck, David
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 12:30:09 -0500

On Wed, Mar 31, 2010 at 01:19:00PM -0400, [email-masked] wrote:
> servers?

As necessary for whatever other domainname slots in other protocols they
are copying a given domainname.

For example, on a SETATTR to change an ACL the server may need to
resolve some name@domain elements.  Doing so might mean doing DNS
lookups (ACE-encoded labels for non-ASCII domainname labels), and LDAP
lookups (which is... IDN-??aware?).  If LDAP is IDN-aware then the
server will have to have applied ToASCII() or ToUnicode(), thus we'd get
no simplification from saying that NFSv4 domainname slots are
IDN-unaware.  OTOH, if LDAP is IDN-unaware then we could simplify NFSv4
server implementations by declaring NFSv4 domainname slots to be
IDN-unaware.

We need to determine what is the best practice for mapping DNS
domainnames to LDAP naming context DNs.

>           In particular, if the receiver has to accept either, then it

Here the sender is the server.  But in the case of SETATTR the sender is
the client, which leads to: both have to "deal with it".

> those RFC's that David Black warned us about come out.   

Yes, something to absorb.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 12:50:32 -0500

> There are IDN changes coming (approved Internet-Drafts that are not yet

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

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 13:55:04 -0400

When you deal with other protocols, you have to conform to their
requirements.  If the protocols don't specify, you have to conform to
their implementations' requirements.  That's a given.

The question we're dealing with is different.

We have to determine what NFSV4 will require as far as this goes.  There
are 9 choices.

     U) The Unicode format is required for both the client 
   
     P) The Punycode format is required for both client and server.

     S) The sender can send either and the receiver must accept both.

     CU) The client can send either and the server must accept both.
         The server must send Unicode.

     CP) The client can send either and the server must accept both.
         The server must send Punycode.

     SU) The client must send Unicode format and the server must accept
it.
         The server can send either and client must accept both.

     SP) The client must send Punycode format and the server must accept
it.
         The server can send either and client must accept both.

     UP) The client must send Unicode format and the server must accept
it.
         The server must send Punycode format and the client must accept
it.

     PU) The client must send Punycode format and the server must accept
it.
         The server must send Unicode format and the client must accept
it. 
  
You can specify different choices for different places in the protocol
but I'll assert that that will lead to a nightmare.

Unless someone can think of a real strong reason for any of (CU), (CP),
(SU), (SP), (UP), or (PU), I'd say those are out.

We just need to pick one of (P), (U), or (S).   They all have some sort
of problems/inconveniences for various implementations.

I vote for (S).

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, March 31, 2010 1:30 PM
To: Noveck, David
Cc: [email-masked]; [email-masked];

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 13:06:16 -0500

> their implementations' requirements.  That's a given.

Correct.

> The question we're dealing with is different.

Indeed, but if all of those other protocols are IDN-unaware then we can
make NFSv4's domainname slots IDN-unaware and then NFSv4 servers need
not implement any part of IDNA.

Thus what other protocols are used seems relevant.  Of course, the
"other protocols" set is open.

>      S) The sender can send either and the receiver must accept both.

However, the server has to understand that [email-masked] and
[email-masked] compare as equal.

>      [...]

Yes.

> (SU), (SP), (UP), or (PU), I'd say those are out.

Agreed.

> of problems/inconveniences for various implementations.

Me too.  That's another way of saying that NFSv4 domainname slots should
be IDN-aware.  (IDN-aware slots accept A-labels and U-labels both.)

Nico
--

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 14:41:00 -0400

Nico,

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

> 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

> Sent: Wednesday, March 31, 2010 1:51 PM
> To: Black, David
> Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
> [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 14:08:52 -0500

On Wed, Mar 31, 2010 at 02:41:00PM -0400, [email-masked] wrote:
> > 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.
> 

None of those changes is relevant to the issue at hand (whether NFSv4's
domainname slots are IDN-aware).

> negative language on this topic if asked ;-).

Newprep discussions I've been a part of (I didn't attend the BoF because
I wasn't at Anaheim) involved likely accepting normalization-
insensitive/preserving behavior.  Our (Sun's, now Oracle's) experience
with Unicode and NFSv4 indicates that, indeed, n-i/p is the best
approach to Unicode normalization issues.  Indeed, I think n-i/p is the
only way to properly live with the RFC3530 nfs4_cs_prep.  I would extend
this to the user/group name component of name@domain, but not for the
domain component (since IDNA applies there).  Normalization insensitive
string comparison (and NFSv4 LOOKUPs) is an idea whose time has come.

Also, RFC3530's nfs4_cis_prep and utf8str_mixed need to be updated to
indicate that IDNA applies wherever nfs4_cis_prep/utf8str_mixed apply to
domainnames.

Nico
--

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 15:30:11 -0400

> It's also the situation that

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: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, March 31, 2010 2:41 PM
To: [email-masked]
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

Thanks,
--David

> IDNAbis doesn't radically change IDNA, at least not in ways that
matter

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 16:12:43 -0400

Dave,

> 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

> From: Noveck, David
> Sent: Wednesday, March 31, 2010 3:30 PM
> To: Black, David; [email-masked]
> Cc: Black, David
> Subject: RE: [nfsv4] work items to complete rfc3530bis (what are
they?)
> 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"?
> 
Of [email-masked]
> > > There are IDN changes coming (approved Internet-Drafts that are
not
> yet

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 15:39:57 -0500

> with some German strings.

Correct, but even better: NFSv4 never dealt correctly with IDNA, thus we
have to do this anyways.  The problem isn't the stringpreps that NFSv4
uses, but the fact that what RFC3530 says was in conflict with IDNA even
before IDNAbis.  IDNAbis is not causing us extra work.

Nico
--