[nfsv4] one more try at RFC3530 internationalization.

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

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?