On Aug 9, 2012, at 7:22 PM, Howard Chu wrote:
Michael Ströder wrote:
> Chuck Lever wrote:
>> On Aug 9, 2012, at 2:46 PM, Howard Chu wrote:
>>> Michael Ströder wrote:
>>>> Chuck Lever wrote:
>>>>> We could also use an NFS URL, which would allow us to express the
>>>>> hostname, a port number, and the pathname in a single string. But
>>>>> hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS
>>>>> format employs a fixed pathname separator character.
>>>> That's what I would prefer. Think of file browsers which can open the
>>>> mount point just by clicking on it. Same encoding steps as with file
>>> This seems the most obvious and natural solution (NFS URL). After all, you
>>> specifying an NFS resource...
>> I've looked more closely at this idea. While it's got some surface
>> NFS URLs (RFC 2224) don't specify a generic NFS resource. They specify a
>> webDAV like resource that can be accessed with NFS, called WebNFS (RFC
>> 2054, RFC 20550), which gives clients access via a so-called "public file
>> handle," which is a degenerate NFS FH.
>> WebNFS is defined only for legacy versions of NFS, not for NFSv4.
>> Referrals are supported only in NFSv4. In fact, section 4 of RFC 2224
>> specifies that clients try version 3 then version 2. NFS version 4 is not
>> Thus, the form of an NFS URL might be rich enough, but the existing
>> semantics are not equivalent.
> I see no reason why it should not be able to use NFS URLs and define the exact
> usage of them for NFSv4. Maybe I'm overlooking something though.
Agreed. AFAICS the semantics of the URL are for your actual application to
define. We're not talking about URLs that are meant to be served up by an HTTP
IMO RFC2224 is defective in that it specifies both the URL format and its
associated access methods. URL formats are meant to be "Uniform" which should
mean they are independent of their access methods.
In order to use the NFS URL format, I think we would be compelled to correct RFC 2224,
probably by issuing an RFC that supersedes it. While certainly possible, I'm not sure
the NFSv4 working group is prepared to hold up the NSDB draft for such an undertaking at
this point. Naturally there may be simpler alternatives.
That said, I can present this design choice (the use of an NFS URL to represent an
fs_locations entry in LDAP) to them for discussion.
Thanks for the excellent feedback.