TBTF: Proposed Sections for Binding Specifications

All,

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
Security - can be called out separately, but also could be referenced
throughout document

Reliable Messaging
	Message Addressing
	Message Correlation
	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

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

If any of the above sections do not apply to the protocol in question, it
would be omitted or listed as not applicable.


A colleague of mine passed along a document from members of an ebXML sub
group.  This sub group is made up automotive industry IT professionals.
The group is creating a specification or guideline on how to transport ebXML
messages over SMTP, HTTP, etc. Below is a much abridged version of this
specification document, calling out the sections covered to solve the
binding problem. I AM NOT SHARING THIS INFORMATION FOR THE TECHNICAL DETAIL,
but more of a structural example to communicate a solution to the binding
problem.   

Here is the transport binding example from the ebXML automotive industry
subgroup, referenced above:

Packaging Specification

An ebXML Message is a communication protocol independent MIME/Multipart
message envelope, structured in compliance with the SOAP Messages with
Attachments [SOAPATTACH] specification, referred to as a Message Package.
We transmit these using HTTP posts.

There are two logical MIME parts within the Message Package:

	·	A MIME part, referred to as the Header Container, containing
one SOAP 1.1 compliant message.  This XML document is referred to as a SOAP
Message for the remainder of this specification,
	·	zero or more MIME parts, referred to as Payload Containers,
containing application level payloads.
The SOAP Message is an XML document that consists of the SOAP Envelope
element. This is the root element of the XML document representing the SOAP
Message. The SOAP Envelope element consists of the following:
	·	One SOAP Header element.  This is a generic mechanism for
adding features to a SOAP Message, including ebXML specific header elements.
	·	One SOAP Body element.  This is a container for message
service handler control data and information related to the payload parts of
the message.
The general structure and composition of an ebXML Message is described in
the following figure.
 <<ebXMLPackage.ZIP>> SOAP Structural Conformance
ebXML Message packaging SHALL comply with the following specifications:
	·	Simple Object Access Protocol (SOAP) 1.1 [SOAP]
	·	SOAP Messages with Attachments [SOAPATTACH]
Carrying ebXML headers in SOAP Messages does not mean that ebXML overrides
existing semantics of SOAP, but rather that the semantics of ebXML over SOAP
maps directly onto SOAP semantics.

Message Package
All MIME header elements of the Message Package MUST be in conformance with
the SOAP Messages with Attachments [SOAPATTACH] specification.  In addition,
the Content-Type MIME header in the Message Package MUST contain a type
attribute that matches the MIME media type of the MIME body part that
contains the SOAP Message document.  In accordance with the [SOAP]
specification, the MIME media type of the SOAP Message MUST have the value
"text/xml."
It is strongly RECOMMENDED that the root part contain a Content-ID MIME
header structured in accordance with [RFC2045], and that in addition to the
required parameters for the Multipart/Related media type, the start
parameter (OPTIONAL in [RFC2387]) always be present. This permits more
robust error detection.

Header Container
The root body part of the Message Package is referred to in this
specification as the Header Container. The Header Container is a MIME body
part that MUST consist of one SOAP Message as defined in the SOAP Messages
with Attachments [SOAPATTACH] specification.

Payload Container
Zero or more Payload Containers MAY be present within a Message Package in
conformance with the SOAP Messages with Attachments [SOAPATTACH]
specification.
If the Message Package contains an application payload, it MUST be enclosed
within a Payload Container.
If there is no application payload within the Message Package then a Payload
Container MUST NOT be present.
The contents of each Payload Container MUST be identified by the ebXML
Message Manifest element within the SOAP Body  (see section 8.11).
The ebXML Message Service Specification makes no provision, nor limits in
any way, the structure or content of application payloads.  Payloads MAY be
a simple-plain-text object or complex nested multipart objects.  The
specification of the structure and composition of payload objects is the
prerogative of the organization that defines the business process or
information exchange that uses the ebXML Message Service.

Security Considerations

Reliable Messaging

	Sending Message Behavior
	Receiving Message Behavior
	Generating an Acknowledgement Message
	Resending Lost Messages and Duplicate Filtering
	Duplicate Message Handling
	Failed Message Delivery

Error Reporting and Handling

Definitions
For clarity, two phrases are defined that are used in this section:
·	"message in error" -  A message that contains or causes an error of
some kind
·	"message reporting the error" -  A message that contains an ebXML
ErrorList element that describes the error(s) found in a message in error.

Types of Errors
One MSH needs to report to another MSH errors in a message in error.  For
example, errors associated with:
·	ebXML namespace qualified content of the SOAP Message document
·	reliable messaging failures
·	security 
Unless specified to the contrary, all references to "an error" in the
remainder of this specification imply any or all of the types of errors
listed above.
Errors associated with Data Communication protocols are detected and
reported using the standard mechanisms supported by that data communication
protocol and do not use the error reporting mechanism described here.

When to generate Error Messages
When a MSH detects an error in a message it is strongly RECOMMENDED that the
error is reported to the MSH that sent the message that had an error if: 
·	the Error Reporting Location (see section 0) to which the message
reporting the error should be sent can be determined, and
·	the message in error does not have an ErrorList element with
highestSeverity set to Error.
If the Error Reporting Location cannot be found or the message in error has
an ErrorList element with highestSeverity set to Error, it is RECOMMENDED
that:
·	the error is logged, and
·	the problem is resolved by other means, and
·	no further action is taken.

Security Considerations
Parties that receive a Message containing an error in the header SHOULD
always respond to the message.  However, they MAY ignore the message and not
respond if they consider that the message received is unauthorized or is
part of some security attack.  The decision process resulting in this course
of action is implementation dependent.

Identifying the Error Reporting Location
Errors are written to an error log on the machine on which the MSH runs.

Service and Action Element Values
An ErrorList element can be included in a SOAP Header that is part of a
message being sent as a result of processing of an earlier message.  In this
case, the values for the Service and Action elements are set by the designer
of the Service.

Security
Transport security 
The ebXML Message Service, by its very nature, presents certain security
risks.  A Message Service may be at risk by means of:
·	Unauthorized access
·	Data integrity and/or confidentiality attacks (e.g. through
man-in-the-middle attacks)
·	Denial-of-Service and spoofing
Application of countermeasures SHOULD be balanced against an assessment of
the inherent risks and the value of the asset(s) that might be placed at
risk.

Security and Management
No technology, regardless of how advanced it might be, is an adequate
substitute to the effective application of security management policies and
practices.
It is strongly RECOMMENDED that the site manager of an ebXML Message Service
apply due diligence to the support and maintenance of its; security
mechanism, site (or physical) security procedures, cryptographic protocols,
update implementations and apply fixes as appropriate.  (See
http://www.cert.org/ and http://ciac.llnl.gov/)

Counter measure Technologies

We secure the message.
Persistent Digital Signature
	Signature Generation
Non-persistent Confidentiality (SSL)


Highland Mary Mountain

Intel Corporation
eBusiness Solutions Lab
(480) 552 - 3817

highland.m.mountain@intel.com