OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: minutes of feb 01 2001 con-call


Ralph Berwanger
Doug Bunting
Henry Lowe
Gary Morin
Rik Drummond
David Fischer
Robert Adams
Rich Salz
Mike DeNicola 
Ian Jones
Chris Ferris


Discussed and voted on minor technical changes
proposed by Chris. Attached HTML doc highlights the 
disposition of each considered.

Rik indicated that Bob Sutor has re-rasised
the issue of changing ebXML so that our 
framework is based on SOAP1.1 by May 2001. There
was much discussion, mostly surrounding the whole
timing aspects, release of IPR and more
that it was felt that while this is something that
many agree should happen, eventually (with XP)
it is simply not appropriate for us to consider 
significant technical changes at this late date.
4) line 15 - minor technical - we may want to define a process for the development
and registration of communication protocol bindings for ebXML. If we do, then we should
do so before Vancouver. Of course, this will all be relative to what body assumes
stewardship of the specification.

Defer and bring up in Vancouver

6) line 41 & 2473 - minor technical - appendix C - communication protocol bindings
should be made a normative part of the specification. This would be related to
comment #4 above. Without normative protocol bindings, there can be no guarantee
of interoperability between services that leverage the same protocol, but differently.

Appendix A1 (Schema) Normative
Appendix A2 (DTD) Nonnormative
Appendix B (Examples) Nonnormative
Appendix C (Protocol Bindings) Normative
remove appendix A3 (FTP)
Appendix C4 should be incorporated into the specific
protocol binding section (e.g. HTTP and SMTP)
remove Appendix D

12) line 126 - minor technical - proposed description of logical components of MSH are
as follows:

Header Processing - the creation of the ebXMLHeader document for the ebXML Message
uses input from the application, passed through the Message Service Interface, information
from the CPA that governs the message, and generated information such as digital signature,
timestamps and unique identifiers.

Header Parsing - extracting or transforming information from a received ebXMLHeader
into a form that is suitable for processing by the MSH implementation.

Security Services - digital signature creation and verification, authentication and authorization.
These services MAY be used by other components of the MSH including the Header Processing and
Header Parsing components.

Reliable Messaging Services - handles the delivery and acknowledgment of ebXML Messages
sent with deliverySemantics of OnceAndOnlyOnce. The service includes handling for
persistence, retry, error notification and acknowledgment of messages requiring reliable

Message Packaging - the final enveloping of an ebXML Message (ebXMLHeader and payload)
into its MIME multipart/related container

Error Handling - this component handles the reporting of errors encountered
during MSH or Application processing of a message as well as processing of
received messages that have an ErrorList element detailing an error reported
by a foriegn MSH on a message previously sent by the MSH.

Notification - I have no idea what this was supposed to be!

Message Service Interface - an abstract service interface that applications
use to interact with the MSH to send and receive messages and which the MSH
uses to interface with applications that handle received messages.

Accepted with Notification temporarily removed.

17) line 212 - minor technical - have we actually submitted a request for
registration of this MIME type? I have never seen evidence that we have.

Defer, to be addressed in Vancouver. Include registration submission
as an appendix as per Rich Salz suggestion. Dick says he registered
application/vnd.ebxml. Needs to be researched and registration
should be submitted. Dick to submit.

35) line 423 - minor technical - I fail to see why ApplicationHeaders is NOT allowed
when there is an ErrorList that has a highestSeverity of Error. I would suggest that
the only case where ApplicationHeaders is NOT allowed is when there is a StatusData
element because the StatusData is a MSH to MSH message and there is no "application"

Defer to Vancouver.

36) line 431 - minor technical - I fail to see why a StatusData element could not
be accompanied by an ErrorList element, regardless of severity. Suppose the
message being queried had errors but the message reporting the errors was never received?

Defer to Vancouver.

39) line 567 - minor technical - suggest we remove the ID attribute from Header element.
An ID is not much use when there is only a single element matching that type in a
document because there is no need to distinguish between like elements.

Agreed, remove ID attribute from Header element.

