Browse Prior Art Database

On the use of HTTP as a Substrate (RFC3205)

IP.com Disclosure Number: IPCOM000006947D
Original Publication Date: 2002-Feb-01
Included in the Prior Art Database: 2002-Feb-12
Document File: 15 page(s) / 35K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Moore: AUTHOR

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 10% of the total text.

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