[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Messaging Spec v1.092
"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)"
"For the time being, the exchange [Covisint] will use only the messaging services element of ebXML, Cripps said. Adoption of other elements, such as collaborative protocol profiles and agreements, will be added as customer demands grow and standards mature, he said. "
-----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.092Comments 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.092David: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 PMSubject: [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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC