Rich Brown wrote:
> The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended
> to be used as NFS named attributes directly.  The format of these files
> are nvpairs of the system attributes.  I wouldn't expect all NFS clients
> and servers to recognize Solaris' nvpair format.

I would expect a future project to make these attributes visible through 
NFSv4 to make each attribute visible as a separate named attribute, not 
all of them in one file with nvlist format.  But then, perhaps we'd 
pursue different extensions to NFSv4 for this anyways.

> Regarding the registration of named attributes, RFC3530 states:
> "the intent is to promote interoperability where common interest exists".

But surely also there is a namespace collision avoidance rationale.  In 
the case of applications there is no problem since presumably two (or 
more) different apps using conflicting attribute names wouldn't share 
the same files.  While in the case of the operating system as the 
application we could expect every file to have these attributes, so the 
namespace conflict avoidance issue matters.

I suspect that the NFSv4 WG only intended for imlementors of clients and 
servers that rely on special named attributes to register them, whereas 
application developers wouldn't have to.  Whatever.  The WG chose a 
method too difficult to use, so we shan't (and if anyone insisted I'd 
suggest simply not allowing these SUNW attrs to be visible via NFSv4).

> But the team is not claiming interoperability with these two attribute
> files.  Interoperability would happen with the attributes stored WITHIN
> these attribute files.

No, the team isn't claiming interop, but folks outside Sun might like to 
support these attributes -- I believe that's what the RFC wants us to 
facilitate.

> Registering these attribute files with the IANA means that the project
> team would have to publish an informational RFC to state the name of the
> attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and
> semantics of the named attribute contents.  Any new attributes added
> to these files would require project teams to submit updates to the RFC.
> As Nico said, this is "a very heavy-weight procedure".
> 
> Given that, I don't see the value for Sun in registering the system
> attribute files as named attributes for NFS through the IANA.
> I see it as a high cost for no gain.  Not that we think that anyone
> is going to use SUNWattr_* (or whatever we decide on) but the IANA
> registration doesn't even claim to prevent name collisions.

Really?  No NFSv4 client implementor would see any value in 
understanding and supporting the use of these attributes?  I somehow 
doubt that.

Nico
-- 

Reply via email to