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

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

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

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

[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:[e-mail]]
Sent: Monday, October 28, 2013 9:37 PM
To: Black, David
Cc: Noveck, David; [e-mail]
Subject: Re: [nfsv4] rfc3530bis-28 draft - i18n material


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


Dave,

[David B] Inline ...

Thanks,
--David

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

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.

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

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

[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 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 :)

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

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

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

_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4