From: Mike Eisler (mre@jurassic.eng.sun.com)
Date: 03/24/97-12:14:16 PM Z
Date: Mon, 24 Mar 1997 10:14:16 -0800 (PST) From: Mike Eisler <mre@jurassic.eng.sun.com> Subject: Re: Attributes Message-ID: <Roam 0.9.4.859227256.9226.mre@jurassic.eng.sun.com> > > So we might have: > > > > - Protocol defined attributes. > > > > An enumerated set of attributes with clearly defined semantics. > > The set be extensible via standards-track RFCs and registered > > with IANA. Adding attributes via standards-track RFCs and IANA seems redundant. I prefer just the standards-track RFC approach and associated each successive RFC with a new NFS V4 minor version #. > > - Application defined attributes. > > > > Name/value pairs. Supported by the protocol but names > > and values are opaque. > > > > I agree with most of this but I don't think Names should be opaque. I > prefer the method used for numbering RPC programs. Range x-y is for > registered attributes. Range 1000000+x - 1000000+y is for client > unofficial attributes. The value in using string names for the uncontrolled attribute name space is that client applications that don't understand the named attributes can at least display them to a human user who may understand the attribute because its got an obvious name. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:38 AM Z CST