Subject: [nfsv4] draft-ietf-nfsv4-rfc3530bis-28.txt editorial feedback

From: Mike Kupfer <[email-masked]>
Date: Mon, 11 Nov 2013 15:30:10 -0800

Section 12.1: "nlot" -> "not"

Section 12.2:

       Use of non-UTF-8
       encodings can be problematic since it may interfere with access to
       files stored using encoding

   Should that be "files stored using UTF-8 encoding"?

Section 12.2:

       and because normalization-related
       processing (see Section 12.3) would result in name aliasing in the
       case of a non-UTF-8 encoding resulted characters strings that have
       multiple equivalent Unicode encodings.

   How about

       Also, normalization-related processing (see Section 12.3) of a
       string that was not encoded as UTF-8 could result in name
       aliasing.

Section 12.5:

     Requirements for server handling of component names which are not
     valid UTF-8, when a server does not return NFS4ERR_INVAL in response
     to receiving these are described in Section 12.6.

   Change "receiving these are" to "receiving them, are".

     (e.g., names containing slashes or characters
     that have more than two octets on a filesystem that supports Unicode

   Add a comma after "slashes".

Section 12.6:

     o Characters which are not valid UTF-8, have no canonically
       equivalent Unicode string so normalization-related processing
       cannot happen.

   Move the comma after "UTF-8", so that it comes after "string".

best regards,
mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 27 Nov 2013 17:48:28 +0000

Thanks!

> Section 12.1: "nlot" -> "not"

fixed

>  Should that be "files stored using UTF-8 encoding"?

Agreed

>      string that was not encoded as UTF-8 could result in name

Dave, thoughts here?

>  Change "receiving these are" to "receiving them, are".

Agreed

>  Add a comma after "slashes".

ack

>  Move the comma after "UTF-8", so that it comes after "string".

agreed

> 
> best regards,
> mike
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 28 Nov 2013 09:29:24 -0500

>  Dave, thoughts here?

How about rewriting the paragraph as follows:

      In many cases, clients have no knowledge of the encoding being
      used, with the encoding done at user-level under control of a per-
      process locale specification.  As a result, it may be impossible
      for the NFSv4 client to enforce use of UTF-8.  Use of non-UTF-8
      encodings can be problematic since it may interfere with access to
      files stored using other forms of name encoding .  Also, normalization-
      related processing (see Section 12.3)  of a string  not encoded in UTF-8 
      could result in inappropriate name modification or aliasing.  In cases in 
      which one has a  non-UT8-name that accidentally conforms to UTF-8 rules, 
      substitution of canonically equivalent strings  can change the non-UTF-8 
      encoded name drastically 

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Wednesday, November 27, 2013 12:48 PM
To: Mike Kupfer; Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] draft-ietf-nfsv4-rfc3530bis-28.txt editorial feedback

Thanks!

fixed

Agreed

Dave, thoughts here?

Agreed

ack

agreed

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 28 Nov 2013 18:09:10 +0000

Okay, the latest draft (-29) has all of the changes known to me for i18n, including this one.