[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]