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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: [ebxml-msg] Groups - ebXML Messaging weekly call modified

Title: RE: [ebxml-msg] Groups - ebXML Messaging weekly call modified

We'd like to add to the agenda:

- schedule for the next CD2 (can we wrap-up the first draft consolidation of all resolutions by next week...?)
- referencing of messages-in-error from eb:Error element, and bundling conditions (see previous email)
- security of attachments, WSS1.0 vs WSS1.1
- review of various updates (section 3 processing modes, SOAP 1.2 option, conformance section)

Attached is the list of current issues (some resolved some not yet) that I had sent before.


-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Wednesday, January 25, 2006 4:47 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - ebXML Messaging weekly call modified

ebXML Messaging weekly call has been modified by Mr Ian Jones

Date:  Wednesday, 08 February 2006
Time:  02:30pm - 04:00pm PT

Event Description:
ebXML Messaging weekly call

Dial-in:     1-620-782-2200 (Kansas)
Access Code: 120905


1) Role
2) Status
3) Current actions
4) new Business
5) A.O.B.


This event is one in a list of recurring events.
Other event dates in this series:

Wednesday, 01 February 2006, 02:30pm to 04:00pm PT

View event details:

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web


Update on comments on CD1: (Jan 30)

1) In the whole document, replace every occurrence of eb:Message by

This aligns element with the name of the spec, allows for potential future
bundling of messages, and containment of other messaging-related elements
other than messages themselves.  Tentative agreement; no objections at
this time.  Ian may follow up and raise issues after reviewing his notes.

STATUS: agreed.

2) eb:ErrorList element: Already removed, except in Figure 8, which needs
to be updated, as already noted.  We now have eb:Error, which may be
repeated if multiple errors need to be reported.  If batching of errors
is allowed, we can repeat eb:SignalMessage, each containing eb:Errors.

STATUS: agreed.
3) Subsection 5.3 (Signal Packaging) should rather be a subsubsection of
subsection 5.2 (Core Header Extension). After all, signal packaging is
also about packaging in the header. Therefore, subsection 5.2 (Core Header
Extension) should have only two subsubsections, namely eb:UserMessage
Element and eb:SignalMessage Element.

STATUS: Agreed.  

4) Remove paragraph (lines 291-292): "Implementors are strongly advised to
read and understand the Collaboration Protocol Profile."
It is very clear in the specification that such binding is out of
scope. In other terms, the specification explicitly allows many different
representations of an ebXML agreement without being in favor for any of
them (such as a CPA for example).

See also Monica's comments.

Note that a CPA binding could be in appendix of Part 2.

STATUS: No consensus; decision deferred.
Ian: We need a statement that understanding CPP/A is helpful in doing
a proper implementation.

5) Subsubsection 5.1.3 (ebXML SOAP Envelope Extension ) should be
moved to 5.1.4, and a new subsubsection 5.1.3 should be added having
the title Example.

STATUS: Agreed that a complete example be provided in its own section.
Some disagreement as to placement of Example section.  Some feel it
should be first; others would like the normative specification text
first with example following.

6) In examples, the element eb:Partref still contains the attributes:

5.a- eb:id : agreed to remove (replaced by XML Id)
5.b- eb:idref. Keep it as AnyURI type. Will use a cid scheme when referring to MIME parts,
and an XML fragment ( #if-of-fragment) when referring to parts in the SOAP body.

STATUS: agreed.

7) remove sections related to SOAP actors:

In Part 1:
- Remove sections ,, about SOAP actors & mustUnderstand, as the related topologies that such actors
support are relevant to Part 2. (see proposed changes for Section 3 below)
In Part II:
- introduce the additional topologies that are handled.
- address the routing issue for MEPs in a more generic way, and add SOAP actors as needed.

STATUS: To be discussed.

8) Remodeling of Section 3:

8.a- Remove 3.4 and in Section 1 Intro (1.2 "Scope") add: 
"Features defined in Part 1 only support the point-to-point MSH topology, 
where no MSH or SOAP intermediary is assumed.
Part 2 takes into account topologies with intermediaries, hub or multi-hop, as well
as topologies where the ultimate MSH acts as a SOAP intermediary."

8.b- move section 3.3 "Message Service Processing Model" at the end of 
Section 2 (Messaging Model), replace "Message Service " with "Messaging Service " 
or  "MSH ".  On line 674, the paragraph should describe not only the processing
by the receiving role but also the processing by the sending role,
because the picture above it is supposed to describe the structure of
an MSH for both a sending and receiving role (accepted).

8.c- Replaces what is left of Section 3 (3.1 + 3.2) with proposal posted.

8.d- Section 3 should then be renamed "Processing Modes"

STATUS: To be discussed.

9) @soapresp attribute:

STATUS: Agreed to remove. (from and

10) Security:

- too many examples that may not add value, redundant with WSS examples?
- Ric notes that the security examples are incorrect, where the references
are supposed to be to the SOAP Body, but instead contain a cid:xxx.

STATUS: to be discussed


reliability of "Internal" Service/Action (such as msg:service/Ping):

At the end of 8.2.2 (Reliability section) add:

"Messages that have eb:CollaborationInfo/eb:Service set to “urn:oasis:names:tc:ebxml-msg:service”
are not intended to be delivered (Deliver) to an MSH Consumer, although they may be submitted by
an MSH Producer. They and are for internal MSH consumption. 
They may also be subject to reliability contracts. In this case, the delivery contract is fulfilled
with a successful RM-delivery. In case of failure do deliver, and if this message was
submitted by an MSH Producer (Submit) instead of the MSH itself, the Producer must be notified (Notify) 
of the failure, like for regular user messages."

Also, in 8.1,  L2811, replace "may be subject" with "is subject".

STATUS: to be discussed
----------------------------- Error section: ---------------------
- Add 1 error EBMS:0010 "ProcessingModeMismatch", severity: failure, category: Processing
"the ebMS header is not compatible with expected content for the 
associated P-Mode."

- in Reliability errors, Add 1 error EBMS:0201 "DysfunctionalReliability" 
severity: failure, category: Processing
"some reliability function as implemented by the Reliability module, is not operational,
or the reliability state associated with this message sequence is not valid."

- renumber the error code for "DeliveryFailure"as: EBMS:0202 (instad of 0010)

- renumber the error code for "Failed Authentication" as: EBMS:0101 (instad of 0011)

STATUS: to be discussed


The response message, in case a two-way underlying protocol is used, may contain:
(a) a SOAP envelope with a SOAP body that is always empty, in which case the One-way MEP 
is qualified as "composable".
(b) a SOAP envelope with a SOAP body that is either empty or contains a SOAP Fault. 
In that case the MEP is qualified as "fault supporting" in addition to being composable.
(c) never contains a SOAP envelope, in which case the SOAP One-way MEP is qualified as “strict”.

STATUS: to be discussed
Section 4.1:

reword as:

"...ways with another MSH, engaging in a client-server type of interaction with 
the remote MSH, without any need to open a port to incoming requests. This MEP also 
supports exchanges with a partner that is intermittently connected: instead of periodically
polling for partner presence, a sending MSH will simply wait for the partner MSH to pull

Example: A mobile, occasionally connected device without static IP address and with 
limited storage capability 
can only initiate requests and receive messages as synchronous responses to these. 
The  One-way Pull MEP allows this device to enable and control the flow of received messages, 
and to adjust it to its own resources.

"...without a need to transfer filter expressions. " --> "...without a need to transfer and process filter expressions. " 

STATUS: to be discussed
-------------------- Operation COntext --> P-Mode ----------------

Section 2.4.3:
"...This is done by sharing the message pipes operation context (see OpCtx_MessagePipes in Section 3)."
replace with:
"...This is done by sharing the message pipes processing mode feature (see P-Mode.messagePipes in Section 3)."

