RE: Getting no REST

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 05 March 2002 16:04
> To: skw@hplb.hpl.hp.com
> Cc: xml-dist-app@w3.org
> Subject: Getting no REST

<snip/>

> No, it's still a protocol, in that mustUnderstand, actor, and the
> end-to-end model defined with them, comprise extended agreement
> required to permit a priori communication.  This is (roughly) the
> definition of a protocol.
> 
> A litmus test of whether something is a protocol or not, is whether the
> thing has faults.  If it does, it's a protocol.  If not, it isn't.
> This works because faults are a by-product of agreement.

I guess I'd apply a different litmus test... I'd look to Gerard Holtzmann,
"Design and Validation of Computer Protocols" [1]. Don't have my copy to
hand, he identifies 5 facets of a protocol:

a) A service definiton - an abstraction of what it does.
b) A vocabulary of messages (abstract) exchanged between protocol entities.
c) A concrete encoding of the message set.
d) Rules of procedure - the behavioural rule for the protocol entities 
   that exchange protocol messages.
e) Environmental assumptions - delay, loss and ordering properties of
whatever
   the protocol is built on - often evident in the service defn of the next
   protocol down.

I think we could identify all of these pieces for HTTP. I'm less confident
that we could for SOAP. However, I think I'll buy the point that you make
that the SOAP processing model has some behavioural rules that should be
evidenced through the generation of faults - which should be externally
visible. A question I would ask is how do we know that the design of SOAP is
correct if we don't articulate what it is intended to do, a) above?

[1] http://cm.bell-labs.com/cm/cs/who/gerard/popd.html

<snip/>

> That's a good characterization.  Another way of saying it is that the
> chameleon view exposes the application model in use, whereas tunneling
> hides it.
> 
> I think this explanation goes a long way to explaining why the tunneling
> view disregards Web architecture.  The Web is an application, and
> tunneling over it disregards that application and all the rules and
> constraints that were built into it (Tim's axioms).

I have a hard time with this one. We have spoken of this before. Taking a
narrow view the application of HTTP is the creation, manipulation and
retrieval of resource state - i think just saying the "Web is an
application" is a bit vague. 

I can see buying a book from Amazon, or booking an airline ticket, or
searching for information (eg. Google) as applications, Web Applications.
They are not "The Web", but they are done on the Web. There is an argument I
think, that says that the Web is infrastructure for these applications. The
user of these applications does not think in terms of manipulation of
resource state. They think in terms of the application domain task they are
trying to accomplish. It is likely that a well designed application will
model its state as a collection of related resources and be highly sensitive
to the architecture of the Web. So, if (note the predicate) I then go on to
say the Web Application I want to build is messaging infrastructure to
support the exchange of messages between application entities that I might
identify with URI's and regard as resources (the application entities), then
I hope I (we) could find away to do that in an HTTP Web environment, that is
every bit as 'well designed' from a resource modeling point of view as the
best designed web applications. Then, viewed as a collection of resources
whose state is being manipulated, I might hope that the result does not
violate the TBL axioms...

> > So we have two communities (at least) pulling toward these different
> > extremes. 
> > 
> > I think that one reasonable viewpoint is that one can 'do' HTTP and
> > simply(?) use SOAP for the content-type of the of an HTTP
request/response
> > entity body. This *is* HTTP, no binding required.
> 
> A binding is required in the chameleon view because 1) you have to know
> how to map SOAP faults into the fault model of the application protocol,
> and

I guess we have a limited number of top level fault codes, but we have an
open model for sub-codes. I don't think we could articulate a mapping for
all asserted faults to HTTP status codes ie. we couldn't just look at the
message and know what status code to apply, we would have to understand the
semantics of the faults which really means that the application has to
decide the appropriate fault code and at the time of writing the SOAP spec,
we will be unable to define this mapping, only, perhaps, the principle upon
which applications should make the choice. Anyway, it amounts to exposing
the HTTP status code directly to the application. Wrt to your original
question one use/quoting of faults, its just the same, its the application
sending the fault that knows what it intends and needs to make the
appropriate choice.

> 2) you have to know which parts of the application model of the
> underlying protocol is being reused.  For example, we currently only
> define a POST binding, which means that we can't do replacement-type
> stuff, since HTTP PUT is required for that, nor can we do retrieval,
> since GET is used for that.
> 
> > However, in the Messaging/Tunneling view you do need a binding to
establish
> > how messages are exchanged between messaging endpoints. Of course you
then
> > need to establish the (binding independent) semantics of your messaging
> > system (what messaging operations does it support and what are their
> > semantics)
> 
> Ah, see, there's the rub.  Application protocols *already* define those
> semantics for you (some being more general than others).  The chameleon
> view reuses them, whereas the tunneling view ignores them and reinvents
> new ones.

I don't think I've seen anything in HTTP that attributes any semantics to a
particular resource or resource representation. A well specified sequence of
resource manipulations intended to achieve some effect (place books in a
shopping cart and pass through a checkout) is itself an application
protocol.

