current list of comments and pending updates on CD1

Consolidated comments on CD1: previous (Dec 7) + new
comments

 

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

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

eb:Messaging

 

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: consensus for it, need finalize.

 

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

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.

 

Minor modification suggested by Hamid (see
last email on ebMS-3 mailing list): replace eb:idref by the 

SOAP 1.1 attribute href. Also rename
"eb:Partref" to "eb:Part" (Partref and href would be
redundant when put together)

                 

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

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: To be discussed.

 

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

8) Remodeling of Section 3:

 

8.a- remove section 3.4 (supported topologies), and
remind in Intro (1.2 "Scope") 

that Part 1 only supports the point-to-point
topology (1st bullet in 3.4)

Part 2 will take care of expanding on other
topologies.

 

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 " (Prefer MSH than Messaging Service).  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- After some thought, the 3.2 section should be
removed, in particular

not give any semantics to an "absent
AgreementRef". AgreementRef is just a meaningful

place holder that has no semantics for this
specification - like Service and Action.

The notion of Default Operation Mode still makes
sense, but is more related to

default operation contexts defined in 3.1: 

when any individual OpCtxt is unspecified or not
agreed upon between parties 

(or more precisely, when a message to be sent does
not fall under any existing

Op COntext between the parties) then the MSH falls
back on what is the "default OpCtx".

E.g. the default Security OpCtxt is No security at
all. Same for default Reliabiity.

Etc. The default OpCtx-BusinessColaboration will use
a dummy service/action used for

ping/pong.

So each Op context will define what is its
"default", i.e. what is the related 

MSH behavior when it is absent.

 

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

 

 

STATUS: To be discussed.

 

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

9) @soapresp attribute:

 

- should it be removed?: it Indicates whether a
correlated SOAP response is expected,

meaning for the ultimate MSH using an HTTP standard
binding, whether a connection should be kept open.

Two reasons weaken this feature:

(a) implementations can "know" which MEP a
message is involved in, based on op contexts (agreements). They may decide to
keep connections open anyway, for a short time regardless of MEPs.

(b) as decided for SOAP actor features, there should
be a more generic way (outside ebMS header)to indicate a req-resp MEP to a SOAP
node. Once decided, can be used instead.

 

STATUS: to be discussed

 

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

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