David:
I am happy that some of my comments get discussed.
I don't want to hold up the voting process any longer. I trust your judgement on
what to include in a 1.093 draft.
Regards,
-Arvola
----- Original Message -----
Sent: Thursday, January 03, 2002 5:47
PM
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.
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 -----
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. >
|