Subject: Update from Nov '01 to July '02 -- How bad is it?

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 3 Jul 2002 09:38:22 -0700

This is mainly for bakeoff participants but others may find it
interesting as well.

The short answer is "Not bad at all".

I diff'ed the .x files from the Nov-01 and July-02 specs to see
what is involved in updating clients and servers supporting the
Nov-01 protocol, which had been used at recent bakeoffs and
connectathons, to the July-02 protocol that we will be using at
the forthcoming Ann Arbor bakeoff.  This only covers the obvious
stuff exposed in the .x file and one other thing where I wrote the
modified section.  Subtle changes in semantics are not addressed, 
but I don't know of any that would affect people (i.e. there are 
no obvious subtleties :-).  I've listed things in order of 
decreasing importance, from "fix this or you won't inter-operate" 
to "if you don't fix this, you might not be behaving correctly 
under some circumstances".

Addition of callback_ident to SETCLIENTID and callbacks.

     This is the one change that everybody absolutely must make or
     nothing will work right.

New OP, OP_RELEASE_LOCKOWNER added replacing the RELEASE_STATE
case for LOCK.
    
     Clients which don't use RELEASE_STATE don't need to do anything.
     Servers need to accept the new OP and reject RELEASE_STATE with
     an error (not sure if a non-specified value in an enum is 
     NFS4ERR_INVAL or NFS4ERR_BADXDR.  Does anybody know for sure?).

New error NFS4ERR_BADOWNER added.

     Servers which don't support all possible values of OWNER and 
     OWNER_GROUP (most or all of them), need to reject invalid values
     on a SETATTR with this value, although the previous thing of 
     treating this as nobody is not going cause anybody to crash.
     Clients need to be prepared for this error.

Numeric owners and groups.

     Servers should accept these if it is appropriate (and because of
     v2/v3 interoperability, it is for most).  Unix clients should
     probably also send these if they have no mapping for a userid.

New error, NFS4ERR_OPENMODE added.

     Servers need to check READ, WRITE, SETATTR (truncate) for the
     open mode being appropriate (If you don't almost everything will
     still work).  Clients just have to be prepared for a surprise if
     they have been doing something they shouldn't.

Addition of OPEN4_RESULT_LOCKTYPE_POSIX to open result.

     Servers should set this appropriately but probably can get by with
     returning zero as was done in previous protocol revs.  Clients don't 
     have to look at it.  If clients do look at it, the very few programs
     that actually use the weird POSIX locking semantics may be affected.

Owners and client identification strings now limited to 1024 bytes. 

     Servers should check for this, but nobody (except Peter Astrand's
     test programs) will care if you don't.  Clients should be OK, unless
     they have been sending strings over the limit, in which case they're
     probably beyond hope anyway.

Spelling of error changed from NFS4ERR_ACCES to NFS4ERR_ACCESS.

     Client and server writers need to gather in the evening for refreshments
     and to debate this important issue.  Participants must offer impassioned
     arguments for or against this break with tradition.  Other participants
     will vote on debate and allocate cost of refreshments according to
     results.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 14:16:47 -0500

>      NFS4ERR_INVAL or NFS4ERR_BADXDR.  Does anybody know for sure?).

NFS4ERR_INVAL is most appropriate.

Spencer