RE: [ebxml-msg] Groups - No more pending issues

Title: RE: [ebxml-msg] Groups - New Issue Discovered

+1 

 

From: Ric Emery
[mailto:] 

Sent: Tuesday, February 28, 2006
1:44 PM

To: Hamid Ben Malek

Cc: Jacques Durand; Sacha
Schlegel; Dale Moberg; ''

Subject: Re: [ebxml-msg] Groups -
No more pending issues

 

Dale and I have a concern that the Security Section
was, for the most part, removed from the spec. We spoke with Jacques about this
last week on the conference call. I was trying to profile WSS down, to show how
signing and encryption should be done for ebMS. 

We both feel that the ebMS spec should state prescribed ways to sign and
encrypt messages. Then state something to the effect that other WSS compliant
mechanisms can be utilized. But are left outside of the scope of the ebMS spec,
and support is not required.

Only stating that ebMS can utilize WSS is not going to be enough to ensure
interoperability. 

Hamid Ben Malek wrote: 

I
don’t know if you are aware of it or not, but this is just to make sure
you know. The list of pending issues Jacques is talking about is already
resolved. Please read Draft 9a posted to Kavi. We just need to vote on that
draft (either approve it the way it is, or correct few items and make it a CD
2).

 

Hamid.

 

From: Jacques
Durand 

Sent: Tuesday, February 28, 2006
1:34 AM

To: 'Sacha Schlegel'; Dale Moberg;
Hamid Ben Malek; 

Subject: RE: [ebxml-msg] Groups -
New Issue Discovered

 

Sacha:

 

Your points are taken.

So far I believe your concerns below are
addressed by the current draft (?)– if yes let us move on to wrap-up CD2.

We still have some review work to do on
the pending list of proposals to the issues – are we ready to discuss
these next meeting?

I have appended these proposals at the end
of this email.

 

Jacques

 

 

 

From: Sacha
Schlegel [mailto:]

Sent: Monday, February 27, 2006
8:46 PM

To: Jacques
Durand; Dale Moberg; Hamid Ben Malek;


Subject: RE: [ebxml-msg] Groups -
New Issue Discovered

 

 

Hi everyone

I did not follow the conversation but I saw that you mention Service and
Action, and even Roles ... actually they have great value if you take the top
down approach and if you define your collaborative business processes (with
ebXML Business Process) first. Eg you just have to look at the ebXML message
header and you got all the information in one place, that is very convenient.

The From, FromRole, To, ToRole, Service, Action, and CPA id values in fact
provide the link to the ebXML CPA (to look up security, reliable messaging and
other messaging operational aspects). At the same time and in combination with the
conversation ID these values provide the information to identify the document
exchange in the collaborative business process. So to me ebXML Messaging
"2.0" has actually very good support for higher level collaborative
business processes. So to deal with ebXML messages that do not have those
values anymore ... it would take some headscratching how to interact with the
next layer (CPA in this case).

From what I see the advanced ebXML end users, those who think along the lines
of adding, removing and changing collaborative business processes over time to
their trading partner relationsships, do in fact take the top down approach
starting with the collaborative business processes, managing the CPA's and then
using ebXML messaging that supports that approach by those Role, Serivce, and
Action information in the ebXML message header.

Ignore this email if my concerns are not related to your current discussion.

Sacha

-----Original Message-----

Remiaining proposed and agreed updates on latest WD
0.8: (Feb 15)

 

-----------------------------------------------------------------------

-----------------------------------------------------------------------

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.

 

EDIT: Just need detailed
proposal

 

 

-----------------------------------------------------------------------

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

(and Partref to be renamed
PartInfo I believe)

 

5.a- eb:id : agreed to
remove (replaced by XML Id)

5.b- eb:idref. Use instead
"href" (a SOAP standard attribute).

 

STATUS: agreed.

EDIT: Just need detailed
proposal (see SOAP 1.2 appendix which uses it)

 

-----------------------------------------------------------------------

7) remove sections related
to SOAP actors:

 

In Part 1:

- Remove sections 5.1.3.8 ,
5.1.3.9, 5.1.3.10 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: agreed. Issue 8
takes care of scoping Part 1 to remove needs 

for handling intermediaries.

EDIT: TO DO (Part 1)

 

-----------------------------------------------------------------------

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 title as "Messaging Service Processing Model" 

or  "MSH
Processing Model".  

 

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: Proposal has already
been discussed and reviewed, no overall objection.

EDIT: Ready for inclusion
review draft.

 

-----------------------------------------------------------------------

9) @soapresp attribute:

 

STATUS: Agreed to remove.
(references to it still in from 2.2.3.1 and 2.2.3.3)

EDIT: TO DO

 

------------------------------------------------------------------

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: Agreed in general.
Needs detailed proposal.

EDIT: 

 

