WDIFF

draft-moore-using-http-00.txt --> draft-moore-using-http-01.txt-32378.txt

Internet-Draft University of Tennessee
4 May
16 October 2000
Expires: 4 November 2000 16 April 2001

On the use of HTTP as a Substrate for Other Protocols

draft-moore-using-http-00.txt

draft-moore-using-http-01.txt

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html

Comments regarding this internet-draft should be sent to the
author, whose address appears below. Please include the document
identifier draft-moore-using-http-01.txt in all correspondence.

Abstract

Recently there has been widespread interest in using Hypertext
Transport 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
Transport Protocol (HTTP) [1] as a substrate for other applications-
level protocols. Various reasons cited for this interest have included:

o familiarity and mindshare,

Moore Expires 4 November 2000 16 April 2001 [Page 1]
HTTP Layering INTERNET-DRAFT 4 May 16 October 2000

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.

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.

Moore Expires 16 April 2001 [Page 2]
HTTP Layering INTERNET-DRAFT 16 October 2000

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

Moore Expires 4 November 2000 [Page 2]
HTTP Layering INTERNET-DRAFT 4 May 2000
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. Even if existing HTTP client and
server code can often be re-used, the additional complexity of HTTP over
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

Moore Expires 16 April 2001 [Page 3]
HTTP Layering INTERNET-DRAFT 16 October 2000

same secret (or password) is used for several applications. (Similar
concerns exist with TLS based clients or servers - if a public key is descended from SSL, which was
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 - not the other way around. Even though
TLS now provides mutual authentication, clients, so that a client user could be assured
(for example) that needs to talk his credit card number was not being sent to
multiple servers must still know which credentials an
imposter. However, many applications need to present authenticate clients to each

Moore Expires 4 November 2000 [Page 3]
HTTP Layering INTERNET-DRAFT 4 May 2000

server before establishing a secure connection
servers, or to the server. Client provide mutual authentication of client and server must each use private keys that are trusted by the other
party - typically because they are signed by server. TLS
does have a certificate authority
(CA) known capability to the other. As provide authentication in the digest each direction, but
such authentication case, both
client and server need ways to protect their private keys against
exposure. may or may not be suitable for a particular
application.

Web browsers typically which support TLS or SSL are typically shipped with
the public keys of several
CAs 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. This deployment model does
not necessarily For this to work well for other applications, and 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 trusted by browser vendors
(and by users of those browsers), and each of those CA's keys would need
to be "wired into" popular browsers. Those CAs would also have a more
difficult time verifying the identities of ordinary users than they do
in verifying the identities 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 doesn't provide
any way for 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 verify
establish a client's identity. Even if secure connection to the
client's CA is recognized by server.

For the server, this doesn't necessarily convey
authorization reasons stated above, client authentication is rarely used
with TLS. A common technique is to use TLS to authenticate the service. Existing clients server
to the client and servers may
therefore lack to establish a private channel, and for the mechanisms needed client to
authenticate to the server using some other means - for robust authentication example, a
username and password using TLS HTTP basic or SSL and HTTP. digest authentication.

For any application that requires privacy, the 40-bit ciphersuites
provided by some SSL implementations (to conform to outdated US export
regulations)

Moore Expires 16 April 2001 [Page 4]
HTTP Layering INTERNET-DRAFT 16 October 2000

regulations or to regulations on the use or export of cryptography in
other countries) are unsuitable. Even 56-bit DES encryption, which is
required by TLS, has of conforming TLS implementations, has been broken in a matter
of days with only 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.

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 - only
besides HTTP. Many of the limitations of TLS and digest authentication
also apply to other authentication and privacy systems. The point here
is that they are not neither TLS nor digest authentication is a "magic pixie dust"
solution to
either authentication or privacy. An In every case, an application's
designers should must carefully determine the application's users' requirements
for authentication and privacy before automatically choosing TLS an authentication or digest
authentication.
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 even if TLS and/or digest are suitable for an application, this does it is not imply that necessary to use HTTP should be used. 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 Proxies, Firewalls, and Firewalls NATs

One oft-cited reason for the use of HTTP is its ability to pass
through proxies proxies, firewalls, or firewalls. Firewalls are an network address translators (NATs). One
unfortunate consequence of the Internet's explosive growth, in firewalls and NATs is that they decrease the
deployability of make it
harder to deploy new Internet applications, by requiring explicit
permission (or even a software upgrade) 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 whether or not new

Moore Expires 4 November 2000 [Page 4]
HTTP Layering INTERNET-DRAFT 4 May 2000

protocols should be "firewall-friendly", they should definitely not be
"firewall-hostile". In particular, new protocols should not attempt 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 existing security policy. policy is not an acceptable justification
for doing so.

It would be desirable useful to establish guidelines for "firewall-
friendly" "firewall-friendly"
protocols, to make it easier for existing firewalls to be compatible

Moore Expires 16 April 2001 [Page 5]
HTTP Layering INTERNET-DRAFT 16 October 2000

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?

o Is this new protocol usable by existing web browsers without
modification?

o Are

(In other words: will the existing HTTP security mechanisms appropriate for payload size be worth the overhead asso-
ciated 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.

Moore Expires 16 April 2001 [Page 6]
HTTP Layering INTERNET-DRAFT 16 October 2000

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

Moore Expires 4 November 2000 [Page 5]
HTTP Layering INTERNET-DRAFT 4 May 2000
underlying service.

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 "type" kind of resource or service. This service which is used, for instance, by being accessed. For example,
web browsers that typically provide a different response when a user mouse-clicks 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. A 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 type. 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, 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.

Moore Expires 16 April 2001 [Page 7]
HTTP Layering INTERNET-DRAFT 16 October 2000

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
should not be propagated. 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. Authentication or other connection setup
information should be communicated in URL parameters, rather than in the
URL prefix.

Moore Expires 4 November 2000 [Page 6]
HTTP Layering INTERNET-DRAFT 4 May 2000

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 gen-
eral 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 If Should MIME multipart or message types be allowed? This can be an
advantage if it is at all useful to be able desirable to use incorporate (for example) the same payload over
email, mul-
tipart/alternative construct or the differences between HTTP encoding of MIME security framework. On
the payload other hand, these constructs were designed specifically for use
in store-and-forward electronic mail systems, and
email encoding of the payload should be minimized. Ideally, there
should other mechanisms
be no differences in the "canonical form" used in appropriate for the two
environments. Text/* media types can be problematic in this regard 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 Expires 16 April 2001 [Page 8]
HTTP Layering INTERNET-DRAFT 16 October 2000

o Different "commands" or "operations" 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 con-
tent-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 dif-
ferent operations on the same kind type of object object, this can be communicated communi-
cated in a number of different ways, including different ways: HTTP methods, different Content-Types, different Content-Type
parameters, HTTP request-
URI, HTTP request headers, the MIME Content-Disposition header
field, or inside the payload.
Different protocols have solved this problem in different ways.
Again, if it's desirable to provide the same services over elec-
tronic mail, the means as part of communicating the operation should ide-
ally be the same in both environments. 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. This The use of new methods may be useful, 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 prime 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

Moore Expires 4 November 2000 [Page 7]
HTTP Layering INTERNET-DRAFT 4 May 2000 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 may need 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 need,
when invoking an HTTP client library, to translate its URLs of
the form from
"xyz://host/something" format to "http://host:###/something" for the
purpose of calling the existing HTTP client 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.

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

Moore Expires 16 April 2001 [Page 9]
HTTP Layering INTERNET-DRAFT 16 October 2000

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 URL http: prefix when the request is communicated to
the origin server.

Existing clients HTTP client libraries and servers will transmit "HTTP/1.1"
(or a different version) in requests and responses. To facilitate reuse
of
existing code, protocols layered on top of HTTP must such libraries and servers by a new protocol, such a protocol may
therefore need to transmit and accept "HTTP/1.1" rather than their its own
protocol name and version number. This 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 change 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 future if client libraries and servers
gain more flexibility.

For 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.

Use of HTTP's error codes is problematic when the layered
application does not share same notion of success or failure as HTTP.

Moore Expires 16 April 2001 [Page 10]
HTTP Layering INTERNET-DRAFT 16 October 2000

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 necessary to require classified as either "complete success" or limit
"complete failure" may use of certain HTTP features, 200 and 500 for example, to defeat caching of
responses by proxies. Each protocol layered on HTTP those conditions,
respectively. However, the specification for such an application
must therefore
specify define the specific way mechanism which ensures that HTTP its successful (200)
responses are not cached by intermediaries, or demonstrate that
such caching will be used, do no harm; and in particular, how it must be able to operate even
if the message-body of an error (500) response is not transmitted
back to the client and server should interact with HTTP proxies.

HTTP's three-digit status codes were designed intact.

o A layered application may return a 200 response code for use with
traditional HTTP applications, both
successfully processed requests and may errors resulting from the
request message-body (but not be suitable to communicate from the specifics request headers). Such an
application must return its error code as part of errors encountered in 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 applications. HTTP status
codes than 200 should therefore not be used to indicate subtle errors of layered
applications. They should be re-used only to indicate errors
with, or the status of, the HTTP protocol layer; layer (including the
request headers), or to indicate the inability of the HTTP server
to communicate with the application server.

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.

Moore Expires 4 November 2000 16 April 2001 [Page 8] 11]
HTTP Layering INTERNET-DRAFT 4 May 16 October 2000

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.
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 to re-use reuse existing ports.

3. New In general, new protocols or services should use new not reuse http: or
other URL types. 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 define their own error reporting mechanisms,
and use HTTP status codes only for communicating follow the state guidelines in section 8 regarding
use of the HTTP protocol.

9. 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.

10.

11. Author's address

Keith Moore
University of Tennessee, Knoxville
104 Ayres Hall Tennessee Computer Science Department
1122 Volunteer Blvd, Suite 203
Knoxville TN, 37996-1301 37996-3450
USA
email: moore@cs.utk.edu

Moore Expires 4 November 2000 16 April 2001 [Page 9] 12]
HTTP Layering INTERNET-DRAFT 4 May 16 October 2000

11.

12. References

[1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1.
RFC 2616, June 1999.

[2] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A.
Luotonen, L. Stewart. HTTP Authentication: Basic and Digest
Access Authentication. RFC 2617, June 1999.

[3] T. Dierks, C. Allen. The TLS Protocol Version 1.0. RFC 2246,
January 1999.

[4] J. Postel, J.K. Reynolds. Telnet Protocol Specification. RFC 854,
May 1983.

[5] J. Postel, J.K. Reynolds. File Transfer Protocol. RFC 959, October
1985.

[6] J. Postel. Simple Mail Transfer Protocol. RFC 821, August 1982.

[7] J. Myers. Simple Authentication and Security Layer (SASL). RFC
2222, October 1997.

[8] R. Petke, I. King. Registration Procedures for URL Scheme Names.
BCP 35, RFC 2717, November 1999.

[9] N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types. RFC 2046, November 1996.

[10] T. Howes, M. Smith, F. Dawson. A MIME Content-Type for Directory
Information. RFC 2425, September 1998.

[11] T. Bray, J. Paoli, C. M. 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] E. Whitehead, M. Murata. XML Media Types. RFC 2376, July 1998.

Moore Expires 4 November 2000 16 April 2001 [Page 10] 13]

----