doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3205.txt b/doc/rfc/rfc3205.txt
new file mode 100644
index 0000000..737c4ed
--- /dev/null
+++ b/doc/rfc/rfc3205.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                           K. Moore
+Request for Comments: 3205                       University of Tennessee
+BCP: 56                                                    February 2002
+Category: Best Current Practice
+
+
+                   On the use of HTTP as a Substrate
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   Recently there has been widespread interest in using Hypertext
+   Transfer Protocol (HTTP) as a substrate for other applications-level
+   protocols.  This document recommends technical particulars of such
+   use, including use of default ports, URL schemes, and HTTP security
+   mechanisms.
+
+1. Introduction
+
+   Recently there has been widespread interest in using Hypertext
+   Transfer Protocol (HTTP) [1] as a substrate for other applications-
+   level protocols.  Various reasons cited for this interest have
+   included:
+
+   o  familiarity and mindshare,
+
+   o  compatibility with widely deployed browsers,
+
+   o  ability to reuse existing servers and client libraries,
+
+   o  ease of prototyping servers using CGI scripts and similar
+      extension mechanisms,
+
+   o  ability to use existing security mechanisms such as HTTP digest
+      authentication [2] and SSL or TLS [3],
+
+   o  the ability of HTTP to traverse firewalls, and
+
+   o  cases where a server often needs to support HTTP anyway.
+
+
+
+Moore                    Best Current Practice                  [Page 1]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   The Internet community has a long tradition of protocol reuse, dating
+   back to the use of Telnet [4] as a substrate for FTP [5] and SMTP
+   [6].  However, the recent interest in layering new protocols over
+   HTTP has raised a number of questions when such use is appropriate,
+   and the proper way to use HTTP in contexts where it is appropriate.
+   Specifically, for a given application that is layered on top of HTTP:
+
+   o  Should the application use a different port than the HTTP default
+      of 80?
+
+   o  Should the application use traditional HTTP methods (GET, POST,
+      etc.) or should it define new methods?
+
+   o  Should the application use http: URLs or define its own prefix?
+
+   o  Should the application define its own MIME-types, or use something
+      that already exists (like registering a new type of MIME-directory
+      structure)?
+
+   This memo recommends certain design decisions in answer to these
+   questions.
+
+   This memo is intended as advice and recommendation for protocol
+   designers, working groups, implementors, and IESG, rather than as a
+   strict set of rules which must be adhered to in all cases.
+   Accordingly, the capitalized key words defined in RFC 2119, which are
+   intended to indicate conformance to a specification, are not used in
+   this memo.
+
+2. Issues Regarding the Design Choice to use HTTP
+
+   Despite the advantages listed above, it's worth asking the question
+   as to whether HTTP should be used at all, or whether the entire HTTP
+   protocol should be used.
+
+2.1 Complexity
+
+   HTTP started out as a simple protocol, but quickly became much more
+   complex due to the addition of several features unanticipated by its
+   original design.  These features include persistent connections, byte
+   ranges, content negotiation, and cache support.  All of these are
+   useful for traditional web applications but may not be useful for the
+   layered application.  The need to support (or circumvent) these
+   features can add additional complexity to the design and
+   implementation of a protocol layered on top of HTTP.  Even when HTTP
+   can be "profiled" to minimize implementation overhead, the effort of
+   specifying such a profile might be more than the effort of specifying
+   a purpose-built protocol which is better suited to the task at hand.
+
+
+
+Moore                    Best Current Practice                  [Page 2]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   Even if existing HTTP client and server code can often be re-used,
+   the additional complexity of layering something over HTTP vs. using a
+   purpose-built protocol can increase the number of interoperability
+   problems.
+
+2.2 Overhead
+
+   Further, although HTTP can be used as the transport for a "remote
+   procedure call" paradigm, HTTP's protocol overhead, along with the
+   connection setup overhead of TCP, can make HTTP a poor choice.  A
+   protocol based on UDP, or with both UDP and TCP variants, should be
+   considered if the payloads are very likely to be small (less than a
+   few hundred bytes) for the foreseeable future.  This is especially
+   true if the protocol might be heavily used, or if it might be used
+   over slow or expensive links.
+
+   On the other hand, the connection setup overhead can become
+   negligible if the layered protocol can utilize HTTP/1.1's persistent
+   connections, and if the same client and server are likely to perform
+   several transactions during the time the HTTP connection is open.
+
+2.3 Security
+
+   Although HTTP appears at first glance to be one of the few "mature"
+   Internet protocols that can provide good security, there are many
+   applications for which neither HTTP's digest authentication nor TLS
+   are sufficient by themselves.
+
+   Digest authentication requires a secret (e.g., a password) to be
+   shared between client and server.  This further requires that each
+   client know the secret to be used with each server, but it does not
+   provide any means of securely transmitting such secrets between the
+   parties.  Shared secrets can work fine for small groups where
+   everyone is physically co-located; they don't work as well for large
+   or dispersed communities of users.  Further, if the server is
+   compromised a large number of secrets may be exposed, which is
+   especially dangerous if the same secret (or password) is used for
+   several applications.  (Similar concerns exist with TLS based clients
+   or servers - if a private key is compromised then the attacker can
+   impersonate the party whose key it has.)
+
+   TLS and its predecessor SSL were originally designed to authenticate
+   web servers to clients, so that a user could be assured (for example)
+   that his credit card number was not being sent to an imposter.
+   However, many applications need to authenticate clients to servers,
+   or to provide mutual authentication of client and server.  TLS does
+
+
+
+
+
+Moore                    Best Current Practice                  [Page 3]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   have a capability to provide authentication in each direction, but
+   such authentication may or may not be suitable for a particular
+   application.
+
+   Web browsers which support TLS or SSL are typically shipped with the
+   public keys of several certificate authorities (CAs) "wired in" so
+   that they can verify the identity of any server whose public key was
+   signed by one of those CAs.  For this to work well, every secure web
+   server's public key has to be signed by one of the CAs whose keys are
+   wired into popular browsers.  This deployment model works when there
+   are a (relatively) small number of servers whose identities can be
+   verified, and their public keys signed, by the small number of CAs
+   whose keys are included in a small number of different browsers.
+
+   This scheme does not work as well to authenticate millions of
+   potential clients to servers.  It would take a much larger number of
+   CAs to do the job, each of which would need to be widely trusted by
+   servers.  Those CAs would also have a more difficult time verifying
+   the identities of (large numbers of) ordinary users than they do in
+   verifying the identities of (a smaller number of) commercial and
+   other enterprises that need to run secure web servers.
+
+   Also, in a situation where there were a large number of clients
+   authenticating with TLS, it seems unlikely that there would be a set
+   of CAs whose keys were trusted by every server.  A client that
+   potentially needed to authenticate to multiple servers would
+   therefore need to be configured as to which key to use with which
+   server when attempting to establish a secure connection to the
+   server.
+
+   For the reasons stated above, client authentication is rarely used
+   with TLS.  A common technique is to use TLS to authenticate the
+   server to the client and to establish a private channel, and for the
+   client to authenticate to the server using some other means - for
+   example, a username and password using HTTP basic or digest
+   authentication.
+
+   For any application that requires privacy, the 40-bit ciphersuites
+   provided by some SSL implementations (to conform to outdated US
+   export regulations or to regulations on the use or export of
+   cryptography in other countries) are unsuitable.  Even 56-bit DES
+   encryption, which is required of conforming TLS implementations, has
+   been broken in a matter of days with a modest investment in
+   resources.  So if TLS is chosen it may be necessary to discourage use
+   of small key lengths, or of weak ciphersuites, in order to provide
+   adequate privacy assurance.  If TLS is used to provide privacy for
+   passwords sent by clients then it is especially important to support
+   longer keys.
+
+
+
+Moore                    Best Current Practice                  [Page 4]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   None of the above should be taken to mean that either digest
+   authentication or TLS are generally inferior to other authentication
+   systems, or that they are unsuitable for use in other applications
+   besides HTTP.  Many of the limitations of TLS and digest
+   authentication also apply to other authentication and privacy
+   systems.  The point here is that neither TLS nor digest
+   authentication is a "magic pixie dust" solution to authentication or
+   privacy.  In every case, an application's designers must carefully
+   determine the application's users' requirements for authentication
+   and privacy before choosing an authentication or privacy mechanism.
+
+   Note also that TLS can be used with other TCP-based protocols, and
+   there are SASL [7] mechanisms similar to HTTP's digest
+   authentication.  So it is not necessary to use HTTP in order to
+   benefit from either TLS or digest-like authentication.  However, HTTP
+   APIs may already support TLS and/or digest.
+
+2.4 Compatibility with Proxies, Firewalls, and NATs
+
+   One oft-cited reason for the use of HTTP is its ability to pass
+   through proxies, firewalls, or network address translators (NATs).
+   One unfortunate consequence of firewalls and NATs is that they make
+   it harder to deploy new Internet applications, by requiring explicit
+   permission (or even a software upgrade of the firewall or NAT) to
+   accommodate each new protocol.  The existence of firewalls and NATs
+   creates a strong incentive for protocol designers to layer new
+   applications on top of existing protocols, including HTTP.
+
+   However, if a site's firewall prevents the use of unknown protocols,
+   this is presumably a conscious policy decision on the part of the
+   firewall administrator.  While it is arguable that such policies are
+   of limited value in enhancing security, this is beside the point -
+   well-known port numbers are quite useful for a variety of purposes,
+   and the overloading of port numbers erodes this utility.  Attempting
+   to circumvent a site's security policy is not an acceptable
+   justification for doing so.
+
+   It would be useful to establish guidelines for "firewall-friendly"
+   protocols, to make it easier for existing firewalls to be compatible
+   with new protocols.
+
+2.5 Questions to be asked when considering use of HTTP
+
+   o  When considering payload size and traffic patterns, is HTTP an
+      appropriate transport for the anticipated use of this protocol?
+
+
+
+
+
+
+Moore                    Best Current Practice                  [Page 5]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+      (In other words: will the payload size be worth the overhead
+      associated with TCP and HTTP?  Or will the application be able to
+      make use of HTTP persistent connections to amortize the cost of
+      that overhead over several requests?)
+
+   o  Is this new protocol usable by existing web browsers without
+      modification?
+
+      (For example: Is the request transmitted as if it were a filled-in
+      HTML form?  Is the response which is returned viewable from a web
+      browser, say as HTML?)
+
+   o  Are the existing HTTP security mechanisms appropriate for the new
+      application?
+
+   o  Are HTTP status codes and the HTTP status code paradigm suitable
+      for this application?  (see section 8)
+
+   o  Does the server for this application need to support HTTP anyway?
+
+3. Issues Regarding Reuse of Port 80
+
+   IANA has reserved TCP port number 80 for use by HTTP.  It would not
+   be appropriate for a substantially new service, even one which uses
+   HTTP as a substrate, to usurp port 80 from its traditional use.  A
+   new use of HTTP might be considered a "substantially new service",
+   thus requiring a new port, if any of the following are true:
+
+   o  The "new service" and traditional HTTP service are likely to
+      reference different sets of data, even when they both operate on
+      the same host.
+
+   o  There is a good reason for the "new service" to be implemented by
+      a separate server process, or separate code, than traditional HTTP
+      service on the same host, at least on some platforms.
+
+   o  There is a good reason to want to easily distinguish the traffic
+      of the "new service" from traditional HTTP, e.g., for the purposes
+      of firewall access control or traffic analysis.
+
+   o  If none of the above are true, it is arguable that the new use of
+      HTTP is an "extension" to traditional HTTP, rather than a "new
+      service".  Extensions to HTTP which share data with traditional
+      HTTP services should probably define new HTTP methods to describe
+      those extensions, rather than using separate ports.  If separate
+      ports are used, there is no way for a client to know whether they
+      are separate services or different ways of accessing the same
+      underlying service.
+
+
+
+Moore                    Best Current Practice                  [Page 6]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+4. Issues Regarding Reuse of the http: Scheme in URLs
+
+   A number of different URL schemes are in widespread use and many more
+   are in the process of being standardized.  In practice, the URL
+   scheme not only serves as a "tag" to govern the interpretation of the
+   remaining portion of the URL, it also provides coarse identification
+   of the kind of resource or service which is being accessed.  For
+   example, web browsers typically provide a different response when a
+   user mouse-clicks on an "http" URL, than when the user clicks on a
+   "mailto" URL.
+
+   Some criteria that might be used in making this determination are:
+
+   o  Whether this URL scheme is likely to become widely used, versus
+      used only in limited communities or by private agreement.
+
+   o  Whether a new "default port" is needed.  If reuse of port 80 is
+      not appropriate (see above), a new "default port" is needed.  A
+      new default port in turn requires that a new URL scheme be
+      registered if that URL scheme is expected to be widely used.
+      Explicit port numbers in URLs are regarded as an "escape hatch",
+      not something for use in ordinary circumstances.
+
+   o  Whether use of the new service is likely to require a
+      substantially different setup or protocol interaction with the
+      server, than ordinary HTTP service.  This could include the need
+      to request a different type of service from the network, or to
+      reserve bandwidth, or to present different TLS authentication
+      credentials to the server, or different kind of server
+      provisioning, or any number of other needs.
+
+   o  Whether user interfaces (such as web browsers) are likely to be
+      able to exploit the difference in the URL prefix to produce a
+      significant improvement in usability.
+
+   According to the rules in [8] the "http:" URI is part of the "IETF
+   Tree" for URL scheme names, and IETF is the maintainer of the "IETF
+   Tree".  Since IESG is the decision-making body for IETF, IESG has the
+   authority to determine whether a resource accessed by a protocol that
+   is layered on top of HTTP, should use http: or some other URL prefix.
+
+   Note that the convention of appending an "s" to the URL scheme to
+   mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and
+   of limited value.  For most applications, a single "use TLS or SSL"
+   bit is not sufficient to adequately convey the information that a
+   client needs to authenticate itself to a server, even if it has the
+   proper credentials.  For instance, in order to ensure that adequate
+   security is provided with TLS an application may need to be
+
+
+
+Moore                    Best Current Practice                  [Page 7]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   configured with a list of acceptable ciphersuites, or with the client
+   certificate to be used to authenticate to a particular server.  When
+   it is necessary to specify authentication or other connection setup
+   information in a URL these should be communicated in URL parameters,
+   rather than in the URL prefix.
+
+5. Issues regarding use of MIME media types
+
+   Since HTTP uses the MIME media type system [9] to label its payload,
+   many applications which layer on HTTP will need to define, or select,
+   MIME media types for use by that application.  Especially when using
+   a multipart structure, the choice of media types requires careful
+   consideration.  In particular:
+
+   o  Should some existing framework be used, such as text/directory
+      [10], or XML [11,12], or should the new content-types be built
+      from scratch?  Just as with HTTP, it's useful if code can be
+      reused, but protocol designers should not be over-eager to
+      incorporate a general but complex framework into a new protocol.
+      Experience with ASN.1, for example, suggests that the advantage of
+      using a general framework may not be worth the cost.
+
+   o  Should MIME multipart or message types be allowed?  This can be an
+      advantage if it is desirable to incorporate (for example) the
+      multipart/alternative construct or the MIME security framework.
+      On the other hand, these constructs were designed specifically for
+      use in store-and-forward electronic mail systems, and other
+      mechanisms may be more appropriate for the application being
+      considered.
+
+      The point here is that a decision to use MIME content-type names
+      to describe protocol payloads (which is generally desirable if the
+      same payloads may appear in other applications) does not imply
+      that the application must accept arbitrary MIME content-types,
+      including MIME multipart or security mechanisms.  Nor does it
+      imply that the application must use MIME syntax or that it must
+      recognize or even tolerate existing MIME header fields.
+
+   o  If the same payload is likely to be sent over electronic mail, the
+      differences between HTTP encoding of the payload and email
+      encoding of the payload should be minimized.  Ideally, there
+      should be no differences in the "canonical form" used in the two
+      environments.  Text/* media types can be problematic in this
+      regard because MIME email requires CRLF for line endings of text/*
+      body parts, where HTTP traditionally uses LF only.
+
+
+
+
+
+
+Moore                    Best Current Practice                  [Page 8]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   o  A MIME content-type label describes the nature of the object being
+      labeled.  It does not describe, and should not be used to
+      describe, the semantics which should be applied when the object is
+      received.  For instance, the transmission of an object with a
+      particular content-type using HTTP POST, should not be taken as a
+      request for some operation based solely on the type.  The request
+      should be separate from the content-type label and it should be
+      explicit.
+
+      When it is necessary for a protocol layered on HTTP to allow
+      different operations on the same type of object, this can be
+      communicated in a number of different ways: HTTP methods, HTTP
+      request-URI, HTTP request headers, the MIME Content-Disposition
+      header field, or as part of the payload.
+
+6. Issues Regarding Existing vs.  New HTTP Methods
+
+   It has been suggested that a new service layered on top of HTTP
+   should define one or more new HTTP methods, rather than allocating a
+   new port.  The use of new methods may be appropriate, but is not
+   sufficient in all cases.  The definition of one or more new methods
+   for use in a new protocol, does not by itself alleviate the need for
+   use of a new port, or a new URL type.
+
+7. Issues regarding reuse of HTTP client, server, and proxy code
+
+   As mentioned earlier, one of the primary reasons for the use of HTTP
+   as a substrate for new protocols, is to allow reuse of existing HTTP
+   client, server, or proxy code.  However, HTTP was not designed for
+   such layering.  Existing HTTP client and code may have "http"
+   assumptions wired into them.  For instance, client libraries and
+   proxies may expect "http:" URLs, and clients and servers may send
+   (and expect) "HTTP/1.1", in requests and responses, as opposed to the
+   name of the layered protocol and its version number.
+
+   Existing client libraries may not understand new URL types.  In order
+   to get a new HTTP-layered application client to work with an existing
+   client library, it may be necessary for the application to convert
+   its URLs to an "http equivalent" form.  For instance, if service
+   "xyz" is layered on top of HTTP using port ###, the xyz client may
+   need, when invoking an HTTP client library, to translate its URLs
+   from "xyz://host/something" format to "http://host:###/something" for
+   the purpose of calling that library.  This should be done ONLY when
+   calling the HTTP client library - such URLs should not be used in
+   other parts of the protocol, nor should they be exposed to users.
+
+
+
+
+
+
+Moore                    Best Current Practice                  [Page 9]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   Note that when a client is sending requests directly to an origin
+   server, the URL prefix ("http:") is not normally sent.  So
+   translating xyz: URLs to http: URLs when calling the client library
+   should not actually cause http: URLs to be sent over the wire.  But
+   when the same client is sending requests to a proxy server, the
+   client will normally send the entire URL (including the http: prefix)
+   in those requests.  The proxy will remove the http: prefix when the
+   request is communicated to the origin server.
+
+   Existing HTTP client libraries and servers will transmit "HTTP/1.1"
+   (or a different version) in requests and responses.  To facilitate
+   reuse of such libraries and servers by a new protocol, such a
+   protocol may therefore need to transmit and accept "HTTP/1.1" rather
+   than its own protocol name and version number.  Designers of
+   protocols which are layered on top of HTTP should explicitly choose
+   whether or not to accept "HTTP/1.1" in protocol exchanges.
+
+   For certain applications it may be necessary to require or limit use
+   of certain HTTP features, for example, to defeat caching of responses
+   by proxies.  Each protocol layered on HTTP must therefore specify the
+   specific way that HTTP will be used, and in particular, how the
+   client and server should interact with HTTP proxies.
+
+8.  Issues regarding use of HTTP status codes
+
+   HTTP's three-digit status codes were designed for use with
+   traditional HTTP applications (e.g., document retrieval, forms-based
+   queries), and are unlikely to be suitable to communicate the
+   specifics of errors encountered in dissimilar applications.  Even
+   when it seems like there is a close match between HTTP status codes
+   and the codes needed by the application, experience with reuse of
+   other protocols indicates that subtle variations in usage are likely;
+   and that this is likely to degrade interoperability of both the
+   original protocol (in this case HTTP) and any layered applications.
+
+   HTTP status codes therefore should not be used to indicate subtle
+   errors of layered applications.  At most, the "generic" HTTP codes
+   200 (for complete success) and 500 (for complete failure) should be
+   used to indicate errors resulting from the content of the request
+   message-body.  Under certain circumstances, additional detail about
+   the nature of the error can then be included in the response
+   message-body.  Other status codes than 200 or 500 should only appear
+   if the error was detected by the HTTP server or by an intermediary.
+
+   A layered application should not define new HTTP status codes.  The
+   set of available status codes is small, conflicts in code assignment
+   between different layered applications are likely, and they may be
+   needed by future versions of, or extensions to, mainstream HTTP.
+
+
+
+Moore                    Best Current Practice                 [Page 10]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   Use of HTTP's error codes is problematic when the layered application
+   does not share same notion of success or failure as HTTP.  The
+   problem exists when the client does not connect directly to the
+   origin server, but via one or more HTTP caches or proxies.  (Since
+   the ability of HTTP to communicate through intermediaries is often
+   the primary motivation for reusing HTTP, the ability of the
+   application to operate in the presence of such intermediaries is
+   considered very important.)  Such caches and proxies will interpret
+   HTTP's error codes and may take additional action based on those
+   codes.  For instance, on receipt of a 200 error code from an origin
+   server (and under other appropriate conditions) a proxy may cache the
+   response and re-issue it in response to a similar request.  Or a
+   proxy may modify the result of a request which returns a 500 error
+   code in order to add a "helpful" error message.  Other response codes
+   may produce other behaviors.
+
+   A few guidelines are therefore in order:
+
+   o  A layered application should use appropriate HTTP error codes to
+      report errors resulting from information in the HTTP request-line
+      and header fields associated with the request.  This request
+      information is part of the HTTP protocol and errors which are
+      associated with that information should therefore be reported
+      using HTTP protocol mechanisms.
+
+   o  A layered application for which all errors resulting from the
+      message-body can be classified as either "complete success" or
+      "complete failure" may use 200 and 500 for those conditions,
+      respectively.  However, the specification for such an application
+      must define the mechanism which ensures that its successful (200)
+      responses are not cached by intermediaries, or demonstrate that
+      such caching will do no harm; and it must be able to operate even
+      if the message-body of an error (500) response is not transmitted
+      back to the client intact.
+
+   o  A layered application may return a 200 response code for both
+      successfully processed requests and errors (or other exceptional
+      conditions) resulting from the request message-body (but not from
+      the request headers).  Such an application must return its error
+      code as part of the response message body, and the specification
+      for that application protocol must define the mechanism by which
+      the application ensures that its responses are not cached by
+      intermediaries.  In this case a response other than 200 should be
+      used only to indicate errors with, or the status of, the HTTP
+      protocol layer (including the request headers), or to indicate the
+      inability of the HTTP server to communicate with the application
+      server.
+
+
+
+
+Moore                    Best Current Practice                 [Page 11]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   o  A layered application which cannot operate in the presence of
+      intermediaries or proxies that cache and/or alter error responses,
+      should not use HTTP as a substrate.
+
+9. Summary of recommendations regarding reuse of HTTP
+
+   1. All protocols should provide adequate security.  The security
+      needs of a particular application will vary widely depending on
+      the application and its anticipated use environment.  Merely using
+      HTTP and/or TLS as a substrate for a protocol does not
+      automatically provide adequate security for all environments, nor
+      does it relieve the protocol developers of the need to analyze
+      security considerations for their particular application.
+
+   2. New protocols - including but not limited to those using HTTP -
+      should not attempt to circumvent users' firewall policies,
+      particularly by masquerading as existing protocols.
+      "Substantially new services" should not reuse existing ports.
+
+   3. In general, new protocols or services should not reuse http: or
+      other URL schemes.
+
+   4. Each new protocol specification that uses HTTP as a substrate
+      should describe the specific way that HTTP is to be used by that
+      protocol, including how the client and server interact with
+      proxies.
+
+   5. New services should follow the guidelines in section 8 regarding
+      use of HTTP status codes.
+
+10.  Security Considerations
+
+   Much of this document is about security.  Section 2.3 discusses
+   whether HTTP security is adequate for the needs of a particular
+   application, section 2.4 discusses interactions between new HTTP-
+   based protocols and firewalls, section 3 discusses use of separate
+   ports so that firewalls are not circumvented, and section 4 discusses
+   the inadequacy of the "s" suffix of a URL prefix for specifying
+   security levels.
+
+11.  References
+
+   [1]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+
+
+
+
+
+Moore                    Best Current Practice                 [Page 12]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+   [2]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
+         Basic and Digest Access Authentication", RFC 2617, June 1999.
+
+   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+         2246, January 1999.
+
+   [4]   Postel, J. and J. Reynolds, "Telnet Protocol Specification",
+         STD 8, RFC 854, May 1983.
+
+   [5]   Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
+         RFC 959, October 1985.
+
+   [6]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+         2001.
+
+   [7]   Myers, J., "Simple Authentication and Security Layer (SASL)",
+         RFC 2222, October 1997.
+
+   [8]   Petke, R. and I. King, "Registration Procedures for URL Scheme
+         Names", BCP 35, RFC 2717, November 1999.
+
+   [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two: Media Types", RFC 2046, November
+         1996.
+
+   [10]  Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
+         Directory Information", RFC 2425, September 1998.
+
+   [11]  Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
+         Language (XML)" World Wide Web Consortium Recommendation REC-
+         xml-19980210, February 1998.  http://www.w3.org/TR/1998/REC-
+         xml-19980210.
+
+   [12]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
+         3023, January 2001.
+
+12.  Author's Address
+
+   Keith Moore
+   University of Tennessee
+   Computer Science Department
+   1122 Volunteer Blvd, Suite 203
+   Knoxville TN, 37996-3450
+   USA
+
+   EMail: moore@cs.utk.edu
+
+
+
+
+Moore                    Best Current Practice                 [Page 13]
+
+RFC 3205                     HTTP Layering                 February 2002
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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 implementation may be prepared, copied, published
+   and 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                    Best Current Practice                 [Page 14]
+