Subject: [nfsv4] rfc3530bis-28 draft - i18n material

From: "Black, David" <[email-masked]>
Date: Wed, 23 Oct 2013 10:56:53 -0400

With my name having been mentioned in connection with the i18n changes in
this draft, I took an initial look at the new i18n text in section 12 of
the -28 version.

While I need to look at the text more carefully, it looked reasonable on an
initial quick read, and I definitely support the "document the running code"
approach being taken.  FWIW, I've been here recently with another "document
the running code" draft that made backwards-incompatible changes to iSER in
order to match what was implemented and is being used (the story there is
somewhat analogous - there were some clever ideas added to the spec which
implementers roundly ignored)  FWIW, that draft has been approved by the
IESG and is in the RFC Editor's Queue:

	http://datatracker.ietf.org/doc/draft-ietf-storm-iser/

Something that I would suggest capturing in the 3530bis draft is the WG
discussion around software components that are beyond the IETF's control in
addition to the "running code" aspects of dealing with what's deployed and
actually in use (and mostly working, although perhaps not perfectly in
all possible cases).  My initial list of components (all of which deal with
Unicode in filenames in some fashion) is:

- Runtime library, including locale.  Some Unicode processing can only
	be done here.
- Client OS filesystem framework.  May impose requirements.
* NFS client
* NFS server
- Server OS filesystem framework.  May impose requirements..
- Server physical filesystem.  Definitely imposes requirements.

A couple of important (IMHO) things to point out are that (1) the IETF
specifies only the two *'d components, not the other four, and that (2)
physical filesystems do not have a standard way of dealing with Unicode.
For the latter, I think it's important to state that both NFC-based and
NFD-based physical filesystems are in use on NFS servers (with examples),
in addition to the draft's existing text that points out that the OS
filesystem frameworks may use different normalization forms (also seen
in actual NFS usage), in support of the conclusion that mandating a
single normalization form on the wire is untenable.  A useful example to
provide is that if a single NFS client is talking to multiple NFS
servers that use a mix of NFC and NFD, there's no single "right answer"
for the on-the-wire normalization form.

Beyond that, I don't know how far to go into Nico's discussion of
normalization insensitivity and normalization preservation as the only
possible way forward, but I think some of that rationale should be
included as rationale - Section 12.3 will need to grow, but I hope it
won't be necessary to explain everything that's been explored on the list.

Unfortunately, I cannot be in Vancouver for the nfsv4 WG meeting - due
to a conflicting standards meeting (T10 SCSI standards), I won't arrive
until late Tuesday evening.  I'll be in Vancouver all day Wed-Fri, so
perhaps we should set up a side meeting on 3530bis i18n for later in
the week?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 23 Oct 2013 12:32:58 -0400

Most of the things that you mention in your list are things that I thought were appropriate for the post-rfc3530bis internationalization document.  As I read your message, you feel that at least the list of components we don't control needs to be in a new version of rfc3530bis.

I don't feel that that's a problem, but including some of the other items would add a  lot of time/uncertainty/confusion that the document-things-as-implemented approach was intended to avoid.  Could you clarify where you intend to draw the line between rfc3530bis-xy and draft-ietf-nfsv4-i18n-someday-somehow-00 (that addresses all nfsv4 minor versions)?

Now as to your specific items:

Ø  For the latter, I think it's important to state that both NFC-based and NFD-based physical filesystems are in use on NFS servers (with examples),

I'm not even sure that is true and I certainly don't have examples.  Also, I don't think it adds anything to arguing the untenability of mandating a protocol-wide normalization form.  If filesystems that used both forms exist, and there were not normalization-unaware filesystems, you could translate between NFC and NFD, right above the filesystem layer, if necessary.  It is the presence of normalization-unaware filesystems and normalization-unaware users who don't like their filenames changed, in their view gratuitously, that makes a normalization form mandate untenable.

Ø  Beyond that, I don't know how far to go into Nico's discussion of normalization insensitivity and normalization preservation as the only possible way forward, but I think some of that rationale should be included as rationale - Section 12.3 will need to grow, but I hope it won't be necessary to explain everything that's been explored on the list.

