ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ebxml-msg] Messaging Spec v1.092
- From: Arvola Chan <arvola@tibco.com>
- To: David Fischer <david@drummondgroup.com>,ebXML Msg <ebxml-msg@lists.oasis-open.org>
- Date: Wed, 02 Jan 2002 12:33:40 -0800
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?
- Line 311: The reference to [ebREQ] cannot be found
among the Non-Normative References (see line 2761).
- 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?
- 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)."
- Line 1389: CPP/A attribute names start with a
lower case. SyncReplyMode should be globally repaced with
syncReplyMode.
- 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.
- 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?
- 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.
- Line 1557: I think it is inconsistent to ask for a
signed Acknowledgment if the original message is not signed.
- 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.
- Line 1584: Replace "value of duplicateElimination
in the CPA is false" with "value of duplicateElimination in the CPA is
never".
- 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?
- Line 1602: It will be useful to point out that the
Retries parameter comes from the CPA.
- Line 1605: It will be useful to point out that the
RetryInterval parameter comes from the CPA.
- Line 1616: It will be useful to point out that the
PersistDuration parameter comes from the CPA.
- 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)."
- Line 1646: The sentence is missing a closing
period.
- Line 1678: This seems to contradict the statement
on line 1589.
- Line 1684: There is an invalid reference to
section 0.
- 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.
- 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.
- 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.
- Line 2619: This comment seems unnecessary. Would
it constitute an unrecognized MIME header?
Regards,
-Arvola
----- Original Message -----
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.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC