Hi-
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 server hostname, a port number, and the pathname in a single string. But both the hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL format employs a fixed pathname separator character.
That's what I would prefer. Think of file browsers which can open the NFS mount point just by clicking on it. Same encoding steps as with file URLs.
This seems the most obvious and natural solution (NFS URL). After all, you are specifying an NFS resource...
I've looked more closely at this idea. While it's got some surface appeal, 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 discussed.
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 server.
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.
Chuck Lever wrote:
On Aug 9, 2012, at 7:22 PM, Howard Chu wrote:
Michael Ströder wrote:
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 server.
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.
Why?
You could simply use the URL syntax defined in RFC 2224, section 1 (maybe redefine it in your own draft) and ignore the WebNFS-related rest of RFC 2224 if it does not fit your needs. Maybe some things from section 6 could be also considered. But personally I'm not familiar with NFS..
The exact semantics how to use the NFS URLs with NFSv4 should be defined in your NFSv4 drafts then.
Ciao, Michael.
On Aug 13, 2012, at 4:01 PM, Michael Ströder wrote:
Chuck Lever wrote:
On Aug 9, 2012, at 7:22 PM, Howard Chu wrote:
Michael Ströder wrote:
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 server.
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.
Why?
My impression is that may be required by the IETF citation rules. I could be wrong about that.
You could simply use the URL syntax defined in RFC 2224, section 1 (maybe redefine it in your own draft) and ignore the WebNFS-related rest of RFC 2224 if it does not fit your needs. Maybe some things from section 6 could be also considered. But personally I'm not familiar with NFS..
We can implement whatever we like (and in fact we did just that in the current NSDB schema). But there are certain constraints about what may be specified and referenced in a standards-track document.
The exact semantics how to use the NFS URLs with NFSv4 should be defined in your NFSv4 drafts then.
If we use NFS URLs, we would have to follow how the IETF prefers that we address the existing specification of an NFS URL. They may not care, in which case we could do exactly what you suggest.
Chuck Lever wrote:
On Aug 13, 2012, at 4:01 PM, Michael Ströder wrote:
Chuck Lever wrote:
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.
Why?
My impression is that may be required by the IETF citation rules. I could be wrong about that.
You could simply use the URL syntax defined in RFC 2224, section 1 (maybe redefine it in your own draft) and ignore the WebNFS-related rest of RFC 2224 if it does not fit your needs. Maybe some things from section 6 could be also considered. But personally I'm not familiar with NFS..
We can implement whatever we like (and in fact we did just that in the current NSDB schema). But there are certain constraints about what may be specified and referenced in a standards-track document.
IMHO it should be ok if you add a clear note about the non-relationship to WebNFS.
Maybe others with experience writing I-Ds and bringing them through the RFC process can comment on this.
Ciao, Michael.
openldap-technical@openldap.org
-
Chuck Lever -
Michael Ströder