[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: minutes of feb 01 2001 con-call
Attending Ralph Berwanger Doug Bunting Henry Lowe Gary Morin Rik Drummond David Fischer Robert Adams Rich Salz Iwasa Mike DeNicola Ian Jones Chris Ferris Minutes: 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
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.
Agreed.
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
delivery.
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"
involvement.
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.
to:
deliverySemantics attribute
The deliverySemantics attribute is an enumeration of the following
possible
values:
OnceAndOnlyOnce
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
call.
51) line 698 - editorial and minor technical - as with the previous
attribute,
the deliveryReceiptRequested attribute has both editorial and minor
technical
issues.
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.
to:
deliveryReceiptRequested attribute
The deliveryReceiptRequested attribute is an enumeration of the
following possible values:
Signed
UnSigned
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 5.4.6.2:
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.
Agreed.
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
REQUIRED.
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.
Agreed.
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.
Agreed.
begin:vcard n:Ferris;Christopher tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XML Technology Development adr:;;One Network Drive;Burlington;Ma;01824-0903;USA version:2.1 email;internet:chris.ferris@east.Sun.COM title:Sr. Staff Engineer x-mozilla-cpt:;0 fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC