is an Internet Draft (Work In Progress) by Keith Moore and Patrik
Faltstrom. It "relates current IESG and IAB thinking on technical
particulars of [using HTTP as a substrate for other application-level
protocols], including use of default ports, URL schemes, and HTTP
security mechanisms. This thinking is subject to change as discussion
continues and more experience is gained with such use."
A very interesting read. Here is the I-D's summary of IESG Policy
regarding reuse of HTTP:
1. All standards-track protocols must 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
2. New standards-track protocols - including those using HTTP - must
not attempt to circumvent users' firewall policies, particularly by
masquerading as existing protocols. "Substantially new services"
will not be allowed to re-use existing ports.
3. New services should use new URL types.
4. Each new protocol specification that uses HTTP as a substrate must
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 the state of the
Read the I-D for more information about each of these points.
When you start community-building, what you need to be able to present
is a plausible promise. Your program doesn't have to work particularly
well. It can be crude, buggy, incomplete, and poorly documented. What
it must not fail to do is convince potential co-developers that it can
be evolved into something really neat in the foreseeable future.
-- Eric S. Raymond, The Cathedral and the Bazaar