W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

RE: [TBTF] proposed edits for incorporating conneg feature for HT TP binding

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 4 Apr 2002 10:42:38 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192A7F@0-mail-1.hpl.hp.com>
To: "'Noah Mendelsohn/Cambridge/IBM'" <noah_mendelsohn@us.ibm.com>
Cc: "'Christopher Ferris'" <chris.ferris@sun.com>, Marc Hadley <marc.hadley@sun.com>, xml-dist-app@w3.org
Hi Noah,

[I'm writing yet another note on this because my attendance on today's TBTF
call is in doubt].

So... I think the piece that I have a problem with is not so much creating a
bunch of individual bindings with distinguished names... I could go either
way on that. The piece that leaves me uncomfortable is pulling conneg out as
a feature that is 'exposed' to the SOAP Node (by that I mean the entity that
uses the binding).

I am very happy that the HTTP binding should make use of the conneg
capabilities of HTTP, I just don't think we should be exposing them as a
feature to the SOAP Node.

I'd be quite happy (I think) to define this binding such that all request
messages and all response messages are framed with:

	- content-type set to "application/soap+xml" 
	  (ie. *this* binding does *not* support attachments) AND

	- that we specify the use of the Accept: header such that *if* 
	  sent with a request messsage it MUST include 
	  "application/soap+xml" (or maybe more narrowly 
	  specify only "application/soap+xml") AND

	- if present in a request message received at a responder 
	  the Accept header MUST contain at-least "application/soap+xml" 
	  (for compatibility) and MAY contain other additional content 
	  types (for extensibility).

I think that we then add a Note along the lines of:

"Note: Future HTTP bindings that may support features such as attachments
[+other example features] may support a wider range of content-types than
"application/soap+xml". To be interoperable with this binding, such future
bindings MUST be capable of receiving HTTP entity bodies will content-type
"application/soap+xml" (see [12]). In addition, such bindings SHOULD/MUST(?)
include "application/soap+xml" in the list of acceptable content-types
expressed in an HTTP request Accept header. Different future HTTP bindings
that make different choices about the mechanisms used to deploy additional
features, such as attachments will be able to interoperate at a basic-level
in circumstances that do not require the use of the additional feature. eg.
one binding specification may specify SOAP over DIME [ref DIME over SOAP ]as
its attachment serialisation mechanism while different binding specification
may specify SOAP over multi-part MIME [ref SwA]. These two bindings will be
able to interoperate in all circumstances that do not require the exchange
of attachments."

I hope this makes sense. I think this is a hybrid of the two apparent
positions that use HTTP conneg without exposing it as a feature and that
defines a binding with clear conformance requirements and interop
expectations, but requires the definition of additional, interoperable,
bindings to add features like attachments.

If you like the direction then the note can be wordsmithed with closer
attention to the use of MUST/MAY/SHOULD. If not, I like you, will "...go
with whichever approach has a preponderance of support...".

Best regards

Stuart

> -----Original Message-----
> From: Noah Mendelsohn/Cambridge/IBM 
> [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 03 April 2002 20:53
> To: Williams, Stuart
> Cc: 'Christopher Ferris'; Marc Hadley; Williams, Stuart;
> xml-dist-app@w3.org
> Subject: RE: [TBTF] proposed edits for incorporating conneg 
> feature for
> HT TP binding
> 
> 
> Well, if the choice were mine alone I think I would still go with the 
> tighter definition of our binding.  At this point in the WG's work, I can 
> compromise in the interest of moving forward.  Both positions have been 
> clearly stated, and I do see merit in both.  I suggest we go with 
> whichever approach has a preponderance of support, which may well be the 
> "looser" one.  Of course, if someone else has a lie-down-in-the-road 
> position either way, that needs to be resolved.  I don't, but my feeling 
> is moderately strong, but I could well be wrong. 
> 
> So I suggest we move ahead.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
Received on Thursday, 4 April 2002 04:46:41 GMT

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