Re: Proposal for a protocol binding model


Please see my comments below.




Henrik Frystyk Nielsen wrote:
> We could but bindings may not be nestable without tweaking and nested
> bindings may not always expose all properties of the nested bindings. An
> example of the former is the SOAP attachment binding that when used in
> combination with the HTTP binding may force another media type simply
> because MIME multipart/related has another media type than a plain SOAP
> message. An example of the latter could be the RPC convention over SMTP
> not exposing the SMTP property of sending a one-way message.

Depending on how the binding is specified, this may be true. However,
in the proposal I offered a while back [1], I accounted for support
of any media type over the HTTP binding. Thus, the binding is more
flexible and can be "nested" with any encapsulation "bindings"
that might be developed.

Defining this binding in terms of input and output "properties"
would possibly help clarify things. I would imagine that the
binding I specified would require as input the following properties
in addition to any others that we might think of:

	- next-node-delivery-uri
	- media-type
	- media-type-encoded-message-bytes
	- media-types-supported

These properties would be mapped onto the HTTP protocol accordingly:
	Request-URI = next-node-delivery-uri
	Accept: <media-types-supported>
	Content-Type: <media-type>
	message-body = <media-type-encoded-message-bytes>

> With a list comes also the need for a substantially more complicated
> negotiation mechanism: I can do A,B,C but not A,C along with the notion
> of figuring out which combinations are supported and what the exposed
> set of properties are.

See my proposal on this matter as well. It would be assumed that
the recipient of the original message (the HTTP POST) would have
advertised its capabilities via some mechanism such as WSDL or
an ebXML CPP/CPA and provides for the HTTP client to advertise
its capabilities in a manner that is consistent (IMO) with use
of the HTTP protocol via use of the HTTP Accept header. By defining
(or rather specifying) use of the 415 Unsupported Media Type
HTTP client error status response, a server receiving a request
that it doesn't grok can effectively provide a means for negotiation
with the client.

> From a simplicity point of view, I would tend to say that knowing the
> set of available combinations and how they behave is not nearly as
> straight forward as knowing a list of URIs where somebody else has
> described the relationship to other bindings.
> Henrik
> >You consider a combination of bindings (e.g. SMTP+RPC) as a
> >new binding requiring a new identifier.
> >
> >Once people have come up with lots of different nested
> >bindings (attachments, RPC, maybe compression, etc), the
> >number of combinations will be fairly high, and a URI for each
> >of them might become unworkable.
> >
> >Presumably, the binding (and unbinding) of the SOAP message
> >will have to be an ordered operation: e.g. XML Infoset -> XML
> >serialization -> MIME multipart -> SMTP.
> >
> >What about an ordered list of URIs for a combination of bindings?

Received on Tuesday, 21 August 2001 10:52:44 UTC