Re: TBTF: nesting

On Thu, Jul 19, 2001 at 08:31:09PM -0400, christopher ferris wrote:
> Mark,
> 
> I see things somewhat similarly, but there are still problems with
> characterizing the lowest level binding as the only one that
> provides services or imposes constraints. For instance, I think
> that it would be difficult to characterize a binding to HTTPR [1]
> because technically, it is a nested binding of
> http->httpr->httpr-payload-message->?
> 
> Also, consider the case of HTTP/SSL. Techically, HTTP is bound to
> SSL yet both provide services. (actually, one could argue that the
> full stack would be HTTP/SSL/TCP/IP each of these provides some
> level of service;-)

I think that the way we'd discriminate is that 'transport' bindings
have to be 'encapsulation' bindings too; SSL/TLS doesn't provide
framing for SOAP messages, therefore it's not a binding on it's own,
but rather a service provided through HTTP (or whatever else can
transit across it). I think this gels nicely with the comments that
on its own, TCP isn't a binding, because it doesn't provide framing.

re: HTTPR - in its current form, HTTPR is somewhat of a cross between
an HTTP extension and a content format. Hopefully, we won't have to
deal with it, but if we did, it would probably be as a separate
binding, IMHO.


> In my proposal, I suggest that an 'encapsulation' binding
> (mechanism is the term I've used) is identified by its MIME media
> type. In the HTTP binding case, the Content-Type header identifies
> the encapsulation binding, with the default binding being none or
> as you cite, the raw binding which is expressed as the MIME media
> type designated for a SOAP envelope, or text/xml.

Agree, as long as the encapsulation format is MIME-like, and the
encapsulating format can carry MIME type information about its
contents. Not a huge constraint, IMHO.


> I also provide for an encapsulation negotiation mechanism using
> the Accept request header which provides for the client to
> express to the server the encapsulation bindings it is capable
> of supporting.

That's one way to do it; another would be through WSDL or somesuch.
We shouldn't require any one negotiation mechanism, but allow many,
IMHO.


> <aside mode="rant"> Of course, I would REALLY like to see a
> formally declared/defined/registered media type for a SOAP envelope
> (such as application/soap+xml) as this would allow for a more
> precise representation. e.g.
> 
> 	Content-Type: multipart/related; type="application/soap+xml"
> 
> there's no doubt as to the representation that this is a multipart/related
> encapsulation binding for a SOAP envelope with attachments.

Agree quite strongly! application/soap+xml is my preference as well.


> Note that both multipart/related and application/dime
> encapsulations are also providing services as they provide for the
> ability to add attachments to the message.

True........ hmm. I think there's a fundamental difference in the
services' characteristics, but I can't quite articulate it.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 19 July 2001 20:40:37 UTC