I don't think we want to make the case that the only possible way forward, but that's up to the working group.  I assume that we will need to explain it as a possible way forward but that's in the context of a future document.  Right now, we simply say it is allowed because there is a server that does it and it interoperates with existing clients.  It's a "MAY" and you're free to think of it as a way forward or backward or sideways :)

Ø  so perhaps we should set up a side meeting on 3530bis i18n for later in the week?

Sounds good.  How about right after the précis meeting?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, October 23, 2013 10:57 AM
To: [email-masked]
Subject: [nfsv4] rfc3530bis-28 draft - i18n material

With my name having been mentioned in connection with the i18n changes in this draft, I took an initial look at the new i18n text in section 12 of the -28 version.

While I need to look at the text more carefully, it looked reasonable on an initial quick read, and I definitely support the "document the running code"

approach being taken.  FWIW, I've been here recently with another "document the running code" draft that made backwards-incompatible changes to iSER in order to match what was implemented and is being used (the story there is somewhat analogous - there were some clever ideas added to the spec which implementers roundly ignored)  FWIW, that draft has been approved by the IESG and is in the RFC Editor's Queue:

Something that I would suggest capturing in the 3530bis draft is the WG discussion around software components that are beyond the IETF's control in addition to the "running code" aspects of dealing with what's deployed and actually in use (and mostly working, although perhaps not perfectly in all possible cases).  My initial list of components (all of which deal with Unicode in filenames in some fashion) is:

                be done here.

* NFS client

* NFS server

A couple of important (IMHO) things to point out are that (1) the IETF specifies only the two *'d components, not the other four, and that (2) physical filesystems do not have a standard way of dealing with Unicode.

For the latter, I think it's important to state that both NFC-based and NFD-based physical filesystems are in use on NFS servers (with examples), in addition to the draft's existing text that points out that the OS filesystem frameworks may use different normalization forms (also seen in actual NFS usage), in support of the conclusion that mandating a single normalization form on the wire is untenable.  A useful example to provide is that if a single NFS client is talking to multiple NFS servers that use a mix of NFC and NFD, there's no single "right answer"

Beyond that, I don't know how far to go into Nico's discussion of normalization insensitivity and normalization preservation as the only possible way forward, but I think some of that rationale should be included as rationale - Section 12.3 will need to grow, but I hope it won't be necessary to explain everything that's been explored on the list.

Unfortunately, I cannot be in Vancouver for the nfsv4 WG meeting - due to a conflicting standards meeting (T10 SCSI standards), I won't arrive until late Tuesday evening.  I'll be in Vancouver all day Wed-Fri, so perhaps we should set up a side meeting on 3530bis i18n for later in the week?

Thanks,

--David

[email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754

_______________________________________________

nfsv4 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Black, David" <[email-masked]>
Date: Wed, 23 Oct 2013 17:58:54 -0400

Dave,

[David B] Inline ...

Thanks,
--David

From: Noveck, David
Sent: Wednesday, October 23, 2013 12:33 PM
To: Black, David; [email-masked]
Subject: RE: rfc3530bis-28 draft - i18n material

[David B] Yes, as I think that helps illuminate the "running code" situation that we have to deal with in this draft.

[David B] I think that the rfc3530bis draft should focus on NFSv4.0 as it is implemented and used today.  An important goal should be to provide guidance to an implementer of a new NFSv4.0 client or server on what to do (both MUST and SHOULD) to interoperate well with what's out there.  Other minor versions should be out of scope.

[David B] The latter may work.  I'm looking for a clear explanation for why mandating a single normalization form would be wrong with an example of something that breaks if that's attempted.  We are going to want to arm Martin Stiemerling and Pete Resnick with a clear explanation for why a protocol-specific profile of Unicode won't work for NFSv4.0, as that sort of approach is common in the IETF.

My concern is that while documenting "running code" is a fine approach, such a document could say that all the "running code" does something that SHOULD NOT be done.  So (IMHO) the overall goal here is to come up with an i18n approach that is a reasonable match to the state of the NFSv4.0 implementations (which do work) and avoid getting backed into a situation where we are forced to say that the i18n support in all the implementations is an example of something that SHOULD NOT be done ;-).