--------------------------------------------------------------------

11)

 

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

 

Last bullet item in 8.2.2:

 

Relax the requirement:

"... For example, in
the case of At-Least-Once delivery, the MSH must

ensure that if a message
that has been submitted (Submit) fails before RM-Submit is invoked,

then the user layer
(Producer) gets a notification of failure (Notify invocation), as would be the

case if the message
processing failed just after RM-Submit was invoked. Similarly, if a message

fails to be delivered on
receiver side (Deliver) even after RM-Deliver has been successfully

invoked, then a notification
to the Consumer must occur on the receiver side (Notify)."

as:

"...For example, in the
case of At-Least-Once delivery, the MSH must

ensure that if a message
that has been submitted (Submit) fails before RM-Submit is invoked,

then a delivery failure Error
is generated, as would be the

case if the message
processing failed just after RM-Submit was invoked. Similarly, if a message

fails to be delivered on
receiver side (Deliver) even after RM-Deliver has been successfully

invoked, then a delivery
failure Error must be generated. 

The reporting of these
errors obeys the P-Mode.errorHandling."

 

 

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 are
intended for internal MSH consumption. 

They may also be subject to
reliability contracts. In this case, the at-least-once contract 

is fulfilled

with a successful
RM-delivery. In case of at-least-once delivery, a failure do deliver must cause
the 

generation of a delivery
failure Error. If this message was

submitted or initiated by an
MSH Producer (Submit) instead of the MSH itself (e.g. a Ping initiated by 

the Producer), the Producer
may be notified (Notify) 

of the failure depending on
the reporting mode, as for regular user messages."

 

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

 

STATUS: Correction by author.

EDIT: Ready for inclusion
review draft.

 

-----------------------------
Error section: ---------------------

12)

- Add 1 error EBMS:0010
"ProcessingModeMismatch", severity: failure, category: Processing

"the ebMS header is not
compatible with expected content based on 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: Correction by
author. Renumbering is editorial. The new errors are to be discussed. 

EDIT: 

 

------------------------------------------------------------------

13)

Section 2.2.2.1:

 

reword:

 

The response message, in case
a two-way underlying protocol is used:

(a) may contain a SOAP
envelope with a SOAP body that is always empty, in which case the One-way MEP 

is qualified as
"composable".

(b) may contain 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) may never contain a SOAP
envelope, in which case the SOAP One-way MEP is qualified as
“strict”.

 

STATUS: Correction by author.

EDIT: Ready for inclusion
review draft.

 

------------------------------------------------------------------

14)

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

messages."

 

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.

 

L752:

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

process filter expressions.
" 

 

STATUS: Correction by author.

EDIT: Ready for inclusion
review draft.

 

--------------------
Operation COntext --> P-Mode ----------------

15)

 

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)

EDIT: Ready for inclusion
review draft

 

-------------------------
----------------

16)

Section 10 "Reliability
Protocol Bindings"

Replace:

"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."

with:

"Although either one of
the above OASIS reliability specifications is sufficient, 

each one has strong
arguments in favor of its use."

 

In 10.1.3: in the table:

".. two additional
requirements MUST be satisfied"

only the two first bullets apply,
bullet 3 should not be part of this sublist.

 

In 10.1.4: in the table:

".. two additional
requirements MUST be satisfied"

The two conditions should be
singled out , e.g. with dashes or bullets.

 

 

STATUS: Correction by author.

EDIT: Ready for inclusion
review draft.

 

---------------------------------------------

17) 

Insert COnformance Appendix,
latest update (Feb 14).

 

STATUS: 3rd iteration,
latest updates to be discussed.

EDIT: Ready for inclusion
review draft.

 

 

---------------------------------------------

18) 

Insert SOAP 1.2 binding
Appendix. 

Remove previous Appendix 11.

 

STATUS: SOAP 1.2 latest
agreed. Appendix 11 removal to be discussed / confirmed.

no general objection.

EDIT: ?

 

---------------------------------------------

19)

Security Module (Section 6.3)

security of attachments
WSS1.0 vs WSS 1.1

 

STATUS: Proposal to handle
this by a new COnformance profile (Level 2) in Part1. Linked to Issue 17.

EDIT: Need to describe both
WSS 1.0 and WSS 1.1 + WSS-SWA options.

 

---------------------------------------------

20)

Update the packaging figures
Section 5 (fig 7 and 8)

- remove StatusRequest /
Response signals.

 

STATUS: Need concrete
proposal

EDIT: 

 

------------------------------------------

 

 

21) Section 10.2.1: 

WS-RM binding: should
specify that:

- RM QoS applies to an
entire sequence, and is communicated in the CS extension point.

(need to decide of a format
for interoperability ! propose a default, can be override in P-Mode ?)

 

STATUS: Need discussion,
concrete proposal