Public Comment

[comment-form@oasis-open.org]

Comment from: lists@sonnenglanz.net

Name: Pim van der Eijk
Organization: Sonnenglanz Consulting BV
Regarding Specification: EbXML Messaging Services 3.0, Part 1, Core Features 

Here is some feedback on the ebMS3 specification.
I hope you find it useful.

Kind regards,

Pim van der Eijk

------------------
Line 210-214:  add note that also multiple payloads, possibly of different MIME types, can be transported in a single ebMS message (important advantage in some applications)

Line 290 
Change:
"/x:MyHeader/x:SomeProperty/@value1"
To
"/x:MyHeader/x:SomeProperty/@attribute1"

Line 294:
The prefix "wssswa" is defined in
http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf
with the value
"http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1.xsd";
rather than 
"http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0.xsd";

(The URL doesn't resolve to an actual XSD at the doc.oasis-open site though).

Line 309:
These definitions seem to assume that the terms "Producer" or a "Consumer" are reserved for Endpoints and cannot be used for Intermediaries. Is that correct?

Line 322:
"There are two types of ebMS Messages:"
Are these types exclusive?  If a message has both eb:SignalMessage and eb:UserMessage elements, what is its type?  A pull request could at the same time push a UserMessage. Is that allowed?

Line 323:
The definition does not say which entity initiates a Signal Message, whereas the definition of User Message does.  

Line 342:
"receive and process error messages associated"
should this be:
"receive and process Signal Messages associated"?

Line 352:
"enough message data"
->
"enough message (meta)data"?
(some of the data needed may not end up in the actual message)

Line 382-383:
Formatting (no new paragraph)

Line 364:
Section 2.2

Line 489:
"responses to these." -> "responses to these requests."

Line 495, Message Pulling:

It looks like this mechanism can be used to select a particular mailbox.
Could this be generalized to a mechanism where the Initiator wants to retrieve a response to a particular message?  The Responder could have a database of RefToMessageId values of messages waiting to be pulled. The requested message may not be the first in the queue.  

Could the Initiator provide additional filtering information, e.g. only retrieve message less than 1 MB in size?  This would increase the value for SMEs that have limited bandwidth connections.

Or should the Initiator/Responder negotiate policies about which message to put in which Message Partition based on criteria like size?

Is there only one message being pulled for each PullRequest / MPF?  

Line 509:
Uses the "P-Mode" concept that hasn't been introduced at this point.

Line 527:
Is there no From/To PartyInfo in a Pull Request?
How does the Responder know who is pulling?
An initiating MSH may operate on behalf of multiple Parties (or a single Party with multiple IDs). Is there a need to be able to specify a "To" (pulling messages sent "to").
Or is an MPF always unique for a particular PartyId ? 

Line 533 and 548:
While it is an non-normative example, it may be clearer to change these to something like:

"<eb:MessageId>UUID-4@receiver.com</eb:MessageId>"

"<eb:MessageId>UUID-5@sender.com</eb:MessageId>
<eb:RefToMessageId>UUID-4@receiver.com</eb:RefToMessageId>"


Line 640, section 3.4.1:

It is not clear from this text (and earlier, line 479-480), whether the concept of MPFs makes sense outside the context of Pulling.   When A pushes messages of two types to B, is there any benefit in using MPFs?  

Line 681, no distinct addressing for MPFs.
Priority handling (other than queues at sender and receiver) often also depends on networking management equipment with bandwidth management (packet shapers).  Those products classify network trafic based on source/target IP addresses, URIs, port numbers.  So some mechanism to associate MPFs with distinct addresses (statically or dynamically) would be useful.

Line 786:
"the the ebXML Application." -> "the ebXML Application."

Line 887:
"Because either packaging option can be used, implementations MUST support non-multipart
messages."
Should this be:
"Because either packaging option can be used, implementations MUST support both multipart and non-multipart messages." ?

Line 901:
"parts. containing additional" -> "parts containing additional"

Line 903:
"requires an XML content." -> "requires XML content."

Line 918:
"Package contain a type" -> "Package contains a type"

Line 965:
"Namespace declaration" -> "A namespace declaration"

Line 1030:
"the namespace for" -> "the namespace prefix for"

Line 1079:
"there MUST NOT be additional Payload Containers."
Does this mean the ebMS 3.0 specification precludes composition with other SOAP protocols that want to attach data?  (Somewhat theoretical question, admittedly).

Line 1119 and 1148:
"Both eb:UserMessage element and eb:SignalMessage element MAY"
Does this mean
"Both a eb:UserMessage element and a eb:SignalMessage element MAY"
or
"Both eb:UserMessage elements and eb:SignalMessage elements MAY" ?

If the spec allowed multiple eb:UserMessages, it could easily support batch/unbatch operations.

Line 1159 and 1165:
Not sure why "(no change beside renaming)" is there.

Line 1192:
"cid:foo";, note that "foo" has to be a MIME content ID, i.e. "foo@example.com".

Line 1225:  this allows for payloads not in the message, but line 1386 doesn't.

Line 1230:
Why is the element "timestamp" in lower case?  eb:Timestamp would be more consistent?

Line 1253:
What is the semantics of multiple PartyId elements in a From (or To)?
EbMS requires these to be alternative names for a single organizations.
Has this requirement be dropped in ebMS 3?  If yes, that should be specified explicitly.

Note:  various people have struggled to squeeze hierarchical addresses (Company/ Division/ Unit/ Employee) in the ebXML PartyId field.

Line 1311:
"If a CPA is referred to and a receiver determines that a message is in conflict with the referred CPA, the appropriate handling of this conflict is undefined by this specification."

What does this mean for ebCPPA 3.0? Should it have a normative ebMS3 binding that defines how this is handled in an interoperable way?

Line 1320:
"a profiling exercise" -> "profiles using this specification"

Line 1382:
"(see Section , for details)" missing reference.

Line 1386:

"The PartInfo element is used to reference either a MIME
attachment or an XML element within the SOAP Body, according to the value of the href attribute,
described below."  Line 1215 mentions URL-identified payloads too. Does the spec allow this or not? Not according to line 1391-1393.

Note: there may be a case for disallowing URI payloads, i.e. requiring all payloads to be in the message.
The semantics of a URI in a PayloadInfo not in the MIME envelope is unidentified. Should the receiving MSH attempt to download the payload from the Internet?  What if it can't access it?
More useful would be some sort of ebXML Signal or extension protocol for downloading/pulling large attachments separately from the main message is useful. E.g. if there are two attachments, a 40 KB XML document and a 160 MB PDF file, it would be nice if the first can be pushed and the second pulled on demand and based on some combination of MessageId and Content-Id.

Line 1405:  Schema element.
Does this mean that the receiving MSH must validate the payload?
If not, why does the message handler need to carry this information?

Line 1415:  Instead of Description, there are use cases for allowing extensible metadata about payloads.  E.g. to get the MIME type, you now have to find the MIME part. Sometimes it makes sense to have that in the PayloadInfo.  If the attached payload is XML Encrypted, PayloadInfo could reveal the "real" datatype.  If the payload is a TIFF image, the PayloadInfo could provide meta-data.

Line 1425:
eb:version="2.0" ?

Line 1452:
"However, ebMS message can" -> "However, ebMS messaging can"
 
Line 1650:
Is this list exhaustive?  If ebMS is composed with other SOAP protocols, can they be escalated too?

Line 1669:
"reported in a log I" -> "reported in a log in"

Line 1830-1833.
How can a containing element eb:Messaging be encrypted while a contained element eb:PartyInfo is not?  An example would help here ..

Line 2406-2423, section 8.2.3:
If both security and reliability are used, there is presumably a required processing order of the security and reliability headers?  Where is this specified?

Line 2448-2452:

The semantics of ack was NOT clearly a delivery semantics in ebMS2. The ebMS3 specification is more precise in defining At-Least-Once as a delivery contract. But the specification still allows the option of acknowledging a message that is not delivered, e.g. in case of a packaging error that is detected after the reliability processing of a received message, where only the generation of an error is required . Shouldn&#8217;t the spec tighten-up the requirements for acks, or at least provide a conformance profile that requires a tighter semantics? Should this type of difference be documented more clearly?
Is there a contract P-Mode property that allows partners to specify this level semantics of Reliability (including or not successful "Deliver") ?

When RM-Deliver is executed before Deliver, there may be issues in the case of failover. Suppose the MSH system (or the interface from the MSH to the enterprise system) crashes, and processing is transfered to a standby system, that system may want to have all messages delivered in some previous time interval (e.g. 15 minutes if the standby system needs a few minutes to come to service) redelivered, even though they have already been acknowledged.  This in order to get any messages possibly stuck between the MSH and the enterprise system before the crash. 
Is this supported by either the WS-R or WS-RM specifications?  If not, could ebMS3 add some support here?

Line 2499-2502:
It is worth pointing out that the order or RM-Deliver and Deliver could be different.

Line 2637, Section 10:
There are some constraints between Reliable Messaging and ebXML processing.
E.g. all messages in a WSRM sequence should be in the same ebXML conversation and CPAId.
Where are these contraints specified?
How are they enforced in an implementation if it uses non-ebXML aware generic RM processors?

There is now no ebXML concept of Message Ordering.Can organizations still use the ordering 
features of the underlying RM specifications?
E.g. certain service/action/cpaid/conversationid initiate new sequences, and others terminate them. Is there a way to specify this correlation.

Partners may want to specify that certain Service/Action combinations, with a new ConversationID and in the same CpaId, are to be performed in-order.  How do they specify this, and how does the ebMS processor know about this?

Line 2730:
"This become a" -> "This becomes a" 

Line 2851 and 2858:
These examples have invalid Content-Ids (no "@" sign).

General comments:

SyncReply module in ebMS2
A mapping from the CPA properties for SyncReply to P-Modes would be useful, for the existing ebMS2 users looking at ebMS3.

EbMS2 has a Message Status service.
This seems to have disappeared? 
Was it considered not useful?  It seems quite relevant in multi-hop. Do any of the underlying specifications provide this functionality?

EbMS2 has a Ping service.
What happened to it?

EbMS2 had a section C Supported Profiling Services.
It would be quite useful to have a similar table that maps these profiles to ebMS3 with WS Security.

EbMS2 had a section 7.6 with reliable messaging combinations.
When Part II adds support for multi-hop, it would be useful to review how this could be mapped to ebMS3 with WS-R or WS-RM.