[David B] We're talking past each other, and it looks like I could have chosen my words better :-(.  What I was thinking is that normalization insensitivity and normalization preservation are useful concepts in providing the rationale for the i18n approach in this draft.  I had not meant to advocate that we adopt a specific n-i/n-p approach as required.  It isn't even necessary to use those exact words as long as the design rationale is clear.

[David B] Ok, that would involve skipping the Operations and Administration Plenary, or at least its first part, but let's plan on meeting then, at or outside the précis meeting room (Plaza A).

Thanks,

--David

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, October 23, 2013 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] rfc3530bis-28 draft - i18n material

                be done here.

* NFS client

* NFS server

Thanks,

--David

nfsv4 mailing list

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 29 Oct 2013 01:36:47 +0000

On Oct 23, 2013, at 2:58 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Dave,

[David B] Inline ...

Thanks,
--David

From: Noveck, David
Sent: Wednesday, October 23, 2013 12:33 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: RE: rfc3530bis-28 draft - i18n material

[David B] Yes, as I think that helps illuminate the “running code” situation that we have to deal with in this draft.

[David B] I think that the rfc3530bis draft should focus on NFSv4.0 as it is implemented and used today.  An important goal should be to provide guidance to an implementer of a new NFSv4.0 client or server on what to do (both MUST and SHOULD) to interoperate well with what’s out there.  Other minor versions should be out of scope.

Now as to your specific items:

>  For the latter, I think it's important to state that both NFC-based and NFD-based physical filesystems are in use on NFS servers (with examples),

I’m not even sure that is true and I certainly don’t have examples.  Also, I don’t think it adds anything to arguing the untenability of mandating a protocol-wide normalization form.  If filesystems that used both forms exist, and there were not normalization-unaware filesystems, you could translate between NFC and NFD, right above the filesystem layer, if necessary.  It is the presence of normalization-unaware filesystems and normalization-unaware users who don’t like their filenames changed, in their view gratuitously, that makes a normalization form mandate untenable.

[David B] The latter may work.  I’m looking for a clear explanation for why mandating a single normalization form would be wrong with an example of something that breaks if that’s attempted.  We are going to want to arm Martin Stiemerling and Pete Resnick with a clear explanation for why a protocol-specific profile of Unicode won’t work for NFSv4.0, as that sort of approach is common in the IETF.

My concern is that while documenting “running code” is a fine approach, such a document could say that all the “running code” does something that SHOULD NOT be done.  So (IMHO) the overall goal here is to come up with an i18n approach that is a reasonable match to the state of the NFSv4.0 implementations (which do work) and avoid getting backed into a situation where we are forced to say that the i18n support in all the implementations is an example of something that SHOULD NOT be done ;-).

>  Beyond that, I don't know how far to go into Nico's discussion of normalization insensitivity and normalization preservation as the only possible way forward, but I think some of that rationale sh…

I don’t think we want to make the case that the only possible way forward, but that’s up to the working group.  I assume that we will need to explain it as a possible way forward but that’s in the context of a future document.  Right now, we simply say it is allowed because there is a server that does it and it interoperates with existing clients.  It’s a “MAY” and you’re free to think of it as a way forward or backward or sideways :)

[David B] We’re talking past each other, and it looks like I could have chosen my words better :-(.  What I was thinking is that normalization insensitivity and normalization preservation are useful concepts in providing the rationale for the i18n approach in this draft.  I had not meant to advocate that we adopt a specific n-i/n-p approach as required.  It isn’t even necessary to use those exact words as long as the design rationale is clear.

>  so perhaps we should set up a side meeting on 3530bis i18n for later in the week?

[David B] Ok, that would involve skipping the Operations and Administration Plenary, or at least its first part, but let’s plan on meeting then, at or outside the précis meeting room (Plaza A).

So rather than drag in new business for the WG, is there any way we can do this meeting during the actual WG meeting?

I.e., can we close out old business before starting up new business?

Thanks,
--David

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, October 23, 2013 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] rfc3530bis-28 draft - i18n material

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Wed, 30 Oct 2013 18:41:07 -0400

