PP14: HTTP as a substrate -- five years later

Lisa Dusseault <lisa@osafoundation.org> Sun, 27 January 2008 20:20 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDzK-0004bg-Ro; Sun, 27 Jan 2008 15:20:22 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JJDzI-0004bZ-VL for discuss-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDzI-0004bR-Li for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJDzI-0004ld-2h for discuss@apps.ietf.org; Sun, 27 Jan 2008 15:20:20 -0500
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8AE22142245 for <discuss@apps.ietf.org>; Sun, 27 Jan 2008 12:20:22 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqjKrlnTm4TD for <discuss@apps.ietf.org>; Sun, 27 Jan 2008 12:20:16 -0800 (PST)
Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5369E142217 for <discuss@apps.ietf.org>; Sun, 27 Jan 2008 12:20:16 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <C498FF77-D1F6-4047-A448-D5625EC5CEA6@osafoundation.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: Apps Discuss <discuss@apps.ietf.org>
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: PP14: HTTP as a substrate -- five years later
Date: Sun, 27 Jan 2008 12:20:11 -0800
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 386e0819b1192672467565a524848168
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

HTTP as a substrate -- five years later

Yves Lafon
Thomas Roessler


Abstract

In this position paper, we revisit some of the questions that BCP 56
addresses, from the point of view of today's technological
environment.


Using HTTP as an element to build protocols

BCP56 provides useful guidance on the use of HTTP as a substrate.
However, the document mixes considerations that arise when extension
points within HTTP are exercised with considerations that arise when
a new protocol is derived from HTTP.  This mix does not contribute
to the document's clarity.

Additionally, some issues that arise in today's environment are not
covered in BCP 56.


The Cost of New Methods

HTTP methods are allocated from a single pool of flat strings;
coining new HTTP methods is therefore inherently costly, as it
requires social coordination.  Use of existing HTTP methods to
underpin protocols that identify the semantics of individual
messages in a way that can be reduced to URI-based extensibility
patterns might often turn out to be lest costly, and ultimately
scale to a broader set of applications.

It can be argued, then, that new methods should only be introduced
when they would be found useful to the Web in general and not
one particular protocol built as an extension of HTTP.

Client Expectations

BCP56 uses a notion of "browser-based HTTP" as one of its criteria.
With the arrival of almost arbitrary socket-style interfaces in
commonly deployed Web Browsers, and with broad use of XMLHttpRequest
in AJAX style applications, that notion has changed fundamentally
over the last five years.  Clients for many TCP/IP based protocols
can be readily implemented using a commonly deployed web browser as
a platform, and almost arbitrary variants of HTTP can be used
readily and on a standardized basis.

As clients are able to automatically trigger HTTP requests,
additional questions might become more critical for the choice of
HTTP as a substrate:

- Does the HTTP-based protocol stick to pre-existing method
   semantics (e.g., safe vs unsafe)?  If a protocol adds semantic
   expectations to existing HTTP methods that are not present in
   these methods' original designs, then that suggests strongly to
   either use a different protocol, or introduce a new method.

- How will the protocol deal with unattended execution of unsafe
   HTTP methods?  In today's browser-based environment, even some of
   the original design constraints on HTTP methods don't hold any
   more.

Server Expectations

BCP56 uses notions such as a "different data set" and "distinct
server processes" as suggestions for criteria that should be taken
into account when deciding whether a separate port should be used
for a new HTTP-based protocol.

In some cases, like WebDAV, new methods were introduced that affect
new data sets, while regular Web cotnent could be served using the
default HTTP method.  Should such protocols run on a different port?

Instead, we suggest that designers of HTTP-based protocols consider
the impact of their design decisions on URI space as a whole.
* Are safe HTTP methods still able to work as intended?
* Does the newly designed protocol rely on specific expectations,
like well-known locations, without injecting a discovery phase?
* Does it involve a completely separated data set?

RESTfulness?

Another dimension in the design of HTTP-based protocols that isn't
addressed in BCP56 is the relation between the newly designed
protocol and the REST design paradigm:  What protocol states should
be identifiable by URI themselves, and what protocol states should
maybe not be addressable?