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

["Noveck, David" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Black, David
Sent: Wednesday, October 23, 2013 10:57 AM
To: [e-mail]
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:



                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

[phone]             FAX: [phone]

[e-mail]<mailto:[e-mail]>        Mobile: [phone]

----------------------------------------------------

_______________________________________________

nfsv4 mailing list

[e-mail]<mailto:[e-mail]>

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