49) line 673 - minor technical - there are a number of problems with this section.
Some of the errors are editorial in nature (e.g. use of term 'element' instead
of 'attribute'. There are also some technical issues at play including the
confusion of the use of the term default. The description also erroneously
describes BestEffort as "unspecified", which is wrong.

Finally, I take great exception with the notion that the CPA may be overridden.
The CPA constitutes an AGREEMENT between the two parties. In the case of
deliverySemantics and reliable messaging, you cannot willy-nilly change the
agreed upon behavior. The receiving party may NOT be capable of adapting to the
different deliverySemantics that were agreed upon. Let us not make this specification
any more comlicated than it needs to be.

Suggest we change:

deliverySemantics attribute
The deliverySemantics element, if present, over-rides the value of the
same parameter in the CPA. If it is not present, the value in the CPA
MUST be used.
The deliverySemantics parameter/element MUST used by the From Party MSH
to indicate whether the Message must be sent reliably. Valid Values are:

 OnceAndOnlyOnce. The message must be sent using a
 reliableMessagingMethod that will result in the application
 or other process at the To Party receiving the message once and only once

 BestEffort The reliable delivery semantics are not specified. In this
 case the value of reliableMessagingMethod is ignored.

The default value for deliverySemantics is specified in the CPA. If no value
is specified in the CPA then the default value is BestEffort.
If deliverySemantics is set to OnceAndOnlyOnce then the From Party MSH and
the To Party MSH must adopt the Reliable Messaging behavior (see section
Reliable Messaging) that describes how messages are resent in the case of
failure and duplicates are ignored.
If deliverySemantics is set to BestEffort then a MSH that received a message
that it is unable to deliver MUST NOT take any action to recover or otherwise
notify anyone of the problem, and the MSH that sent the message must not
attempt to recover from any failure.
This means that duplicate messages might be delivered to an application
and persistent storage of messages is not required.
If the To Party is unable to support the type of Delivery Semantics
requested, then the To Party SHOULD report the error to the From Party
using an ErrorCode of NotSupported and a Severity of Error.


deliverySemantics attribute
The deliverySemantics attribute is an enumeration of the following possible
 BestEffort (default value)

The deliverySemantics parameter/attribute MUST used by the From Party MSH to
indicate whether the Message is be processed using Reliable Messaging as defined
in this specification.

The value for deliverySemantics is specified in the CPA that governs the
processing of the message. If no value is specified in the CPA then the default
value of BestEffort MUST be used.

Refer to the section on Reliable Messaging for a detailed discussion on the
REQUIRED and suggested handling of messages with this attribute.

Agreed. Editorial wordsmithing to be submitted for next week's

51) line 698 - editorial and minor technical - as with the previous attribute,
the deliveryReceiptRequested attribute has both editorial and minor technical

Propose we change:

DeliveryReceiptRequested attribute
The deliveryReceiptRequested element, if present, over-rides the value
of the same parameter in the CPA. If not present then the value in the
CPA MUST be used.
The deliveryReceiptRequested parameter/element MUST be used by a From
Party MSH to indicate whether a message received by the To Party MSH
should result in the To Party MSH returning an acknowledgment message
containing an Acknowledgment element with a type of deliveryReceipt.
The deliveryReceiptRequested parameter/element is frequently used to
help implement Reliable Messaging (see section Reliable Messaging)
although it can be used independently.
Before setting the value of deliveryReceiptRequested, the From Party
SHOULD check the deliveryReceiptSupported parameter for the To Party
in the CPA to make sure that its value is compatible.

Valid values for deliveryReceiptRequested are:
 Unsigned - requests that an unsigned Delivery Receipt is requested
 Signed - requests that a signed Delivery Receipt is requested, or
 None - indicates that no Delivery Receipt is requested.
When a To Party MSH receives a message with deliveryReceiptRequested not
set to None then it should check if it is able to support the type of
Delivery Receipt requested.
If the To Party MSH can produce the Delivery Receipt of the type requested,
then it MUST return to the From Party on the message just received, a message
containing an Acknowledgment element with the value of the type attribute set
to DeliveryReceipt.
If the To Party cannot return a Delivery Receipt of the type requested
then it MUST report the error to the From Party using an ErrorCode of
NotSupported and a Severity of Error.


