Re: TBTF: nesting

On Thu, Jul 19, 2001 at 09:14:12PM -0400, christopher ferris wrote:
> > 
> > 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.

I'd quibble about the meaning of 'exposed to' and how relevent it is,
but otherwise agreed, and the fact that SSL, etc is provided to HTTP
is a good point. In fact, from a SOAP path viewpoint, all 'services'
(authentication, encryption, caching, etc.) might be hop-by-hop, and
some might be end-to-end, depending on how the SOAP intermediary is
interposed into the transport (as an endpoint vs. as part of the
underlying transport's path). Hmm.


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

Agreed; wasn't meaning to imply that encapsulation solely defines a
binding.

So where does this leave us in terms of describing a binding's
possible relationships? Is it useful to try to categorize bindings,
or describe the permutations that are permitted?


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

Yes; I only meant to say that there needed to be equivalent
mechanisms for typing if MIME-ish ones weren't present.


> > > 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 think this is what Henrik might call "American-style" negotiation;
"this is what I do, if you don't like it, too bad" ;) I should have
said 'description'; negotiation only applies for certain MEPs, of
course.


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

Received on Thursday, 19 July 2001 22:34:45 UTC