[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Messaging Spec v1.092 / CPA dependency
Jacques,
You have given a very good summary of the situation.
I have several times suggested the expression "Configuration Parameter
Aggregation" as a nickname for CPA but so far no one has shown interest.
IMHO, the problem here is that some people want the richness of ebXML
messaging but do not accept the need to configure a pair of partners to use
the richness.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
Jacques Durand <JDurand@fs.fujitsu.com> on 01/10/2002 07:45:26 PM
To: "'David Fischer'" <david@drummondgroup.com>, Martin W
Sachs/Watson/IBM@IBMUS, Jacques Durand <JDurand@fs.fujitsu.com>
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] Messaging Spec v1.092 / CPA dependency
I believe the notion of "independence" should remain "formal": means
an MSH instance is not required to imperatively access an ebXML CPA server
somewhere,
or is not forced to literally parse a CPA document.
I think it satisfies the spirit of the charter, the ultimate purpose of
which is
I believe that any MS implementation should be able to work without a
(formally)
CPA-compliant implementation.
That does not mean an MSH should not use any "CPA-data"... which should be
considered
as MSH configuration data, as Martin suggested. Being able to configure MSH
behavior
at conversation level, not just message level, makes it a much more
reliable/efficient
tool for business, and so it is worth the pain of sorting out the semantic
conflicts
between this configuration data and header data.
If we don't do it, then each message will have to always carry CPA-data,
and the burden will be on the app to provide it each time.
Plus, in future versions, the MSH will likely be the place where to enforce
CPA data
that is higher level than message: duration of a conversation, max
concurrent conversations...
Maybe the apparent dependency is mostly editorial.
we could have abstracted more the notion of CPA in MS spec:
Just a (late) suggestion: we could have named it "Communication Protocol
COnfiguration" (CPC)
and assume it is no more than a set of attributes associated with each
communicating pair (from/to), and write CPC anywhere we use CPA today.
We could have then a RECOMMENDATION that the CPC content be derived from a
CPA...
So applying a CPA to an MSH is a matter of configuration, in the same way
as applying a
CPA to a lower transport layer is.
Jacques
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Sunday, January 06, 2002 2:24 PM
To: Martin W Sachs; Jacques Durand
Cc: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092
I disagree. If the specs were truly loosely coupled then we would not have
discussions concerning discrepancies between the header fields and the CPA.
Errors concerning such discrepancies would be implementation dependant. We
would not worry about aligning Messaging and CPA. We would not have
continual
problems with having to remove fields from the Messaging headers because
they
are already specified in the CPA (in fact, many fields would exist both
places).
We even voted at the last F2F that there MUST be an agreement in place --
no
allowance for spontaneous eCommerce. There has been constant discussion
that
there MUST be either a CPA or a "virtual CPA", which simply means a
database
containing all the CPA fields and structures even though there may not be
an
actual XML document anywhere. Quotes from the spec to the contrary are
simply
my lack of diligence in removing them since the last F2F.
If we could move back to a time when we did allow non-agreement (with or
without
CPA) type eCommerce, then that would remove my objection -- but I don't
think
that is where we are now. Our original charter was to focus on the SME
needs in
eCommerce. I would argue the SME's need something more akin to B2C rather
than
traditional B2B (I don't mean Web based but I do mean spontaneous). My
objection is that our (very good) system is largely a rehash of what has
gone
before (and maybe somewhat of an improvement) but it does NOT adequately
address
the needs of SME's.
Now, someone else please take the SOAP box ;-).
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, January 04, 2002 10:39 PM
To: Jacques Durand
Cc: 'David Fischer'; Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092
Jacques,
I agree with you that the MSG spec is NOT tightly coupled to the CPA. The
words you quote are exactly the words that eliminate dependence on the CPA.
However, information that can be encoded in the CPA is still needed to
enable to partners to exchange messages. Without a CPA, that information
is entered separately into each partner's system via a GUI tool. That's as
loosely coupled as you can ask for.
********************************************************************************
*****
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
********************************************************************************
*****
Jacques Durand <JDurand@fs.fujitsu.com> on 01/04/2002 07:21:24 PM
To: "'David Fischer'" <david@drummondgroup.com>, Arvola Chan
<arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>,
"Ian. C. Jones (E-mail)" <ian.c.jones@bt.com>
cc:
Subject: RE: [ebxml-msg] Messaging Spec v1.092
David:
No problem with V2.0, agree that "1.1" is misleading with regard to
backward compatibility.
The adoption of an (early) incompatible new version can still be helped if
the upgrade is such that it
allows for an upgraded MSH implementation to handle in parallel the two
"incompatible" versions
during a transition period, (in case running two different MSH instances
on same site is problematic).
That is quite possible using version # in header, if the incompatibility
is mostly in the packaging format,
with no conflicting MSH behavior . This would permit a smooth transition,
not needing
all trading partners to upgrade at same time.
"Tightly" integrated with CPA? Just reading V1.092 I did not have this
impression:
"...However, the method used by a specific implementation of the MSH does
not mandate the existence of a discrete instance of a CPA.
... This specification does not prescribe how the CPA information is
derived, stored, or used:
it only states specific information items must be available for the MSH to
achieve successful operations."
My understanding is that some (actually small) subset of CPA needs be
available in some form.
That still sounds like loose coupling to me...
Regards,
jacques Durand
-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Thursday, January 03, 2002 5:48 PM
To: Arvola Chan; ebXML Msg; Ian. C. Jones (E-mail)
Subject: RE: [ebxml-msg] Messaging Spec v1.092
Comments inline.
Ian,
We still have a couple of unresolved issues -- most notably the signature
problem Sanjay pointed out. There is also the issue (item 6 below) that
SyncReply does not work with Intermediate Acknowledgments. We are
supposed to start voting tomorrow. What shall we do? If you would like,
I can go ahead and post as version 1.093?
I want to thank everyone for all the help on editing/reviewing the
specification. I think this is a much better spec than v1.0. That said,
I will also say I plan to vote *no* on this spec for two reasons: 1) Our
charter was to create a v1.1 spec with "fixes and clarifications only"
which we have failed to do (if we could name this spec v2.0, as the RegRep
team did, then this objection would go away), and 2) Our original
charter was to create a set of "orthogonal ebXML specifications" which we
have failed to do (we have tightly coupled Messaging with CPPA). I would
like to urge everyone to consider a version number of v2.0 since v1.1 has
the connotation of backward compatibility which we certainly have not
achieved. Our next version could then be v3.0?
Please let me know what you want to do.
David.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Wednesday, January 02, 2002 2:34 PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] Messaging Spec v1.092
David:
Here are some belated editorial comments. I hope they can be fixed without
too much trouble:
Line 18: Don't we have to wait for a calendar quarter boundary before
the spec can be presented to the OASIS membership for consideration as
an OASIS specification?
<df>Fixed -- this means we will submit on April Fools Day ;-)
We still don't have anything under the *This Version*
heading</df>
Line 311: The reference to [ebREQ] cannot be found among the
Non-Normative References (see line 2761).
<df>Added Reference</df>
LIne 896: The permissible values for duplicateElimination in the CPA
are perMessage, never, and always. Therefore, replace "set to false"
with "set to never" on line 897. Note: this is with respect to the 1.1
CPP/A spec. Do we need to add a reference to the forthcoming 1.1 CPP/A
spec?
<df>done</df>
Line 1384: The schema says that this is a REQUIRED attribute. It must
be set to the value "http://schemas.xmlsoap.org/soap/actor/next". It is
somewhat different from being declared as a FIXED attribute in the
schema. Line 1384 seems to suggest the latter. Excerpts from the SOAP
1.1 spec: "The SOAP actor global attribute can be used to indicate the
recipient of a header element. The value of the SOAP actor attribute is
a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next"
indicates that the header element is intended for the very first SOAP
application that processes the message. This is similar to the
hop-by-hop scope model represented by the Connection header field in
HTTP. Omitting the SOAP actor attribute indicates that the recipient is
the ultimate destination of the SOAP message. This attribute MUST
appear in the SOAP message instance in order to be effective (see
section 3 and 4.2.1)."
<df>Changed "fixed" to "REQUIRED"</df>
Line 1389: CPP/A attribute names start with a lower case. SyncReplyMode
should be globally repaced with syncReplyMode.
<df>done</df>
Line 1412: I like to point out that a SyncReply element is not
compatible with an AckRequested element that is targeted at the next
MSH.
<df>No resolution yet.</df>
Line 1491: I think an errorCode of Inconsistent should be accompanied
by a severity of Error rather than warning. Didn't we decide that
inconsistency between the CPA and the message header must always result
in an error being returned?
<df>This might not be an inconsistency with the CPA (perMessage). If
we say this must be an Error then we must also say the To Party MSH
MUST NOT deliver to the Application. IMO This needs to be a
Warning.</df>
1502: The statement "An Error Message MUST NOT contain an AckRequested
element" is not correct and should be struck out. Please see
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html
(Resolution of issues in the issues database), IssueId 73, and/or
http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc,
Issue 73.
<df>We have gone back and forth on this several times. I think the
latest was to change to *no Ack on Error*. If we go back to *no Error
on Ack* then I need to go back through the spec and make several
changes. See *[ebxml-msg] Ack on Error, or Error on Ack* thread
starting 12/10/01.</df>
Line 1557: I think it is inconsistent to ask for a signed
Acknowledgment if the original message is not signed.
<df>Why? I agree it sounds strange but I can't think of any reason it
would be inconsistent. Someone might want NRR but there is no reason
to sign.</df>
Line 1579: It will be useful to point out that parameters that are not
found in the message header are to be obtained from the CPA.
<df>??? It already says this?</df>
Line 1584: Replace "value of duplicateElimination in the CPA is false"
with "value of duplicateElimination in the CPA is never".
<df>done</df>
Line 1591: I think it may be problematical for the recipient to do
duplicate elimination when no DuplicateElimination element is present.
What happens if SyncReply is present and AckRequested is not present.
If the incoming message is not passed on to the application, should any
reply be returned to the sender?
<df>Resolved between Arvola and Doug</df>
Line 1602: It will be useful to point out that the Retries parameter
comes from the CPA.
<df>done</df>
Line 1605: It will be useful to point out that the RetryInterval
parameter comes from the CPA.
<df> done </df>
Line 1616: It will be useful to point out that the PersistDuration
parameter comes from the CPA.
<df> done </df>
Line 1625: As mentioned earlier, SyncReplyMode should be spelt as
syncReplyMode. Also, I just noticed the following statement in the 1.0
CPP/A spec. "If the delivery channel identifies a transport protocol
that has no synchronous capabilities (such as SMTP) and the
Characteristics element has a syncReplyMode attribute with a value
other than "none", a response SHALL contain the same content as if the
transport protocol did support synchronous responses." which
contradicts the statement on line 1625: "The SyncReplyMode parameter
from the CPA is used only if the data communications protocol is
synchronous (e.g. HTTP)."
<df> Resolved </df>
Line 1646: The sentence is missing a closing period.
<df> done </df>
Line 1678: This seems to contradict the statement on line 1589.
<df> deleted </df>
Line 1684: There is an invalid reference to section 0.
<df> deleted </df>
Line 1733 and line 1738: These two bullet points assume that
syncReplyMode in the CPA is not used with an asynchronous communication
channel. This is in conflict with the 1.0 CPP/A spec statement quoted
in item 15 above. I think this is a minor technical issue that may
require some discussion.
<df> Resolved </df>
Line 1772: Since one MSH is not allowed to place more than one
AckRequested element in the SOAP Header (according to line 1469), this
matrix represents what an intermediary MSH or the To Party MSH may
receive, not what the From Party MSH may send.
<df> Does this mean 1468/9 is wrong? It already says *SHOULD* so
maybe no change is needed.</df>
Line 2098: I think the statement "The Receiving MSH MUST NOT send an
Acknowledgment Message until the message has been delivered to the Next
MSH" is not correct. This does not correspond to store and forward
behavior (see line 2043). The Receiving MSH cannot know for sure that
the message has been delivered to the Next MSH until it receives an
Acknowledgment from the latter. The prescribed behavior defeats the
purpose of intermediate Acknowledgments.
<df> What would be more correct? Should it say *The Receiving MSH MUST
NOT send an Acknowledgment Message until the message has
been persisted?* Actually, I don't see a problem as it is. What
should I do? </df>
Line 2619: This comment seems unnecessary. Would it constitute an
unrecognized MIME header?
<df> Yes, this is unnecessary. No this is not illegal. Everything
between the first blank line and the first boundary is ignored. It is
common for vendors to put advertising info in this space -- identify
the product or vendor software producing this message. </df>
Regards,
-Arvola
----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "ebXML Msg" <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, December 20, 2001 7:25 PM
Subject: [ebxml-msg] Messaging Spec v1.092
> This is the spec as it stands now. I think everyone's comments are
included
> (I'm mad at Doug for sending pages and pages of very good comments AT
THE LAST
> MINUTE ;-)
>
> Please get any last minute comments to me quickly. Please no large
changes at
> this point.
>
> Ian, I still need to resolve the copyright issue. Also, we need to
decide on
> the problem Sanjay described (I added the change as hidden text if
anyone wants
> to look at it).
>
> If anyone needs this in PDF, please let me know.
>
> Regards,
>
> David Fischer
> Drummond Group
> ebXML-MS Editor.
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC