Re: Requirements for reliable message delivery

John,

I'd like to phrase my concerns about HTTPR (recognizing that this draft
is likely a prelude to its submission) in the form of an example.

Suppose I've got a resource, say my thermostat, that I want to interact
with via HTTP.  I can send it a PUT message, explicitly setting the
target temperature of the thermostat to 21C, like so;

PUT http://example.org/mythermostat/
Content-Type: application/xml
<temperature type="absolute" units="celsius">21</temperature>

In this context, reliability means ensuring that my thermostat is set
to 21C.  As HTTP is a state coordination language, even if my PUT
request lost the connection after the PUT was performed, I have choices.
I can check the state of the thermostat with a GET to see if it's set to
21C, or I can re-invoke the PUT, which works because PUT is idempotent.

That was partly for context, to show that HTTP has its own reliability
characteristics that have to be considered.  Non-idempotent methods such
as POST are the tough ones, so let's look at it.

Let's say I want to bump up the current temperature of the thermostat by
one degree C, for whatever temperature it's currently set at.  I can do
that with;

POST http://example.org/mythermostat/
Content-Type: application/xml
<temperature type="relative" units="celsius">1</temperature>

You're entirely right that there is currently no way for the sender to
know if the recipient processed that message, in the case where the
connection drops after the message is processed.  But consider a small
extension;

POST http://example.org/mythermostat/
Content-Type: application/xml
Message-Id: 74293847298374
<temperature type="relative" units="celsius">1</temperature>

Here, "Message-Id" uniquely identifies an instance of a message, and
can be used by consenting parties to add idempotency to POST ...
though, without prior agreement, you'd want to use a mandatory extension
feature such as that provided by M-POST in RFC 2774 to ensure that
Message-Id isn't ignored.  With this, I can simply re-POST the message
until I get a 2xx response.

This example doesn't draw a complete picture of what reliability means
in the context of HTTP, but hopefully it's enough to describe why I
believe HTTPR is taking the wrong approach.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Tuesday, 4 December 2001 13:27:07 UTC