[David B] Unfortunately, a conflict with the T10 SCSI standards meeting prevents me from being in Vancouver on Mon & Tue, so I will not be at the nfsv4 WG meeting.

Thanks,
--David

From: Haynes, Tom [mailto:[email-masked]]
Sent: Monday, October 28, 2013 9:37 PM
To: Black, David
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] rfc3530bis-28 draft - i18n material

Dave,

[David B] Inline ...

Thanks,
--David

From: Noveck, David

Thanks,
--David

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, October 23, 2013 10:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] rfc3530bis-28 draft - i18n material

Thanks,
--David

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Oct 2013 01:07:54 -0500

On Wed, Oct 23, 2013 at 10:56:53AM -0400, Black, David wrote:
>               [...].  My initial list of components (all of which deal with

Yes.  Moreover, the IETF can't impose constraints on the other
components, and the starred components don't have enough information.

This leaves few options available.  I've described some
(normalize-always, and form-insensitivity).  We could also do nothing.

Incidentally, the topic has come up in the HTTPbis WG and there people
talk about the service (e.g., WebDAV) normalizing, so there it's like
NFSv4: above the filesystem.  Normalizing above the filesystem means
only one option: normalize-always.

> NFD-based physical filesystems are in use on NFS servers (with examples),

There are no examples of NFC filesystems to my knowledge.  Only:

 - any form goes but accidentally ~ NFC
 - normalize to NFD
 - form-insensitive but accidentally ~ NFC

> single normalization form on the wire is untenable.  A useful example to

I wouldn't say that a single normalization form is untenable.
Normalize-always-to-NFC will interop quite well.

What's untenable is to demand Unicode: the components you starred don't
have 100% certainty about the charset/codeset used for any one filename
except by convention (e.g., because the admin made all users use UTF-8
locales).  At least form-insensitivity plays best with non-Unicode
content because it doesn't transform it, it only aliases it.

> for the on-the-wire normalization form.

True, if the server makes right then there's no point in talking about
form on the wire (or about what the client must do -- there's nothing
for it to do, since the server makes right).

> [...]

Normalize-always is an alternative.  Both have trade-offs.  Both are
legitimate in my view.

I *prefer* form-insensitivity because I think its trade-offs are better.

Perhaps the choice should be made by the admin and we should mandate
that they get this choice.  I don't see any other choices though:
neither the client can't make right (it'd have to READDIR to LOOKUP) nor
can we do nothing (well, we could but...).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Oct 2013 01:24:15 -0500

To offer something more concrete, we should:

 - Explain why it's difficult to ensure Unicode-only for filenames.

   Namely: the NFSv4 client and server are at layers where charset/
   codeset information about filenames is usually not available except
   by convention.

 - Explain that only the server can make Unicode form right because the
   alternative is that clients must implement LOOKUP (unacceptable:
   they'd have to always READDIR to LOOKUP) or that no component does
   anything at all about normalization.

   Further, there are two ways the server can make right:

    - normalize-always (any server, like NFSv4, FTP, SFTP, WebDAV, ...,
      can do this, and so can filesystems)

    - form-insensitivity (only *filesystems* can do this)

Then proceed to:

 - Say that filenames SHOULD be UTF-8 on the wire, not MUST.  (Servers
   SHOULD reject non-UTF-8 names by default.  Dunno what clients should
   do.)

 - Require that servers provide one or both of the server-makes-right
   options.

   I.e., "servers MUST implement one of these two" or "servers MUST
   implement normalize-always and MAY be configured to be
   form-insensitive instead".

One server-makes-right option could be REQUIRED to implement and the
other could be OPTIONAL.  But if only one server-makes-right option is
allowed at all then it has to be normalize-always (because that's the
only option that everyone can trivially implement), and the other option
would be effectively prohibited (or useless).

IMO we should not preclude either server-makes-right option.

Nico
--