Section 5.2.9:
"... AgreementRef is a string value that identifies the operation context that governs the exchange. The
recipient of a message MUST be able to resolve the AgreementRef to this operation context, or to the
related agreement between the Sending and Receiving parties."
replace with:
"... AgreementRef is a string value that identifies the agreement that governs the exchange. The P-Mode under which
the MSH operates for this message MUST be aligned with this agreement."

Section 7:
"... Error generation and error reporting are treated here as orthogonal concepts. Some aspects of error
handling - in particular, reporting - are best specified within the operation context for error handling
(OpCtx-ErrorHandling) e.g. as resulting from an agreement."
replace with:
"... Error generation and error reporting are treated here as orthogonal concepts. While the generation of errors
is a matter of conformance, the reporting of errors may be subject to an agreement. Consequently, the way errors 
are to be reported is specified in the P-Mode (P-Mode.errorHandling feature) that results from such an agreement."

Section 7.5:
"... Except for some cases defined in this specification, Error escalation policies are left to an
agreement between users, represented in the operation context of an MSH ( OpCtx-ErrorHandling)."
replace with:
"... Except for some cases defined in this specification, Error escalation policies are left to an
agreement between users, represented in the processing mode of an MSH ( P-Mode.errorHandling )."

Section 7.7.1:
EBMS:0003 : replace operationn context with "processing mode"

Section 8.1 (end):
"... Note that depending on the reliability operation
context (OpCtx-Reliability), notification of delivery failure may be detected on either side."
replace with:
"... Note that depending on the reliability processing mode (P-Mode.reliability),  awareness of 
delivery failure may occur on either side."

STATUS: Editorial effect of replacing Section 3. Follows from agreement on (8)

------------------------- ----------------
Rename Section 10 as "Reliability Protocol Bindings"
(Because "Profile " is an overloaded term, with different meanings.)
"It is not the intent of ebMS to open too many options, but the case of reliability is a particular one, as
each one of the two OASIS reliability specifications has strong arguments in its favor."
"Although either one of the above OASIS reliability specifications is sufficient, each one has strong arguments in 
favor of its use."

- retitle 10.1: "WS-Reliability Binding" 
- insert also the new section content for 10.2 "WS-ReliableMessaging Binding"

STATUS: to be discussed
Insert COnformance Appendix, latest update.

STATUS: 3rd iteration, to be finalized.
Insert SOAP 1.2 binding Appendix.

STATUS: 2nd iteration, to be finalized.
Security Module (Section 6.3)
Shouldn't we postpone the security of attachment to Part 2, where we can introduce 
the WSS 1.1 alternative that supports it (WSS-SWA), instead of tweaking WSS1.0?
"[Hamid] I know this has been discussed previously, but I'd like to bring it again on the 
table for discussion. I am suggesting deferring the security of attachments to Part 2 
of the ebMS-3 Specification. The main reason for this is because the security of attachments 
is formally being part of WSS-1.1, whereas the core part of ebMS-3 spec only supports WSS-1.0. 
I don’t like the pick-and-choose approach (we can’t just pick one part of another version, 
but not support the whole version, or have a position between two versions). 
I understand the importance of security of the attachments for the business, but we can 
assure the audience that it will be covered in Part 2, which by the way can start before 
even finishing the core (we can start editing Part 2 in parallel to the Core draft if 
nobody minds that).

STATUS: to be discussed

Update the packaging figures Section 5 (fig 7 and 8)
- eb:Message --> eb:Messaging
- the comments behind the arrows need be more explanatory.
- bold outline not justified
- ping & pong signals need be discussed (advantage in reversing to 
Service/Action coding like in ebMS2, when combined with P-Modes)

See posted proposal.

STATUS: to be discussed
------------------------------------------ TODO

A1- rename:
 P-Mode --> P-Mode set
P-Mode is what applies to a single message.

A2- WS-RM binding: should specify that:
- RM QoS applies to an entire sequence, and is communicated in the CS extension point.
(need to conform to the format proposed in P-Mode !)

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