W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Binding example discussion

From: Mark Nottingham <mnot@akamai.com>
Date: Tue, 17 Jul 2001 13:28:43 -0700
To: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20010717132833.A16951@akamai.com>
There has been some discussion amongst the binding TF regarding
example bindings, to help us discover requirements for defining a
binding. As part of this, I generated a candiate for a HTTP binding
definition.

Find attached a thread regarding this; the first message is my reply
to some of Henrik's comments, and the second is another reply to the
same message, and finally the actual candidate.

Comments welcome.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

attached mail follows:



Thanks for the comments.

> * It is not clear whether you allow something like MIME
> multipart/related - or DIME encapsulations as well?



> * Just as a side note, HTTP doesn't really say anywhere but I would be
> very surprised if not all kind of implementation stuff will break if GET
> requests start to have a body.

IIRC I only documented using GET when there is no soap message to be
sent in the request, so there would be no body in that case.


> * There are situations where other status codes than 204 would be more
> appropriate given the situation and what HTTP dictates. An example is
> 202, or even 200. For example, it should be ok for a service to say that
> it accepts a event notification for example and just responds with a 200
> status code.

Are you saying that some applications will wish to use a 200 status
code with a 0-length body for a response? That seems to me that it's
sticking the application's semantics into the binding, which may or
may not be a good thing. 

It could be listed as a service - i.e., "if you wish to send a
boolean acknowledgement over an HTTP response message without
incurring the overhead of a SOAP envelope, you can send a 200 status
code w/ 0-length body to signal success, and a 403 status code to
signal failure'.

A problem that I very quickly came up against, and which I hinted at
in my previous message, is that it's easy to go overboard with
services - at a not-so-distant point, you start listing all of the
features in the underlying protocol. HTTP is a very featureful
protocol - can we get a sense of the group as to how far the listing
of services should go?

Another thing that should probably be made clear is that
implementations must be able to act in full compliance with the
underlying protocol's specification; implement all of the required
features, etc. It's obvious, but I can very easily imagine someone
only implementing the parts referred to, and leaving out
"unimportant" bits (e.g., host header, redirects, etc.). This would
leave them unable to deal with the mechanisms that might get injected
into message streams by intermediaries, the underlying HTTP
implementation, etc.

I also wonder what implications that has for SOAP compliance... e.g.,
if we documented the 200/403 behaviour, would an implementation need
to expose it, at the SOAP level, to be considered compliant?

This, I think, is where we dance the line between defining a protocol
and defining an API...


> * Regarding fault, do you anticipate to use a specific fault code (like
> 500 for example) to indicate a fault? (I hope so :)

I would have thought you knew my position on that one by now ;)


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

attached mail follows:




On Mon, Jul 16, 2001 at 12:13:47AM -0700, Henrik Frystyk Nielsen wrote:
> 
> Great start - a few quick comments:
> 
> * It is not clear whether you allow something like MIME
> multipart/related - or DIME encapsulations as well?

Realised I didn't answer this question. Not sure how to address this,
it seems like there need to be rules for stacking bindings in this
manner. We'll get into a situation where DIME/MIME is the
highest-level encapsulation, but services and constraints are coming
from a lower-layer binding (HTTP). 

This is why I suggested "blessing" one binding in the stack as that
providing services and imposing constraints; in this case, it would
be HTTP.


> * Just as a side note, HTTP doesn't really say anywhere but I would be
> very surprised if not all kind of implementation stuff will break if GET
> requests start to have a body.

Also realized I didn't explicitly state the method or response code
if a SOAP envelope is encapsulated (which led to this confusion,
sorry); see attached revision.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)



Received on Tuesday, 17 July 2001 16:28:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT