rfc2224.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 620 行 · 第 1/2 页

   filehandle, then the client should attempt to resolve the <url-path>
   to a filehandle using the MOUNT protocol.

   Version 1 of the MOUNT protocol is described in Appendix A of RFC
   1094 and version 3 in Appendix I of RFC 1813. Version 2 of the MOUNT
   protocol is identical to version 1 except for the addition of a
   procedure MOUNTPROC_PATHCONF which returns POSIX pathconf information
   from the server.

   Note that the pathname sent to the server in the MOUNTPROC_MNT
   request is assumed to be a server native path, rather than a slash-
   separated path described by RFC 1738.  Hence, the MOUNT protocol can
   reasonably be expected to map a <url-path> to a filehandle only on
   servers that support slash-separated ASCII native paths.  In general,
   servers that do not support WebNFS access or slash-separated ASCII
   native paths should not advertise NFS URLs.

   At this point the client must already have some indication as to
   which version of the NFS protocol is supported on the server.  Since
   the filehandle format differs between NFS versions 2 and 3, the
   client must select the appropriate version of the MOUNT protocol.
   MOUNT versions 1 and 2 return only NFS version 2 filehandles, whereas
   MOUNT version 3 returns NFS version 3 filehandles.




Callaghan                    Informational                      [Page 6]

RFC 2224                     NFS URL Scheme                 October 1997


   Unlike the NFS service, the MOUNT service is not registered on a
   well-known port.  The client must use the PORTMAP service to locate
   the server's MOUNT port before it can transmit a MOUNTPROC_MNT
   request to retrieve the filehandle corresponding to the requested
   path.

       Client                                       Server
       ------                                       ------

       -------------- MOUNT port ? -------------->  Portmapper
       <-------------- Port=984 ------------------

       ------- Filehandle for /export/foo ?  ---->  Mountd @ port 984
       <--------- Filehandle=0xf82455ce0..  ------

   NFS servers commonly use a client's successful MOUNTPROC_MNT request
   request as an indication that the client has "mounted" the filesystem
   and may maintain this information in a file that lists the
   filesystems that clients currently have mounted.  This information is
   removed from the file when the client transmits an MOUNTPROC_UMNT
   request.  Upon receiving a successful reply to a MOUNTPROC_MNT
   request, a WebNFS client should send a MOUNTPROC_UMNT request to
   prevent an accumulation of "mounted" records on the server.

8.0 Bibliography

   [RFC1738]       Berners-Lee, T., Masinter, L. and M. McCahill,
                   "Uniform Resource Locators (URL)," RFC 1738,
                   December 1994.

   [RFC1808]       Fielding, R., "Relative Uniform Resource Locators,"
                   RFC 1808, June 1995.

   [RFC1831]       Srinivasan, R., "RPC: Remote Procedure Call
                   Protocol Specification Version 2," RFC 1831,
                   August 1995.

   [RFC1832]       Srinivasan, R., "XDR: External Data Representation
                   Standard," RFC 1832, August 1995.

   [RFC1833]       Srinivasan, R., "Binding Protocols for ONC RPC
                   Version 2," RFC 1833, August 1995.

   [RFC1094]       Sun Microsystems, Inc., "Network Filesystem
                   Specification," RFC 1094, March 1989.






Callaghan                    Informational                      [Page 7]

