I just got off the phone with Nico. Turns out we're in violent agreement.
I thought he was talking about exposing the system extended attribute files
(SUNWattr_rw, SUNWattr_ro). But Nico was talking about the individual
attributes (CREATETIME, SYSTEM, HIDDEN, etc., etc.).
We've agreed that a future project should add the new attributes to
the Solaris client and server as the NFSv4 protocol allows. This is
briefly described in section 4.3.1 of the spec for this case.
We also agree that the work in described in sectin 4.3.1 is outside
the scope of this project.
Sorry for the confusion. Thanks.
Rich
Nicolas.Williams at Sun.COM wrote:
> 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
