1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc4157.txt b/doc/rfc/rfc4157.txt
new file mode 100644
index 0000000..c63e707
--- /dev/null
+++ b/doc/rfc/rfc4157.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         P. Hoffman
+Request for Comments: 4157                                VPN Consortium
+Category: Historic                                           August 2005
+
+
+                        The prospero URI Scheme
+
+Status of This Memo
+
+   This memo defines a Historic Document for the Internet community.  It
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies the prospero Uniform Resource Identifier
+   (URI) scheme that was originally specified in RFC 1738.  The purpose
+   of this document is to allow RFC 1738 to be made obsolete while
+   keeping the information about the scheme on standards track.
+
+1.  Introduction
+
+   URIs were previously defined in RFC 2396 [RFC2396], which was updated
+   by RFC 3986 [RFC3986].  Those documents also specify how to define
+   schemes for URIs.
+
+   The first definitions for many URI schemes appeared in RFC 1738
+   [RFC1738].  Because that document has been made obsolete, this
+   document copies the prospero URI scheme from it to allow that
+   material to remain on standards track.
+
+2.  Scheme Definition
+
+   The prospero URL scheme is used to designate resources that are
+   accessed through the Prospero Directory Service.  The Prospero
+   protocol is described in the original Prospero specification [PROSP].
+
+   Historical note: The Prospero protocol was not widely implemented and
+   almost no Prospero servers are in use today.
+
+   A prospero URL takes the form:
+
+   prospero://<host>:<port>/<hsoname>;<field>=<value>
+
+
+
+
+Hoffman                         Historic                        [Page 1]
+
+RFC 4157                The prospero URI Scheme              August 2005
+
+
+   If :<port> is omitted, the port defaults to 1525.  No username or
+   password is allowed.
+
+   The <hsoname> is the host-specific object name in the Prospero
+   protocol, suitably encoded.  This name is opaque and interpreted by
+   the Prospero server.  The semicolon ";" is reserved and may not
+   appear without quoting in the <hsoname>.
+
+   Prospero URLs are interpreted by contacting a Prospero directory
+   server on the specified host and port to determine appropriate access
+   methods for a resource.  The access methods might themselves be
+   represented as different URLs.  External Prospero links are
+   represented as URLs of the underlying access method and are not
+   represented as Prospero URLs.
+
+   Note that a slash "/" may appear in the <hsoname> without quoting,
+   and no significance may be assumed by the application.  Though
+   slashes may indicate hierarchical structure on the server, such
+   structure is not guaranteed.  Note that many <hsoname>s begin with a
+   slash, in which case the host or port will be followed by a double
+   slash: the slash from the URL syntax, followed by the initial slash
+   from the <hsoname> (e.g., <URL:prospero://example.com//pros/name>
+   designates a <hsoname> of "/pros/name").
+
+   In addition, after the <hsoname>, optional fields and values
+   associated with a Prospero link may be specified as part of the URL.
+   When present, each field/value pair is separated from each other and
+   from the rest of the URL by a ";" (semicolon).  The name of the field
+   and its value are separated by a "=" (equal sign).  If present, these
+   fields serve to identify the target of the URL.  For example, the
+   OBJECT-VERSION field can be specified to identify a specific version
+   of an object.
+
+3.  Security Considerations
+
+   Many security considerations for URI schemes are discussed in
+   [RFC3986].  [PROSP] uses passwords in the clear for authentication,
+   and offers no privacy, both of which are considered extremely unsafe
+   in current practice.
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                         Historic                        [Page 2]
+
+RFC 4157                The prospero URI Scheme              August 2005
+
+
+4.  Informative References
+
+   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+              Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [PROSP]    Neuman, B. and S. Augart, "The Prospero Protocol",
+              USC/Information Sciences Institute, June 1993.
+
+Author's Address
+
+   Paul Hoffman
+   VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+   US
+
+   EMail: paul.hoffman@vpnc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                         Historic                        [Page 3]
+
+RFC 4157                The prospero URI Scheme              August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hoffman                         Historic                        [Page 4]
+