deliveryReceiptRequested attribute
The deliveryReceiptRequested attribute is an enumeration of the
following possible values:
 None (default)

The value of the deliveryReceiptRequested attribute is
determined by the CPA that governs the processing of the message. If no
value is specified in the CPA, then the default value of 'None' MUST
be used.

Refer to the section on Reliable Messaging for a detailed discussion on the
REQUIRED and suggested handling of messages with this attribute.

Agreed. May need some wordsmithing to be submitted for next
week's call.

52) line 721 - minor technical - this attribute troubles me. How is an intermediary
expected to handle it? The whole issue of synchronous replies and reliable
messaging is troubling to be perfectly honest.

Defer till Vancouver.

53) line 730 - minor technical - It isn't at all clear to me why this
attribute is present in the QualityOfServiceInfo element. It would seem
to me that if anything, this should be an element and it should be
included in MessageData. IMHO, TTL has nothing to do with reliable
messaging or quality of service. I could easily see TTL applying
to a message that is delivered with BestEffort deliverySemantics.

I would propose that we adopt the following changed description
and insert it in the MessageData section following

TimeToLive element
The TimeToLive element indicates the time by which a message should be
delivered to and processed by the To Party.

In this context the TimeToLive has expired if the time of the internal
clock of the MSH that receives a message is greater than the value
of TimeToLive for the Message.

If TimeToLive is not present then it MUST be assumed that TimeToLive
is infinite and therefore checks for message expiry are unnecessary.

When setting a value for TimeToLive it is RECOMMENDED that the From
Party takes into account the accuracy of its own internal clocks as
well as the mshTimeAccuracy parameter for the Receiver MSH (see section
MSH Time Accuracy) that indicates the accuracy to which a MSH will keep
its internal clocks.

How a MSH ensures that its internal clocks are kept sufficiently accurate
is an implementation decision.

If the To Party's MSH receives a Message where TimeToLive has expired, it SHALL
send a Message to the From Party MSH, reporting that the TimeToLive of the message
has expired. This Message SHALL be comprised of:
 - a Payload that consists of the ebXML Message that expired
 - an ErrorList containing an Error that has the errorCode attribute set to
 TimeToLiveExpired, and the severity attribute set to Error.


62) line 960 - minor technical - I am inclined to agree with sentiments
that have been expressed by some that the mustUnderstand attribute
on the ApplicationHeaders element should probably be removed. Instead,
we should simply RECOMMEND that the global mustUnderstand attribute
has been provided to enable the sender of ApplicationHeaders content
to inform the receiving party's application or application services
layer whether understanding of the namespace qualified content is

My initial thought regarding handling of mustUnderstand on the ApplicationHeaders
element was to inform the MSH as to whether or not it had to support the
ability to pass ApplicationHeaders content to the "application" that services
the message received. I now believe that we simply should REQUIRE that this
functionality be supported in an MSH and leave the mustUnderstand to the
namespace qualified element content.

If we do adopt my proposal to remove mustUnderstand from this element,
then delete lines 992-999.


64) line 1152 - minor technical - OOPS! I didn't see this TBD;-) Here's the
proposed text for the Signature element definition:

An ebXML Message MAY be digitally signed to provide security countermeasures.
Zero or more Signature elements, belonging to the [XMLDSIG]
defined namespace MAY be present in an ebXMLHeader. The Signature element
MUST be namespace qualified in accordance with [XMLDSIG]. The structure and content
of the Signature element MUST conform to the [XMLDSIG] specification. If there
are more than one Signature elements contained within the ebXMLHeader, the
first MUST represent the digital signature of the ebXML Message as signed by
the From Party MSH in conformance with the section Security. Additional Signature
elements MAY be present, but their purpose is undefined by this specification.

Refer to section Security for a detailed discussion on how to construct
the Signature element when digitally signing an ebXML Message.


org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
title:Sr. Staff Engineer
fn:Christopher Ferris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC