[nfsv4] rfc3530bis-28 draft - i18n material

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

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]        Mobile: [phone]
----------------------------------------------------