Subject: VERIFY/NVERIFY issue

From: [email-masked]
Date: Thu, 22 Jun 2000 09:32:54 -0700

Spencer's mail about coding to draft-07 for the bakeoff
forced me to look at my code for VERIFY and NVERIFY, 
which I hadn't done in a while.  It turns out that I
supported drafts 6 and 7 equally, with the same results,
panic("NYI") whether you sent the extra mask or not 

Anyway, finally coding this up, I came up with the 
following issue: What should you do if the attributes
sent by the caller includes ones the server doesn't 
support?  One obvious answer is to treat this as a 
mismatch using the theory that an unsupported attribute
is different for any value for a supported one.  The
trouble is that this means that an NVERIFY will succeed
in this case, while my inclination is that this should
be an error, just as it would be an error, I assume
to use an undefined attribute bit or an attribute bit
for an attribute bit that can only be set.

Anyway, I'm now returning INVAL in this case.  Are there
different behaviors in other implementations or opinions
on what the right thing to do is?

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 22 Jun 2000 11:46:50 -0500

> on what the right thing to do is?

Both NVERIFY/VERIFY have statements in the IMPLEMENTATION
section stating that if a recommended attribute is supplied
by the client and it is not supported by the server that
the error NFS4ERR_NOTSUPP should be returned.

Spencer