Re: TBTF: nesting

Mark,

Please see below.

Cheers,

Chris

Mark Nottingham wrote:
> 
> 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.

While SSL doesn't provide framing, it does provide transient confidentiality
and integrity and optionally can be used to provide authentication of either or both
endpoints which can be used for authorization but may not be sufficient
in and of itself to provide these services through to the application
itself because the authenticated entity is the endpoint which may not be the
originator of a given message such as would be the case of a message received
from a processing intermediary. These services are not provided through
HTTP, they are provided TO HTTP and there is no guarantee that they are
in any way exposed to the application/module that receives the message.

TCP doesn't natively provide framing, but it does provide flow control
and reliability/integrity which UDP does not. I don't think that framing
alone constitutes a definition of a binding. Theoretically, one could
simply stream SOAP envelopes on a TCP connection without any encapsulation
or framing and use a SAX parser to parse the stream to process each message
because the XML provides its own framing of sorts as long as it is well formed;-)

> 
> 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.

Agreed, HTTPR is definitely a hybrid.

> 
> > 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.

What constitutes MIME-like? As long as it can be formally specified and is
given a media type designation the information about the contents
(which might be a nested encapsulation) need not necessarily be
carried within the object. An implicit typing might be applied
by virtue of the specification of the object. If the object could
carry a variety of nested types, then things do become a bit
gnarlier if no provision is given for the nested type to be
self describing such that its type could be inferred.

> 
> > 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.

WSDL defines a web service from the server's perspective. 
It doesn't provide for a client to advertise its preferences/capabilities, 
only the server.

I agree that other negotiation mechanisms should be possible, but 
they should be separate bindings so as to provide for the specification
of the mechanism to be used.

> 
> > <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 21:14:14 UTC