home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2224 < prev    next >
Text File  |  1997-10-17  |  23KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        B. Callaghan
  8. Request for Comments: 2224                         Sun Microsystems, Inc.
  9. Category: Informational                                      October 1997
  10.  
  11.                              NFS URL Scheme
  12.  
  13. Status of this Memo
  14.  
  15.    This memo provides information for the Internet community.  It does
  16.    not specify an Internet standard of any kind.  Distribution of this
  17.    memo is unlimited.
  18.  
  19. Copyright Notice
  20.  
  21.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  22.  
  23. Abstract
  24.  
  25.    A new URL scheme, 'nfs' is defined.  It is used to refer to files and
  26.    directories on NFS servers using the general URL syntax defined in
  27.    RFC 1738, "Uniform Resource Locators (URL)".
  28.  
  29.    This scheme uses the public filehandle and multi-component lookup
  30.    [RFC2054, RFC2055] to access server data with a minimum of protocol
  31.    overhead.
  32.  
  33.    The NFS protocol provides access to shared filesystems across
  34.    networks.  It is designed to be machine, operating system, network
  35.    architecture, and transport protocol independent.  The protocol
  36.    currently exists in two versions: version 2 [RFC1094] and version 3
  37.    [RFC1813], both built on ONC RPC [RFC1831] at its associated eXternal
  38.    Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].
  39.  
  40. Table of Contents
  41.  
  42.       1.    URL Syntax . . . . . . . . . . . . . . . . . . . . . . .  2
  43.       2.    URL Evaluation . . . . . . . . . . . . . . . . . . . . .  2
  44.       3.    Server Connection  . . . . . . . . . . . . . . . . . . .  2
  45.       4.    NFS Version  . . . . . . . . . . . . . . . . . . . . . .  2
  46.       5.    Public Filehandle  . . . . . . . . . . . . . . . . . . .  3
  47.       5.1     NFS Version 2 Public Filehandle  . . . . . . . . . . .  3
  48.       5.2     NFS Version 3 Public Filehandle  . . . . . . . . . . .  3
  49.       6.    Multi-component Lookup . . . . . . . . . . . . . . . . .  3
  50.       6.1     Absolute vs Relative Pathname  . . . . . . . . . . . .  4
  51.       6.2     Symbolic Links . . . . . . . . . . . . . . . . . . . .  5
  52.       7.    Mount Protocol . . . . . . . . . . . . . . . . . . . . .  6
  53.       8.    Bibliography . . . . . . . . . . . . . . . . . . . . . .  7
  54.       9.    Security Considerations  . . . . . . . . . . . . . . . .  8
  55.  
  56.  
  57.  
  58. Callaghan                    Informational                      [Page 1]
  59.  
  60. RFC 2224                     NFS URL Scheme                 October 1997
  61.  
  62.  
  63.       10.   BNF for NFS URL Scheme . . . . . . . . . . . . . . . . .  9
  64.       11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
  65.       12.   Author's Address . . . . . . . . . . . . . . . . . . . . 10
  66.       13.   Full Copyright Statement . . . . . . . . . . . . . . . . 11
  67.  
  68. 1. URL Syntax
  69.  
  70.    An NFS URL is based on the Common Internet Scheme Syntax described in
  71.    section 3.1 of RFC 1738.  It has the general form:
  72.  
  73.         nfs://<host>:<port><url-path>
  74.  
  75.    The ":<port>" part is optional.  If omitted then port 2049 is
  76.    assumed.  The <url-path> is also optional.
  77.  
  78.    The <url-path> is a hierarchical directory path of the form
  79.    /<directory>/<directory>/<directory>/.../<name>. The <url-path> must
  80.    consist only of characters within the US-ASCII character set.  Within
  81.    a <directory> or <name> component the character "/" is reserved and
  82.    must be encoded as described in Section 2.2 of RFC 1738.  If <url-
  83.    path> is omitted or consists solely of "/", it must default to the
  84.    path ".".
  85.  
  86. 2. URL Evaluation
  87.  
  88.    A client must evaluate an NFS URL by a method known as WebNFS
  89.    [RFC2054, RFC2055]. This method provides easy passage through
  90.    firewalls and proxy servers, as well as using a minimum number of
  91.    messages.  The WebNFS method is defined for NFS versions 2 and 3. It
  92.    assumes that the server registers on TCP or UDP port 2049 and
  93.    supports the public filehandle and multi-component lookup semantics
  94.    as described in the following sections.
  95.  
  96. 3. Server Connection
  97.  
  98.    The client must first attempt to create a TCP connection to <host>
  99.    using the <port> specified.  If :<port> is omitted, then port 2049
  100.    will be used.  If the server refuses the TCP connection, then the
  101.    client will use UDP.
  102.  
  103. 4. NFS Version
  104.  
  105.    The client must first attempt to use NFS version 3.  If the server
  106.    returns an RPC PROG_MISMATCH error then the client must assume that
  107.    NFS version 3 is not supported, and retry the operation with an NFS
  108.    version 2 public filehandle.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Callaghan                    Informational                      [Page 2]
  115.  
  116. RFC 2224                     NFS URL Scheme                 October 1997
  117.  
  118.  
  119. 5. Public Filehandle
  120.  
  121.    NFS filehandles are normally created by the server and used to
  122.    identify uniquely a particular file or directory on the server.  The
  123.    client does not normally create filehandles or have any knowledge of
  124.    the contents of a filehandle.
  125.  
  126.    The public filehandle is an an exception.  It is an NFS filehandle
  127.    with a reserved value and special semantics that allow an initial
  128.    filehandle to be obtained.  A WebNFS client uses the public
  129.    filehandle as an initial filehandle rather than using the MOUNT
  130.    protocol.  Since NFS version 2 and version 3 have different
  131.    filehandle formats, the public filehandle is defined differently for
  132.    each.
  133.  
  134.    The public filehandle is a zero filehandle.  For NFS version 2 this
  135.    is a filehandle with 32 zero octets.  A version 3 public filehandle
  136.    has zero length.
  137.  
  138. 5.1 NFS Version 2 Public Filehandle
  139.  
  140.    A version 2 filehandle is defined in RFC 1094 as an opaque value
  141.    occupying 32 octets.  A version 2 public filehandle has a zero in
  142.    each octet, i.e. all zeros.
  143.  
  144.     1                                                             32
  145.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  146.    |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
  147.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  148.  
  149. 5.2 NFS Version 3 Public Filehandle
  150.  
  151.    A version 3 filehandle is defined in RFC 1813 as a variable length
  152.    opaque value occupying up to 64 octets.  The length of the filehandle
  153.    is indicated by an integer value contained in a 4 octet value which
  154.    describes the number of valid octets that follow. A version 3 public
  155.    filehandle has a length of zero.
  156.  
  157.    +-+-+-+-+
  158.    |   0   |
  159.    +-+-+-+-+
  160.  
  161. 6. Multi-component Lookup
  162.  
  163.    Normally the NFS LOOKUP request (version 2 or 3) takes a directory
  164.    filehandle along with the name of a directory member, and returns the
  165.    filehandle of the directory member.  If a client needs to evaluate a
  166.    pathname that contains a sequence of components, then beginning with
  167.  
  168.  
  169.  
  170. Callaghan                    Informational                      [Page 3]
  171.  
  172. RFC 2224                     NFS URL Scheme                 October 1997
  173.  
  174.  
  175.    the directory filehandle of the first component it must issue a
  176.    series of LOOKUP requests one component at a time.  For instance,
  177.    evaluation of the path  "a/b/c" will generate separate LOOKUP
  178.    requests for each component of the pathname "a", "b", and "c".
  179.  
  180.    A LOOKUP request that uses the public filehandle can provide a
  181.    pathname containing multiple components.  The server is expected to
  182.    evaluate the entire pathname and return a filehandle for the final
  183.    component.
  184.  
  185.    For example, rather than evaluate the path "a/b/c" as:
  186.  
  187.         LOOKUP  FH=0x0  "a"  --->
  188.                              <---  FH=0x1
  189.         LOOKUP  FH=0x1  "b"  --->
  190.                              <---  FH=0x2
  191.         LOOKUP  FH=0x2  "c"  --->
  192.                              <---  FH=0x3
  193.  
  194.    Relative to the public filehandle these three LOOKUP
  195.    requests can be replaced by a single multi-component
  196.    lookup:
  197.  
  198.         LOOKUP  FH=0x0  "a/b/c"  --->
  199.                                  <---  FH=0x3
  200.  
  201.    Multi-component lookup is supported only for LOOKUP requests relative
  202.    to the public filehandle.
  203.  
  204.    The <url-path> of the NFS URL must be evaluated as a multi-component
  205.    lookup. This implies that the path components are delimited by
  206.    slashes and the characters that make up the path must be in the
  207.    printable US-ASCII character set. Characters not in the "unreserved"
  208.    set (see BNF description below) may be included in pathname
  209.    components but must be escaped.
  210.  
  211.    If the <url-path> is empty or consists solely of "/", the client must
  212.    send a multi-component lookup for the pathname ".".
  213.  
  214. 6.1 Absolute vs. Relative Pathname
  215.  
  216.    A multi-component pathname that begins with a slash character is
  217.    considered "absolute" and will be evaluated relative to the server's
  218.    root.  A pathname that does not begin with a slash is "relative" and
  219.    will be evaluated relative to the directory with which the public
  220.    filehandle is associated.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Callaghan                    Informational                      [Page 4]
  227.  
  228. RFC 2224                     NFS URL Scheme                 October 1997
  229.  
  230.  
  231.    Note that the initial "/" that introduces the <url-path> of an NFS
  232.    URL must not be passed to the server for multi-component lookup since
  233.    the pathname is to be evaluated relative to the public filehandle
  234.    directory.  For example, if the public filehandle is associated with
  235.    the server's directory "/a/b/c" then the URL:
  236.  
  237.         nfs://server/d/e/f
  238.  
  239.    will be evaluated with a multi-component lookup of the path
  240.    "d/e/f" relative to the server's directory "/a/b/c" while
  241.    the URL:
  242.  
  243.         nfs://server//a/b/c/d/e/f
  244.  
  245.    will locate the same file with an absolute multi-component lookup of
  246.    the path "/a/b/c/d/e/f" relative to the server's filesystem root.
  247.    Notice that a double slash is required at the beginning of the path.
  248.  
  249.    Not all WebNFS servers can support arbitrary use of absolute paths.
  250.    Clearly, the server must not return a filehandle if the path
  251.    identifies a file or directory that is not exported by the server.
  252.    In addition, some servers will not return a filehandle if the path
  253.    names a file or directory in an exported filesystem different from
  254.    the one that is associated with the public filehandle.
  255.  
  256. 6.2 Symbolic Links
  257.  
  258.    The NFS protocol supports symbolic links, which are the filesystem
  259.    equivalent of a relative URL. If a WebNFS client retrieves a
  260.    filehandle for a symbolic link (as indicated by the file type
  261.    attribute) then it should send a READLINK request to the server to
  262.    retrieve the path comprising the symbolic link.
  263.  
  264.    This path should then be combined with the URL which referenced the
  265.    symbolic link according to the rules described in RFC 1808.  If the
  266.    relative URL in the symbolic link text is to be resolved successfully
  267.    then it must contain only ASCII characters and conform to the syntax
  268.    described in RFC 1808.  Note that this allows a symbolic link to
  269.    contain an entire URL and it may specify a scheme that is not
  270.    necessarily an NFS URL.
  271.  
  272.    A symbolic link path that begins with a slash will be evaluated as an
  273.    absolute path relative to the directory associated with the public
  274.    filehandle which may not be the same as the server's system root
  275.    directory.  If symbolic links with absolute paths are to be evaluated
  276.    correctly on both client and server then the public filehandle must
  277.    be associated with the system root directory.
  278.  
  279.  
  280.  
  281.  
  282. Callaghan                    Informational                      [Page 5]
  283.  
  284. RFC 2224                     NFS URL Scheme                 October 1997
  285.  
  286.  
  287.    For example, if the symbolic link is named by the URL
  288.  
  289.         nfs://server/a/b
  290.  
  291.    then the following examples show how a new URL can be
  292.    formed from the symbolic link text:
  293.  
  294.          c                      = nfs://server/a/c
  295.  
  296.          c/d                    = nfs://server/a/c/d
  297.  
  298.          ../c                   = nfs://server/c
  299.  
  300.          /c/d                   = nfs://server/c/d
  301.  
  302.          nfs://server2/a/b      = nfs://server2/a/b
  303.  
  304. 7. Mount Protocol
  305.  
  306.    The NFS URL may have limited use for naming files on servers that do
  307.    not support the public filehandle and multi-component lookup.
  308.  
  309.    If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL, or
  310.    NFS3ERR_BADHANDLE error in response to the client's use of a public
  311.    filehandle, then the client should attempt to resolve the <url-path>
  312.    to a filehandle using the MOUNT protocol.
  313.  
  314.    Version 1 of the MOUNT protocol is described in Appendix A of RFC
  315.    1094 and version 3 in Appendix I of RFC 1813. Version 2 of the MOUNT
  316.    protocol is identical to version 1 except for the addition of a
  317.    procedure MOUNTPROC_PATHCONF which returns POSIX pathconf information
  318.    from the server.
  319.  
  320.    Note that the pathname sent to the server in the MOUNTPROC_MNT
  321.    request is assumed to be a server native path, rather than a slash-
  322.    separated path described by RFC 1738.  Hence, the MOUNT protocol can
  323.    reasonably be expected to map a <url-path> to a filehandle only on
  324.    servers that support slash-separated ASCII native paths.  In general,
  325.    servers that do not support WebNFS access or slash-separated ASCII
  326.    native paths should not advertise NFS URLs.
  327.  
  328.    At this point the client must already have some indication as to
  329.    which version of the NFS protocol is supported on the server.  Since
  330.    the filehandle format differs between NFS versions 2 and 3, the
  331.    client must select the appropriate version of the MOUNT protocol.
  332.    MOUNT versions 1 and 2 return only NFS version 2 filehandles, whereas
  333.    MOUNT version 3 returns NFS version 3 filehandles.
  334.  
  335.  
  336.  
  337.  
  338. Callaghan                    Informational                      [Page 6]
  339.  
  340. RFC 2224                     NFS URL Scheme                 October 1997
  341.  
  342.  
  343.    Unlike the NFS service, the MOUNT service is not registered on a
  344.    well-known port.  The client must use the PORTMAP service to locate
  345.    the server's MOUNT port before it can transmit a MOUNTPROC_MNT
  346.    request to retrieve the filehandle corresponding to the requested
  347.    path.
  348.  
  349.        Client                                       Server
  350.        ------                                       ------
  351.  
  352.        -------------- MOUNT port ? -------------->  Portmapper
  353.        <-------------- Port=984 ------------------
  354.  
  355.        ------- Filehandle for /export/foo ?  ---->  Mountd @ port 984
  356.        <--------- Filehandle=0xf82455ce0..  ------
  357.  
  358.    NFS servers commonly use a client's successful MOUNTPROC_MNT request
  359.    request as an indication that the client has "mounted" the filesystem
  360.    and may maintain this information in a file that lists the
  361.    filesystems that clients currently have mounted.  This information is
  362.    removed from the file when the client transmits an MOUNTPROC_UMNT
  363.    request.  Upon receiving a successful reply to a MOUNTPROC_MNT
  364.    request, a WebNFS client should send a MOUNTPROC_UMNT request to
  365.    prevent an accumulation of "mounted" records on the server.
  366.  
  367. 8.0 Bibliography
  368.  
  369.    [RFC1738]       Berners-Lee, T., Masinter, L. and M. McCahill,
  370.                    "Uniform Resource Locators (URL)," RFC 1738,
  371.                    December 1994.
  372.  
  373.    [RFC1808]       Fielding, R., "Relative Uniform Resource Locators,"
  374.                    RFC 1808, June 1995.
  375.  
  376.    [RFC1831]       Srinivasan, R., "RPC: Remote Procedure Call
  377.                    Protocol Specification Version 2," RFC 1831,
  378.                    August 1995.
  379.  
  380.    [RFC1832]       Srinivasan, R., "XDR: External Data Representation
  381.                    Standard," RFC 1832, August 1995.
  382.  
  383.    [RFC1833]       Srinivasan, R., "Binding Protocols for ONC RPC
  384.                    Version 2," RFC 1833, August 1995.
  385.  
  386.    [RFC1094]       Sun Microsystems, Inc., "Network Filesystem
  387.                    Specification," RFC 1094, March 1989.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Callaghan                    Informational                      [Page 7]
  395.  
  396. RFC 2224                     NFS URL Scheme                 October 1997
  397.  
  398.  
  399.    [RFC1813]       Callaghan, B., Pawlowski, B. and P. Staubach,
  400.                    "NFS Version 3 Protocol Specification," RFC 1813,
  401.                    June 1995.
  402.  
  403.    [RFC2054]       Callaghan, B., "WebNFS Client Specification,"
  404.                    RFC 2054, October 1996.
  405.  
  406.    [RFC2055]       Callaghan, B., "WebNFS Server Specification,"
  407.                    RFC 2055, October 1996.
  408.  
  409.    [Sandberg]      Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh,
  410.                    B.  Lyon, "Design and Implementation of the Sun
  411.                    Network Filesystem," USENIX Conference
  412.                    Proceedings, USENIX Association, Berkeley, CA,
  413.                    Summer 1985.  The basic paper describing the
  414.                    SunOS implementation of the NFS version 2
  415.                    protocol, and discusses the goals, protocol
  416.                    specification and trade-offs.
  417.  
  418.    [X/OpenNFS]     X/Open Company, Ltd., X/Open CAE Specification:
  419.                    Protocols for X/Open Internetworking: XNFS,
  420.                    X/Open Company, Ltd., Apex Plaza, Forbury Road,
  421.                    Reading Berkshire, RG1 1AX, United Kingdom,
  422.                    1991.  This is an indispensable reference for
  423.                    the NFS and accompanying protocols, including
  424.                    the Lock Manager and the Portmapper.
  425.  
  426.    [X/OpenPCNFS]   X/Open Company, Ltd., X/Open CAE Specification:
  427.                    Protocols for X/Open Internetworking: (PC)NFS,
  428.                    Developer's Specification, X/Open Company, Ltd.,
  429.                    Apex Plaza, Forbury Road, Reading Berkshire, RG1
  430.                    1AX, United Kingdom, 1991.  This is an
  431.                    indispensable reference for NFS protocol and
  432.                    accompanying protocols, including the Lock Manager
  433.                    and the Portmapper.
  434.  
  435. 9. Security Considerations
  436.  
  437.    Since the WebNFS server features are based on NFS protocol versions 2
  438.    and 3, the RPC based security considerations described in RFC 1094,
  439.    RFC 1831, and RFC 1832 apply here also.
  440.  
  441.    Server implementors should be careful when implementing multi-
  442.    component lookup that the client cannot obtain unauthorized access to
  443.    files or directories. For example: a path that includes multiple
  444.    occurrences of "../" may locate a filesystem outside of the exported
  445.    filesystem associated with the public filehandle.
  446.  
  447.  
  448.  
  449.  
  450. Callaghan                    Informational                      [Page 8]
  451.  
  452. RFC 2224                     NFS URL Scheme                 October 1997
  453.  
  454.  
  455.    Clients and servers may separately negotiate secure connection
  456.    schemes for authentication, data integrity, and privacy.
  457.  
  458. 10. BNF for NFS URL Scheme
  459.  
  460.    The syntax of the NFS URL is a subset of the Generic URL syntax
  461.    described in RFC 1738.  An NFS URL does not include user or password
  462.    components, nor does it recognize "?" query or "#" fragment
  463.    components.
  464.       nfsURL        = "nfs" ":" relativeURL
  465.       relativeURL   = net_path | abs_path | rel_path
  466.       net_path      = "//" hostport [ abs_path ]
  467.       abs_path      = "/"  rel_path
  468.       rel_path      = [ path_segments ]
  469.  
  470.       hostport      = host [ ":" port ]
  471.       host          = hostname | hostnumber
  472.       hostname      = *( domainlabel "." ) toplabel
  473.       domainlabel   = alphanum | alphanum *( alphanum | "-" ) alphanum
  474.       toplabel      = alpha | alpha *( alphanum | "-" ) alphanum
  475.       hostnumber    = 1*digit "." 1*digit "." 1*digit "." 1*digit
  476.       port          = *digit
  477.  
  478.       url-path      = [ "/" ] path_segments
  479.       path_segments = segment *( "/" segment )
  480.       segment       = *pchar
  481.       pchar         = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
  482.  
  483.       reserved      = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
  484.       unreserved    = alpha | digit | mark
  485.       mark          = "$" | "-" | "_" | "." | "!" | "~" |
  486.                       "*" | "'" | "(" | ")" | ","
  487.  
  488.       escaped       = "%" hex hex
  489.       hex           = digit | "A" | "B" | "C" | "D" | "E" | "F" |
  490.                               "a" | "b" | "c" | "d" | "e" | "f"
  491.  
  492.       alphanum      = alpha | digit
  493.       alpha         = lowalpha | upalpha
  494.  
  495.       lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
  496.                  "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
  497.                  "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
  498.       upalpha  = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
  499.                  "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
  500.                  "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
  501.       digit    = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
  502.                  "8" | "9"
  503.  
  504.  
  505.  
  506. Callaghan                    Informational                      [Page 9]
  507.  
  508. RFC 2224                     NFS URL Scheme                 October 1997
  509.  
  510.  
  511. 11. Acknowledgements
  512.  
  513.    This specification was extensively reviewed by the NFS group at
  514.    SunSoft and brainstormed by Michael Eisler.
  515.  
  516. 12. Author's Address
  517.  
  518.    Address comments related to this RFC to:
  519.  
  520.       brent@eng.sun.com
  521.  
  522.  
  523.    Brent Callaghan
  524.    Sun Microsystems, Inc.
  525.    Mailstop Mpk17-201,
  526.    901 San Antonio Road,
  527.    Palo Alto, California 94303
  528.  
  529.    Phone: 1-415-786-5067
  530.    EMail: brent.callaghan@eng.sun.com
  531.    Fax:   1-415-786-5896
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Callaghan                    Informational                     [Page 10]
  563.  
  564. RFC 2224                     NFS URL Scheme                 October 1997
  565.  
  566.  
  567. 13.  Full Copyright Statement
  568.  
  569.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  570.  
  571.    This document and translations of it may be copied and furnished to
  572.    others, and derivative works that comment on or otherwise explain it
  573.    or assist in its implmentation may be prepared, copied, published
  574.    andand distributed, in whole or in part, without restriction of any
  575.    kind, provided that the above copyright notice and this paragraph are
  576.    included on all such copies and derivative works.  However, this
  577.    document itself may not be modified in any way, such as by removing
  578.    the copyright notice or references to the Internet Society or other
  579.    Internet organizations, except as needed for the purpose of
  580.    developing Internet standards in which case the procedures for
  581.    copyrights defined in the Internet Standards process must be
  582.    followed, or as required to translate it into languages other than
  583.    English.
  584.  
  585.    The limited permissions granted above are perpetual and will not be
  586.    revoked by the Internet Society or its successors or assigns.
  587.  
  588.    This document and the information contained herein is provided on an
  589.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  590.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  591.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  592.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  593.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Callaghan                    Informational                     [Page 11]
  619.  
  620.