Re: TBTF: Proposed Sections for Binding Specifications

Hi Highland Mary.

* Mountain, Highland M <highland.m.mountain@intel.com> [2001-07-20 12:10-0700]
> Below is a proposed list of needed sections for any binding specification
> document.  I arrived at this list by reading several of the WG email threads
> as well as the binding examples.  The proposed sections are as follows(are
> there others?):
> 
> Referenced Protocol Specification Documents (RFC's, etc)
> MEP - Message Exchange Patterns Supported
> SOAP Encapsulation - MIME, etc
> Compression

I see compression as either:
- an encapsulation: the SOAP message is in a part of a MIME message
  and has been gzipped.
- a characteristic of the transport: e.g. HTTP/1.1 allows the content
  to be encoded in a certain way, in this case compressed.

Is there a need for an extra section?

> Security - can be called out separately, but also could be referenced
> throughout document
> 
> Reliable Messaging

> 	Message Addressing
> 	Message Correlation

I am not sure that these two ones should be under reliable messaging.

> 	Sending Message Behavior
> 	Receiving Message Behavior
> 	Generating an Acknowledgement Message
> 	Resending Lost Messages and Duplicate Filtering 
> 	Duplicate Message Handling
> 	Failed Message Delivery
> 	Message Order Preservation
> 	Message Delivery/Failure Notification
> 	Split Messages
> 
[ Moved the section on error reporting below ]
>
> If any of the above sections do not apply to the protocol in question, it
> would be omitted or listed as not applicable.

I am worried about proposing such a list, i.e. pretty complete but not
exhaustive (it is difficult to be exhaustive regarding the
capabilities of every transport that people can come up with).

For example, assuming that the sending message behavior under reliable
messaging doesn't cover it (I do think that it is not related to
reliable messaging), what about the characterization of quality of
service for sending messages with different policies:
- fastest way.
- least number of hops.
- cheapest (based on some financial input) way.
- etc.

I would be more comfortable with drawing a list of mandatory features
to specify, and leaving the rest open to binding designers.

> Error Reporting and Handling
>       Error Types (Bound Protocol Delivery) and Handling
>       SOAP Fault Types and Handling
>       Reporting Errors

The first point seems to be about errors at the underlying protocol
layer. Shouldn't this be covered by the specification of the
underlying protocol used? In other words, SMTP deals with its own
errors (e.g. retries in case of a temporary error and fails for good
in case of a permanent error) and reports to the XMLP layer whether it
succeeded to do what it was asked to do (or at least it thinks it did,
i.e. without going into DSN, MDN, etc) or not.

The 2 last ones sound to me like: how tight the underlying protocol
semantics and the underlying protocol semantics are tied together,
like Mark Baker described it[2], which is definitely something we
should answer, either for each binding separately or in a general way.

My smaller list adapted from yours would be:
- transport protocol used:
  HTTP/1.1, SMTP, BEEP, etc; how to use it.
  I think that the SOAP/underlying protocols semantics relationship
  would be explained here.
- encapsulation:
  ranging from straight XML angle-bracketty serialization to MIME and
  co, maybe compression, etc.
- MEPs supported:
  one-way, request/reply, etc.
  Implicit message correllation, for example, could fall into that
  category.

Hmmm... after writing that, I realize that my list is awfully small...

Anyway, people could then add to this list the extra features provided
by their binding.

Comments?

  1. http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0206.html
  2. http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0241.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Thursday, 26 July 2001 12:06:40 UTC