RFC 2224                     NFS URL Scheme                 October 1997


   [RFC1813]       Callaghan, B., Pawlowski, B. and P. Staubach,
                   "NFS Version 3 Protocol Specification," RFC 1813,
                   June 1995.

   [RFC2054]       Callaghan, B., "WebNFS Client Specification,"
                   RFC 2054, October 1996.

   [RFC2055]       Callaghan, B., "WebNFS Server Specification,"
                   RFC 2055, October 1996.

   [Sandberg]      Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh,
                   B.  Lyon, "Design and Implementation of the Sun
                   Network Filesystem," USENIX Conference
                   Proceedings, USENIX Association, Berkeley, CA,
                   Summer 1985.  The basic paper describing the
                   SunOS implementation of the NFS version 2
                   protocol, and discusses the goals, protocol
                   specification and trade-offs.

   [X/OpenNFS]     X/Open Company, Ltd., X/Open CAE Specification:
                   Protocols for X/Open Internetworking: XNFS,
                   X/Open Company, Ltd., Apex Plaza, Forbury Road,
                   Reading Berkshire, RG1 1AX, United Kingdom,
                   1991.  This is an indispensable reference for
                   the NFS and accompanying protocols, including
                   the Lock Manager and the Portmapper.

   [X/OpenPCNFS]   X/Open Company, Ltd., X/Open CAE Specification:
                   Protocols for X/Open Internetworking: (PC)NFS,
                   Developer's Specification, X/Open Company, Ltd.,
                   Apex Plaza, Forbury Road, Reading Berkshire, RG1
                   1AX, United Kingdom, 1991.  This is an
                   indispensable reference for NFS protocol and
                   accompanying protocols, including the Lock Manager
                   and the Portmapper.

9. Security Considerations

   Since the WebNFS server features are based on NFS protocol versions 2
   and 3, the RPC based security considerations described in RFC 1094,
   RFC 1831, and RFC 1832 apply here also.

   Server implementors should be careful when implementing multi-
   component lookup that the client cannot obtain unauthorized access to
   files or directories. For example: a path that includes multiple
   occurrences of "../" may locate a filesystem outside of the exported
   filesystem associated with the public filehandle.




Callaghan                    Informational                      [Page 8]

RFC 2224                     NFS URL Scheme                 October 1997


   Clients and servers may separately negotiate secure connection
   schemes for authentication, data integrity, and privacy.

10. BNF for NFS URL Scheme

   The syntax of the NFS URL is a subset of the Generic URL syntax
   described in RFC 1738.  An NFS URL does not include user or password
   components, nor does it recognize "?" query or "#" fragment
   components.
      nfsURL        = "nfs" ":" relativeURL
      relativeURL   = net_path | abs_path | rel_path
      net_path      = "//" hostport [ abs_path ]
      abs_path      = "/"  rel_path
      rel_path      = [ path_segments ]

      hostport      = host [ ":" port ]
      host          = hostname | hostnumber
      hostname      = *( domainlabel "." ) toplabel
      domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
      toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
      hostnumber    = 1*digit "." 1*digit "." 1*digit "." 1*digit
      port          = *digit

      url-path      = [ "/" ] path_segments
      path_segments = segment *( "/" segment )
      segment       = *pchar
      pchar         = unreserved | escaped | ":" | "@" | "&" | "=" | "+"

      reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
      unreserved    = alpha | digit | mark
      mark          = "$" | "-" | "_" | "." | "!" | "~" |
                      "*" | "'" | "(" | ")" | ","

      escaped       = "%" hex hex
      hex           = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                              "a" | "b" | "c" | "d" | "e" | "f"

      alphanum      = alpha | digit
      alpha         = lowalpha | upalpha

      lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
                 "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
                 "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
      upalpha  = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
                 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
                 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
      digit    = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                 "8" | "9"



Callaghan                    Informational                      [Page 9]

RFC 2224                     NFS URL Scheme                 October 1997


11. Acknowledgements

   This specification was extensively reviewed by the NFS group at
   SunSoft and brainstormed by Michael Eisler.

12. Author's Address

   Address comments related to this RFC to:

      [e-mail]


   Brent Callaghan
   Sun Microsystems, Inc.
   Mailstop Mpk17-201,
   901 San Antonio Road,
   Palo Alto, California 94303

   Phone: [phone]
   EMail: [e-mail]
   Fax:   [phone]






























Callaghan                    Informational                     [Page 10]

RFC 2224                     NFS URL Scheme                 October 1997


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   andand distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
























Callaghan                    Informational                     [Page 11]