From: wurzl, mario (wurzl_mario@emc.com)
Date: 02/01/05-01:30:28 PM Z
Message-ID: <FA2F59D0E55B4B4892EA076FF8704F5508C692BE@srgraham.eng.emc.com> From: "wurzl, mario" <wurzl_mario@emc.com> Subject: RE: [nfsv4] Minor Versioning. Date: Tue, 1 Feb 2005 14:30:28 -0500 > -----Original Message----- > From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] > On Behalf Of Trond Myklebust > Sent: Tuesday, February 01, 2005 1:47 PM > To: Robert Gordon > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Minor Versioning. > > må den 31.01.2005 Klokka 19:25 (-0600) skreiv Robert Gordon: > > > > Why is the existing NFS4ERR_NOTSUPP insufficient for > these purposes? > > > > The proposal allows for a succinct up-front mechanism to ascertain > > the operations supported by the server in one round-trip. One could > > also figure out the minor versions supported by the server if the > > supported operations in the reply was zero. > > > > I don't see how one could achieve the same with NFS4ERR_NOTSUPP, > > maybe i'm missing something.. > > The minor version is always known to the client, since it > supplies it as > an argument to COMPOUND. The server will return > NFS4ERR_MINOR_VERS_MISMATCH if it does not support that minor version. > > Beyond that, NFS4ERR_NOTSUPP is sufficient to ascertain which ops > actually have been implemented. In practice it makes little > sense for a > server to advertise a minor version if it does not actually implement > any of the features of that minor version, so we should be able to > assume that the number of unimplemented recommended features > will always > be small. > > Cheers, > Trond > -- > Trond Myklebust <trond.myklebust@fys.uio.no> Robert's proposal would allow a server to choose not to implement all the features of a minor release. Mario _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:52 AM Z CST