> > - and an account that describes how the semantics of message
> > transfer are accomplished as a pattern of resource state manipulations.
eg.
> > these resources represent intermediary-points and end-points in a
messaging
> > system, and that the effects of  HTTP are to transfer messages that are
> > either immediately processed yielding an immediate result (200), or that
are
> > accepted as subordinates (201) (an entry in a queue at the endpoint).
> > 
> > I have a concern that we may be trying to align messaging semantics and
HTTP
> > semantics so tightly that ultimately we fail to define a messaging
system
> > and all we end up with is SOAP as a content-type for HTTP.
> 
> I don't know what a "messaging system" is, nor do I believe the WG
> could ever agree on that.

Ironic really. You might think of the US Postal service or Fedex as
messaging systems... or you might prefer to think of them in terms of
manipulation of resource state. The irony is that the illusion of a share
web space for resources comes about through the exchange of messages. Much
of society functions on the exchange of messages which themselves cause the
state of some things to change.
 
> Also, as I've tried to reiterate many times, I'm not trying to align
> anything with HTTP semantics, except for the HTTP binding.  I'm trying
> to say that the big value add of SOAP is where it is used in a way
> that, at each hop in a path, reuses the application model in use for
> that hop.
> 
> An example ...
> 
> Suppose I want to build a SOAP/HTTP based interface to email.  I would
> build a SOAP/HTTP node that accepted a message in over POST, and then
> sent it out over DATA.  So I could do;
> 
> POST skw@hplb.hpl.hp.com HTTP/1.1
> Host: marks-email-gateway.markbaker.ca
> Content-Type: application/soap+xml
> Content-Length: 1234
> From: distobj@acm.org
> 
> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
>  <env:Body>
>  Hi Stuart, how are you?
>  </env:Body>
> </env:Envelope>
> 
> and then my software would convert that to;
> 
> HELO marks-email-gateway.markbaker.ca
> MAIL FROM: distobj@acm.org
> RCPT TO: skw@hplb.hpl.hp.com
> DATA
> [headers..]
> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
>  <env:Body>
>  Hi Stuart, how are you?
>  </env:Body>
> </env:Envelope>
> .
> 
> That's what a SOAP HTTP/SMTP gateway would do.  The value of SOAP as a
> protocol here is the extended end-to-end model; that I could include
> extension headers that I require that your end understand (assuming
> your receiving SMTP processor dispatches on one of the headers we
> included - note to self, see what email binding does here).

So... in this example, what goes in the HTTP POST response? How long does
the gateway wait to decide?

What happens if the email system spits out a delivery failure message eg.
been trying to deliver for 3 days and will keep going for another 8 days?

As it happens i think that the one-way message with causality/correlation
that we ended up with in the AM is very powerful, much more powerful than
the request/response pattern that we currently have in the spec.

> > > For sure, and I'd rather not have to enumerate these.  That's why I
> > > think it's easiest to use broad strokes and say that *if* a response
> > > includes a body *and* uses any 4xx or 5xx response code, then it is a
> > > fault ...
> > 
> > So wrt 4xx status codes, 2616 states:
> > 
> > <quote>
> >    Except when responding to a HEAD request,
> >    the server SHOULD include an entity containing an explanation of the
> >    error situation, and whether it is a temporary or permanent
> >    condition. These status codes are applicable to any request method.
> >    User agents SHOULD display any included entity to the user.
> > </quote>
> > 
> > I think that there is a mismatch of expectations here if the entity body
is
> > a SOAP fault ;-)
> 
> How so?  You mean the "display" bit?  It's not hard to build a browser
> plug-in, or an intermediary, that could display a fault.

Yes... the display bit, there was a smilie there. But it is symptomatic of
the human-centred nature of the HTTP based Web (that's not critiscism). HTTP
is full of sensitivity for the human client of the web... which is a good
thing for human clients, but a little more problematic for machine clients
(for extended information beyond the status code).
> 
> > > I agree that there are different POVs, and that MUST is the right
> > > conformance level here, but that still doesn't say what the
> > > authoritative determinant of a fault is.
> > 
> > Well, it would say that one party is non-compliant... ie is broken. They
are
> > in error. If you proceed at all, proceed with caution. Maybe throw your
> > hands up in horror and refuse to play because you have received
something
> > invalid... as broken as badly formed XML.
> >
> > One could produce a ruling one way or the other for these non-conformant
> > cases, but which way to make the rule is open to debate. 
> 
> Hmm.. But there's no "parties" here, it's a single message that asserts
> two conflicting things; "I'm a fault", "I'm not a fault".

Ok.... there are four cases and I focussed on the wrong case (FIM=fault in
message; FRP=Fault reported by underlying protocol):

	FIM	FRP
	0	0	Clearly no fault!
	0	1	In consistency=>non-conformant message creator.
	1	1	Clearly a fault!
	1	0	see below.

Personnally, I think I would prefer the quotedness of the fault to be
apparent within the message itself in which case I would regard this last
case as non-conformant ie. if there is an unquoted fault in the message, its
a fault and if the fault is quoted (wrapped) then overall the message is not
a fault.

I suspect that your preference would be to make the FRP authorative, as a
means to quote faults rather than assert them.

> Are you suggesting that a fault be generated if such a fault is
> received?

Melt-down warning... ;-)... definitely not.

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

Stuart

Received on Tuesday, 5 March 2002 12:49:58 UTC