Re: [nfsv4] one more try at RFC3530 internationalization.

Thanks for taking this one, David.

For the rest of the WG, a big part of this, as David outlines, is based on understanding what the current implementations have built/deployed.  In support of that, it would be a big help if you would send David a direct email with the choices made in your implementation with regards to i18n.

Spencer

-----Original Message-----
From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of Noveck, David
Sent: Wednesday, August 7, 2013 12:40 PM
To: nfsv4 list (nfsv4@ietf.org)
Subject: [nfsv4] one more try at RFC3530 internationalization.

I've been working with Tom Haynes and David Black to come with an approach to internationalization for RFC3530bis, that meets the IESG's objections and has a good chance of being approved. 

The approach to be taken is basically to get an internationalization description that matches what people have implemented.  I think it is pretty clear that does not match the stringprep-based approach taken in RFC3530, although we may have some issues proving that fact to the IESG, or more properly, giving Martin the information he needs to prove it to the IESG.

The internationalization approach in the curent RF3530bis draft,
draft-ietf-nfsv4-rfc3530bis-26 attempted to make the stringprep stuff non-normtive nd loosen it nough tht current implentations fit withiin it.  unfortunately, the IESG ididn't like it, so we need something else.

The proposed approach is to base the new RFC3530bis handling of internationalization on the internationlization tretament in draft-ietf-nfsv4-rfc3010bis-04, the last draft for rfc3530 before it was stringprep-ized.  I feel that this is simple enough that we can clearly make the case, with the implementer's help, that this is what current servers and clients do and getting RFC3530bis approved.

The rest of this mail surveys the intrnationalization-related changes that are proposed to follow through on this approach.

As mentioned we are starting with Chapter 11 of
draft-ietf-nfsv4-rfc3010bis-04 and making the following changes:

  o  Added an introductory section explaining that this is description 
     of current implementations, even though the words 
     MUST/SHOULD/MAY/should are used to guide future implementations.
  o  Deleted the sections containing a discussion of encoding 
     alternatives and put in simple statement that a UTF-8 encoding of 
     Unicode is to be used.
  o  Added a section distinguishing how different sorts of strings are 
     handled.
  o  In the normalization section changed "A later revision of this 
     specification may specify a particular normalization form" to 
     "A subsequent minor version of the NFSv4 protocol might specify 
     a particular normalization form."
  o  Added in a new section derived from section 12.6 of rfc3530bis.
  o  Added a new paragraph saying what server MAY and MAY NOT do 
     regarding normalization.
  o  In the error discussion replaced a "should" by "SHOULD".  This is 
     not primarily to strengthen the requirement, although that is the 
     effect.  It is mainly to make it clear that some servers will not 
     be doing it.  There are also other changes in that section to tie 
     in with that. 

There are another set of changes to undo the changes to the XDR to define more precisely what the utf-8 attributes of various sorts of strings are.  Basically we are leaving ascii_REQUIRED4 in and changing all instances of the new utf* types back to utf8string.  This includes changes to draft-ietf-nfsv4-rfc3530bis-dox-x  plus the following changes to draft-ietf-nfsv4-rfc3530bis outside the internationalization chapter.

  o  Deleting the definitions of these types in section 2.1.  Also the 
     uses of these types in this section.
  o  Adjust the definition in 2.2.6 (of fs_location4). Also another 
     occurrence of the same in 7.9)
  o  Fixing a similar definition in 6.2.1. (of nfs4ace4).

Any comments before we go ahead with a new draft based on this approach?

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4