Nicolas Williams wrote:
> On Thu, May 31, 2007 at 10:45:04AM -1000, Joseph Kowalski wrote:
>> Garrett D'Amore wrote:
>>> Also, I find the reverse DNS naming scheme dissatisfying ... it makes
>>> everything quite a bit longer than it really needs to be to provide
>>> the separation of the namespace that is desired. It also ignores the
>>> bit that not everyone who wants to participate will have a DNS domain
>>> name, or that the domainname will not change over time. (E.g. due to
>>> mergers, buyouts, insolvency, or rebranding.)
>> True enough, but it is better than Stock Symbols (How much would a
>> domain name cost me? How much would a stock symbol cost me?) More
>> importantly, its the fairly widely accepted convention these days.
>>
>> My only point is that Solaris/OpenSolaris/Sun/whatever is special.
>> Somebody would have to be from another planet to step on SUNW.
>>
>> A discussion as to what the suggested form for others should be is a
>> separate discussion - not this case.
>
> IF RFC3530 had provided a light-weight registration procedure for the
> named attribute namespace, and IF we could treat that as authoritative
> for Solaris' extended attributes namespace, THEN there would be NO NEED
> for any prefix, though we might pick a very generic prefix, like
> "system." to help avoid conflicts with apps that use unregistered named
> attributes.
>
> BUT, NEITHER does RFC3530 provide such a light-weight registration
> procedure, NOR is it obvious that we could use its named attribute
> registry as authoritative for Solaris' extended attrs namespace: though
> fsattr(5) is quite unclear on that point, as it does reference RFC3530
> and says that NFSv4 named attrs and Solaris extended attrs are
> "equivalent," but then misrepresents what RFC3530 says about this
> namespace.
>
> (RFC3530 allows one to use any named attr name one wants but encourages
> folks to follow a very heavy-weight procedure for registering them!
> Guess how many app developers will bother to register their named attr
> names? What is the point of such a registry if noone will ever use it?)
>
> I think we do need an authoritative registry for this namespace, and its
> registration procedures ought to be exceedingly light-weight, else noone
> will register their named attr names. IANA is as good a registrar as
> any. I think advice to the IETF NFSv4 WG to loosen the registration
> procedures is in order.
>
> Advice to the i-team to register these attributes, even though the
> current process is painful, seems in order as well.
>
> *sigh*
>
> Nico
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.
In terms of NFS support for the system attributes contained in these files,
see section 4.1 of the spec:
4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work)
The NFSv4 protocol has an attribute model that supports extensions.
In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of
the "recommended" list of attributes for a client and server
implementation. The Solaris NFSv4 client and server could be
modified to support the new, optional attributes as specified by
the protocol.
This work is not currently funded.
Note that SYSTEM needs to be added to the list. (Thanks Spencer!)
Regarding the registration of named attributes, RFC3530 states:
"the intent is to promote interoperability where common interest exists".
But the team is not claiming interoperability with these two attribute
files. Interoperability would happen with the attributes stored WITHIN
these attribute files.
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.
Rich
