The following material includes issues I've raised in the past
but have not been discussed on the list or addressed in the specification.
I've edited the list to remove things no longer relevant or already
handled. The line numbers are for the 2.0 document in PDF form (or Word
form without change markings) and the suggestions start from the current text.
The historical messages of interest are "[ebxml-msg] Comments on
1.09 first half" [1],"Re: [ebxml-msg] Comments on 1.09 first half" [2] (added
point about missing section 4.2.1) and "[ebxml-msg] Comments on 1.09 second
half". (My comments on the 1.09 schema were generally applied correctly
but for the problems already mentioned in Chris' email.)
[1] http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00323.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00346.html
[3] http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00351.html
General:
Unless specifically called out to the contrary, all issues
below are editorial.
Anything (maybe, almost anything) at the end of a line in
square brackets is added explanatory comments or suggestions to the editor
which should not appear in the specification directly.
I found a fair number of incorrect references to sections in
the document. Why doesn't this document use links to correct sections so
that edits don't mess them up?
Comments below suggest(ed) adding references to 2.3.6 (then
2.2.6) where they were missing in the 1.09 document. The 2.0 document
instead contains no references at all to 2.3.6. Only the schema
describes where wildcard element content is allowed. (The schema does,
at my suggestion, allow <any> element content on all top-level SOAP
extensions and the Error and Reference elements we define.) I'd
recommend restoring the "#wildcard" lines from 1.09 and adding those mentioned
below.
thanx,
doug
New comments noticed while doing this comparison:
The word "then" appears often instead of a comma. The
document might be significantly shorter the other way.
223 s/normative/non-normative/ [This and
following addition are a TECHNICAL change necessary to avoid problems with
contradictions between Appendix A and the schema available directly from the
web site.]
224 a
The XML Schema document found at http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd is a normative part of this specification and supersedes the
"snapshot" found in Appendix A.
228 Section 1.1 is missing. Suggest adding "1.1
Background" or some such.
618, 621 Move these lines to the left to line up with other
URI values called out in the specification. I guess it made sense to
remove the background highlighting these lines (because it was also used for
examples). Unfortunately, the removal of that attribute messed up the
indentation.
779-781 [TECHNICAL: Remove second
sentence. It's not possible (or worthwhile) to determine whether or not
something is a URI except by checking for a colon.]
877-880 [TECHNICAL:
This section on the Timestamp element doesn't require any particular precision
for the value. All examples in this document are accurate only to
seconds, likely not enough for reliable ordering of received messages (among
other purposes). Timestamps generally include at least milliseconds and
we should be at least that prescriptive.]
1049,1053,1065,1068-1072 [To be
consistent with the typographic changes to sections 2.3.1 and 2.3.2, removing
the background from non-example material in section 4.1.3 would seem
appropriate. The lines referenced in this issue are the remaining cases
of normative material against a grey background. That background should
be removed.]
1114,1116 s/"/"/g [No reason to
use the character entity for quotation marks outside an attribute value.
Just lessens readability of the example.]
1407 Section 6.1 is missing. Suggest making 6.1.1
through 6.1.5 be 6.1 through 6.5. Chapter 6 has no lower or later
sections.
1486-1487 s/or by leaving this attribute out.// [TECHNICAL: I suggested adding a default actor option to the
AckRequested and Acknowledgment elements. Later in the discussion, I was
convinced by others in the group this wasn't a necessary addition and I
withdrew it. Since the sender doesn't know whether another MSH is
authorized to act on behalf of the To Party, toPartyMSH is enough. The
document and schema unfortunately followed my suggestion and not its
withdrawal.]
1529-1530 Remove last sentence in paragraph. [Reasoning as above.]
1713 s/Acknowledgment
Messages/Acknowledgment Messages sent without payload data/
[TECHNICAL: We agreed that MSH doesn't support Ack on Ack.
However, that should apply only to stand-alone Ack messages. Quite
reasonable to send Ack and AckR together with a business response, maybe an
ErrorList (containing warnings) too. Improvement may require some
text changes earlier in the document as well.]
1923-1924 d [These lines uselessly repeat the namespace and
location declarations for our schema. Worse, the schemaLocation
attribute does not have the correct syntax.]
2093 d [Another Acknowledgment/RefToMessageId
instance...]
Section 1
193 s/format type/format or type/
Section 1.1.1
208 s/ebXML SOAP/Basic ebXML SOAP/
211 s/section 4.1.5/section 4.2/
219 s/section 8/sections 8 and 9/
221 s/(section 10.12),/(section 11)./ [note replacement of
trailing comma with period.]
Section 1.1.4
262 s/and understand/ [Hard to read implications.]
263 s/its implications/understand its implications/
263 a [MINOR TECHNICAL: Section needs
words covering inconsistencies between specification text and our
schema. I believe we decided the schema "wins" but that isn't reflected
here without this added paragraph.]
The XML Schema definition for
the ebXML SOAP extensions may conflict with the material in the body of this
specification. In all such cases, the schema supersedes the
specification.
Section 1.2.1
282 s/security and reliability//
287 s/the ebMS/this document/
Section 1.2.3
361 s/the ebMS MAY/this document may/
373 s/The CPA is/In [ebCPP], the CPA is/
377 s/operations/operation/
Section 1.2.4
423 a
Delivery Module -- an abstract service interface an
MSH uses to interact with the communication protocol layers when sending and
receiving messages.
Figure 2.1 s/Authentication, Authorization and
Non-Repudiation services/Security Services (authentication, authorization and
non-repudiation)/ [This and other changes attempt to align the document with
the preceding list.]
s/Header Processing/Header Processing and Parsing/
s|Encryption and / or Digital Signatures|Security Services
(encryption and / or digital signatures)|
s|Send/Receive Transport mapping and binding|(Send/Receive
Transport mapping and binding)|
[Add Reliable Messaging box between "Message Packaging" and
"Delivery Module" because message is packed once but (optionally) send
multiple times).]
Section 2.1
462 s/logical MIME parts/types of MIME parts/
Section 2.1.2
508 s|non-multipart messages, which may occur|receipt of a
SOAP message not packaged within a MIME multipart/related container.
This packaging option is defined in the SOAP 1.1 [SOAP] specification.
Senders MAY use this packaging|
Section 2.2.1
592 s/: version='1.0'// [Very confusing as it stands.
We don't need to tell people what the XML Recommendation actually requires.]
Section 2.3
609 s/attribute/attributes/
Section 2.3.2
631 a [Text is necessary to avoid this URI appearing only in
non-normative examples.]
This schema is available at
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsdand SHOULD be referenced in a schemaLocation attribute in the SOAP
Envelope element.
Section 2.3.6
699 a [Spills into a TECHNICAL issue: Our
intentions should lean towards addition of new SOAP extensions rather than
extending the ones we've defined when adding entirely new features.]
[Don't include next paragraph if we decide to re-insert foreign attributes
anywhere.]
This extension mechanism is an exclusive
choice. None of the elements defined in this specification support
foreign namespace-qualified attributes. The wildcard elements are
provided wherever extensions might be required for private extensions or
future expansions to the protocol.
Note: Extension elements
should be included in ebXML SOAP extensions only when they expand the
semantics of that particular element. This mechanism might be used, for
example, to extend the eb:Error element by providing additional structured
information about a problem. Wholly new features should be implemented
using separate SOAP extensions.
Section 2.3.9
717-722 d [Defines SOAP, which shouldn't be necessary in our
specification.]
OR [much prefer previous option but at least following change
would define SOAP properly.]
718 s/REQUIRED SOAP mustUnderstand attribute on SOAP Header
extensions/SOAP mustUnderstand attribute/
722 a [For either choice above.]
For all ebXML SOAP
Header extensions defined in this specification, the SOAP mustUnderstand
attribute is REQUIRED and MUST have the value '1'. A compliant MSH MUST
parse (but not necessarily support features associated with) all elements and
attributes defined in this document.
Section 2.3.10
722 a [Defining a new section introducing the soap:actor
attribute with the existing 2.3.10 and 2.3.11 becoming 2.3.10.1 and 2.3.10.2
(subsections). This section does not redefine the SOAP actor attribute
(unlike lines 717-722 I'd recommend we delete).]
2.3.10 SOAP actor
attribute
All ebXML SOAP Header extensions defined in this specification
that may be handled by an MSH node other than the ultimate recipient of a
message allow inclusion of the SOAP actor attribute. If present, this
attribute SHALL have one of the values defined in the following two
subsections or the SOAP-defined value http://schemas.xmlsoap.org/soap/actor/next.
[I've been told the actor described in existing
section 2.3.11 will support an intermediate node acting on behalf of the To
Party in returning an Acknowledgment (prior to the ultimate recipient seeing
the message). That's a great use case, handling (for example) trusted
store and forward MSH implementations in the destination's DMZ. If
that's the case, we need to be clear this actor value is specifically for use
in the AckRequested and Acknowledgment elements. I don't think it's
useful elsewhere.
Changing the above last
sentence to read "If present in the AckRequested or
Acknowledgment elements (see sections 7.3.1 and 7.3.2), this attribute SHALL
have one of the values defined in the following two subsections." would work since the other use of soap:actor (in eb:SyncReply)
is very explicit about allowed values.]
732 s/when used in the context of the//
729 a Such an actor MAY ignore SOAP Header extensions
targeted to "urn:oasis:names:tc:ebxml-msg:actor:nextMSH" but
not the "http://schemas.xmlsoap.org/soap/actor/next"
actor (which all SOAP nodes, including an ebXML MSH, MUST adopt).
Section 2.3.11
732 s/when used in the context of the//
[TECHNICAL issue: Current text leaves
reader asking "What is the semantic difference between toPartyMSH and the
default SOAP actor? When would a sending MSH specify toPartyMSH rather
than leaving the soap:actor attribute out?" This is not clear in this
document and if I need to check the archives for the reasoning we're leaving
something important out.]
Section 3.1.2
812-818 [split into 2 paragraphs one sentence later]
812,813 s/the appropriate handling of the
conflict is undefined by this specification/the conflict MUST be reported to
the Sending MSH/ [TECHNICAL: This discussion
(including following two points as well) did not reflect the decision to
REQUIRE an error when a message / CPA consistency problem is detected.]
815 s/If a receiver chooses to generate
an error as a result of a detected inconsistency,/If a Receiving MSH detects
an inconsistency,/
816,817 s/If it chooses to generate an error because the
CPAId/If the CPAId/ [This error shouldn't be optional either.]
Section 3.1.3
831 s/schema/scheme/ [Already mentioned (again) in Chris'
message.]
Section 3.1.4
838-840 d [This discussion just confuses the issue because of
its use of the word "role" without reference to the Role element. If
there is a specific element in the CPA or BPSS documents that could be
referenced here, fine. Otherwise don't mention it.]
Section 3.1.4.1
850-851 [TECHNICAL: Remove second
sentence. It's not possible (or worthwhile) to determine whether or not
something is a URI except by checking for a colon. Note as well: Unlike
PartyId@type, we don't RECOMMEND that this attribute be a URI.]
[TECHNICAL issue: How are unrecognised
services (those not mentioned in the BPSS referenced from the CPA for example)
handled? Need to define error handling for that case.]
Section 3.1.6.1
872-873 [As Chris has mentioned, the second sentence of this
paragraph should be removed. I mentioned earlier that RFC2822 mentions
the local part of email addresses but doesn't distinguish between the left and
right sides of a message id except with respect to possible generation
rules. It never mentions "local part" when describing message id
values.]
Section 3.1.6.3
885 s/messages,/messages (see section 4.2),/
886 s/section 4.1.5/section 4.2.1.1/
Section 3.1.6.4
[TECHNICAL issue: Should describe clock
synchronization between MSH nodes. Is it required? Does it not
matter because the durations expected are large values? I would prefer
explicit mention of synchronization or clock accuracy as a deployment issue
rather than ignoring the issue entirely. This is the only place in our
specification where time values must be compared.]
Section 3.1.9
916,921,924,926 [replace "someType" and similar labels with
example values, this is an example]
926 d [Ignore previous comment about this line if you can
perform this deletion. From the service and action values, this is a new
order -- what message is referenced?]
Section
3.2.1
949 a [Was a correction to previous reference to 2.3.6
material:
965 s/any namespace-qualified element content belonging to
a foreign namespace// [References to 2.3.6 should be consistent in these
lists.]]#wildcard (see section 2.3.6 for
details)
Section 3.2.1.1
969 a [TECHNICAL issue: For schema references, should allow a
"namespace" attribute. The location attribute in that case would be a
preferred schemaLocation for the described schema. This would also
require a small addition to the ebXML Messaging schema.]
namespace -- If present, identifies the target namespace
of the schema document found at the above
location.
Section 3.2.2
979-981 [TECHNICAL issue: Error
requirements here are overly restrictive. The problem might be a
security failure accessing content elsewhere on the Internet, for
example. Suggest adding something to the effect of "When no other defined error applies...".]
Section 4.1
1009 [move last sentence to end of line 1006 (the previous
paragraph)]
Section 4.1.2.1
1035 s/payload./payload(s). The MSH takes and active
part in providing these security measures, as part of its generation of the
SOAP message and through the parameters it passes to the underlying
communication protocol./
Section 4.1.3
1099 a [Current xsi:schemaLocation doesn't include the
namespace identifier for our schema, resulting in illegal syntax.
Probably, the second tuple in this attribute value (after addition below)
should be moved to separate xsi:schemaLocation attributes on the soap:Header
and soap:Body elements. Otherwise, we conflict with our own "one
namespace per such attribute" recommendations.]
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
Section 4.1.4.1
1146-1150 [Move before line 1143, making this the first
paragraph and allows it to introduce use of XML Signature.]
Section 4.1.4.2
1154-1157 [TECHNICAL issue: This text
disallows a receiving MSH returning a message saying "party B definitely
received the message with id XYZ". Since that party likely has the
message stored with party A's signatures, having to say "party B received the
message with id XYZ and these contents" seems a burden only some relationships
will require. It also stretches the previous definition of a signed
message to mean just the inclusion of a Signature element in the
soap:Header. Inclusion of ds:Reference elements should be an option even
for signed acknowledgments.]
[TECHNICAL issue: Unlike the Manifest
element we're defining, the dsig:Signature element is not required to
reference every payload in a message. (Line 1084 says "requiring
signing".) The copying described here is likely insufficient for the
"and these contents" claim you want.]
Section 4.1.4.3
1160 s/,//
Section 4.1.4.4
1166 s/integrity check CRCs of/digests and comparisons of/
Section 4.1.4.5
1169 s/document(s)/document/
1068-1078 [TECHNICAL issue: It's not
clear how XML Encryption will address this problem except for payloads
expressed as XML documents.]
Section 4.2
1251,1254 s/Faults/Fault messages/ [should not pluralize the
name of an element even if only part is bold]
1257 [The section 4.2.1 is missing -- we skip from 4.2
Error Handling Module to 4.2.1.1 Definitions. We should at least have an
intermediate heading or (probably easier) make 4.2.1.1 be 4.2.1.]
Section 4.2.3
1279 [TECHNICAL issue: I had a suggestion in this section to add an
actor attribute to the ErrorList element. Even though
intermediates may never hear about errors and DFN messages may take other
routes back to the originator, the problem is likely reduced by the lack of
duplicate elimination at intermediaries. I'd support adding this
attribute in support of store-and-forward intermediaries performing retries to
later destinations if someone proposes it again. I'm simply
removing my suggestion because it didn't get any notice last time
and might induce feature creep.]
1281 a
#wildcard (see section 2.3.6 for details)
1282 s/reported then/reported,/
Section 4.2.3.1
1284 s/of any of the Error elements/of the grouped Error
elements/
1285 s/, otherwise/; otherwise,/
Section 4.2.3.2
1294 a
#wildcard (see section 2.3.6 for details)
1295 s/The content of the Description element MAY contain
error message text.// [TECHNICAL: As Chris mentioned, the
Description element MUST have content if present.]
Section 4.2.3.2.2
1301 s/errorCodes/errorCode attribute values/ [Should
not pluralize our element names.]
s/then//
1303 s/errorCodes/errorCode value(s)/
1302-1304 [TECHNICAL issue: Our list of
codes is comprehensive due to its inclusion of OtherXML and Unknown. How
can "legal" additions to the list of error codes be created without violating
these restrictions?]
Section 4.2.3.2.4
1311 s/problem./problem. (Other Error elements in the
list may describe problems preventing further processing.)/
1312 s/there is/there was/
Section 4.2.3.2.5
1315 a The value of this attribute MUST be a URL. [TECHNICAL issue: Need some text requiring the value of
this attribute be a URL. Otherwise the later discussion doesn't make
that much sense.]
1319-1320 s/in the format cid:23912480wsr, where the text
after the ":" is the value of the MIME part's content-id/using URI scheme
"cid"/ [Don't redefine something well-described in another
specification.]
1318-1320 [A previous TECHNICAL issue
about these lines has been partially resolved through limiting section 2.1.6
to REQUIRING a SOAP Fault only in the outermost Message Package.
Nonetheless, the ebXML handler is unlikely to be invoked when the payload
containers or other MIME packaging is incorrect.]
Section 4.2.4.1
1352 a With the possible exception of retries to the message
in error, additional messages in the conversation MUST NOT be sent after
receiving any message containing such an ErrorList.
Section 4.2.4.1.1
1359 s/header SHOULD/header and no ErrorList with
highestSeverity set to Error SHOULD/
1360 [TECHNICAL issue: What does "ignore"
mean in the context of HTTP with SyncReply true?]
Section 4.2.4.2
1369-1370 [TECHNICAL issue: Unparsable
messages will be caught by the SOAP processor underlying most "layered" MSH
implementations. It's not possible for us to specify the action of that
SOAP processor.]
Section 4.2.4.3
1375 s/not being sent as a result of processing of an earlier
message/being sent on its own, with no payload data/
1376 s/if the highestSeverity is set to Error,//
[TECHNICAL: Actually, this section still
makes little sense. I believe an attempt was made to describe the
Service and Action when ErrorList is sent on its own. That may occur
regardless of the highestSeverity and the problem is mostly addressed through
the two changes above. In addition, "processing" is used in the first
paragraph without context and we still need to remind users that ErrorList
with highestSeverity="Error" can't be combined with payload data.
Something at the end of the first paragraph like "This
method MUST NOT be used if the highestSeverity is "Error". No further
processing of the message in error could have occurred in that case."
may help.]
Section 5
[Entire section would be better placed as section
4.3.]
Section 5.1
1398 s/has the following attributes/consists of/
1395 a
#wildcard (see section 2.3.6 for details)
1406-1408 [TECHNICAL issue: This seems backwards. SyncReply s/b
allowed if syncReplyMode is none (for the Acknowledgment message to come back
synchronously); if syncReplyMode is not none and it's a synchronous
communication protocol in use, SyncReply MUST be present. Further,
intermediaries may have no idea about the CPA in use and could easily violate
these overly strict restrictions (e.g. an intermediary just prior to the To
Party requesting a synchronous hop-to-hop Acknowledgment).]
[TECHNICAL issue: During the discussion of this
addition we agreed to add words about SOAP processors w/o full MSH
understanding and their need to forward a like extension. Those words
are missing. Note: Intermediate MSH nodes MAY forward using a different
protocol than the incoming message and are therefore NOT REQUIRED to insert a
copy of this element in all cases.]
[TECHNICAL issue: Should say the
SyncReply element is not allowed in a synchronous response message.]
Section 6
1406 [TECHNICAL: Need lines for the interaction of
SyncReply with other elements. Probably a new section saying "The SyncReply element MAY be present on any outbound message
sent using a synchronous communication protocol." is needed.]
Section 6.1.4
1416-1417 s/except the StatusRequest element.// [Introduce in
section 8.2.3]
1420 [Why is this bullet all alone? Should be part of
previous paragraph after recommended deletions.]
Section 7
1426 a
For the purposes of this document, "Reliable Messaging" is
defined to mean sending a message that both parties will know was received by
the To Party's application intact once and only once, detect a permanent
failure situation or retry until giving up.
Note: Failure remains an option even when making full use of
ebXML Reliable Messaging. In addition, this addresses duplication only
when caused by errant MSH implementations or communication protocols:
Applications may send distinct messages containing the same payload and
receiving applications may need to handle these duplicates.
1429 s/flexible/flexible with respect to intermediaries/
1429 a
The protocol is also flexible with respect to the features
implemented by communications protocols, ebXML MSH software and
applications. Options are available controlling MSH implementation of
well-defined segments of the overall reliability requirements. Most of
the following discussion assumes all ebXML reliable messaging options are
enabled.
Note: This assumption in the text should not prevent use of
reliable communication protocols, idempotent application semantics, et cetera
instead. ebXML Reliable Messaging semantics should be considered
whenever such alternatives are not available or the MSH implementation is more
efficient.
1435 s/once/once (due to retries or the nature of the
communications protocol in use)/
1436 a Retries initiated by a Sending MSH and duplicates
introduced by an unreliable communication protocol MUST be handled by the
Receiving MSH or higher application layers at the To Party.
Section 7.1
1443 s/SHOULD/MUST/
1455 a [TECHNICAL: All of the following
information is presently missing which is internally inconsistent.]
In order to associate an Acknowledgment element with the
corresponding application state and to send retries, a Sending MSH SHOULD save
the following in persistent storage:
MessageId of the sent message
Timestamp, RetryInterval and remaining Retries (elements
and parameters to the MSH), providing support for a queue of messages
awaiting retry or application failure notification
Entire SOAP message for use in later retries
links to application state for any required notifications
The possible notifications from a Sending MSH to the From
Party application are:
Successful delivery (Sending MSH has received an
Acknowledgment element in a message not containing an ErrorList)
Acknowledged delivery with errors (Sending MSH has received
a message containing both Acknowledgment and ErrorList elements; processing
MAY have continued at the To Party in this case)
Timeout (TimeToLive expired or Retries have been exhausted)
Section 7.3.1
1473 a
#wildcard (see section 2.3.6 for
details)
Section 7.3.1.2
1500-1502 [TECHNICAL issue: I previously
suggested this case should result in an Error because it was inconsistent with
the other Inconsistent errors, resulting in just a Warning. Now, the
text requires Inconsistent/Warning where NotSupported/Error would be
appropriate. It's gotten worse and should be Inconsistent/Error or the
combination of that with a NotSupported/Error option.]
Section 7.3.2
1515-1517 s/The RefToMessageId element in an Acknowledgment
element is used to identify the message being acknowledged by its MessageId.//
[TECHNICAL: This isn't sensible and is a massive change
from 1.0. Why would an Acknowledgment message be bundled into another
message that isn't in response to the message in question?]
1524 d [Again, this isn't
reasonable.]
1526 a
#wildcard (see section 2.3.6 for
details)
Section 7.3.2.3
1535-1537 d
Section
7.3.2.4
1541 a This form SHOULD be used for hop-to-hop Acknowledgment
messages from intermediate nodes, especially when the message also contains
data from later nodes.
1543 a This form SHOULD be used for all end-to-end
Acknowledgment messages.
Section 7.3.2.5
1554 s/derived/derived (as described in section 4.1.4.2)/
[Note: This section contains more references than it did before. It
still doesn't refer to 4.1.4.2 but should. Some of the recent reference
additions may be worth removing.]
1557 s/element/list/ [TECHNICAL: Again, I
disagree with this requirement because it disallows the To Party MSH
acknowledging receipt of a message and signing the acknowledgment without also
describing the contents. The message already has the RefToMessageId
element and any disagreements about the contents of that message would be
covered through the signing the original party did. I would prefer to
strike this sentence and much of the surrounding discussion. It's a bit
worse now that the text attempts to define "signed Acknowledgment Message" two
ways simultaneously (signed Ack either means "it contains both Ack and
Signature" or "contains both Ack with Reference list and Signature").]
Section 7.3.2.6
1570 d
Section 7.3.2.7
1577 a [TECHNICAL: I could go either way
here (prefer either Action) but we haven't made a choice yet.]
When an Acknowledgment message and Error message are
combined without additional payloads (regardless of the highestSeverity
attribute of the included ErrorList element), the service and action described
in 4.2.4.3 MUST be used.
Section
7.3.2.8
1580 [Note TECHNICAL issue already
raised about this last sentence. The inability to send a reliable Error
(even when a Warning and combined with payload data) in the current
text should be resolved by killing this sentence. This issue
was resolved during the last face-to-face and Chris most recently mentioned
it.]
Section 7.4.1
1568-1584 [This section repeats some of 3.1.7 and adds new
information. The new information belongs better in 3.1.7. All that
should be left here is information about the relation between the CPA flag and
the DuplicateElimination element. At the moment, the semantics of the
DuplicateElimination element are described again -- without reference to
section 3.1.7.]
1503 s/duplicate messages to be ignored/the To Party
application never to see duplicate messages/
Section 7.4.2
1601-1603 d [This section attempts to re-define an element
already described in section 7.3.1 and adds no new information. Just
nuke the section. At most, mention that some configuration information
must be available to the From Party MSH to determine whether or not an
acknowledgment may be requested and whether or not it could be signed.]
Section 7.4.4
1613 s/between retries/between later retries/
Section 7.4.6
1621-1622 s/The timestamp for a reliably sent message (found
in the message header), plus its PersistDuration (found in the CPA), must be
greater than its TimeToLive (found in the message header)./For a reliably
delivered message, TimeToLive MUST conform to:
TimeToLive < TimeStamp + PersistDuration
where TimeStamp comes from MessageData and PersistDuration
is found in the CPA./ [The equation should describe something under MSH
control when sending a message. Similar syntax to 7.4.5 makes it easier
to read.]
Section 7.4.7
1630-1631 s/If the value of syncReplyMode is none and a
SyncReply element is present,/If the value of syncReplyMode is not none, the
communications protocol is synchronous and a SyncReply element is not
present in a message,/ [This sentence should be joined with the previous
paragraph.]
[TECHNICAL: The current wording disallows
sending MSH signals synchronously. Above change allows SyncReply even
when syncReplyMode is none (synchronous signals) but doesn't address problems
raised earlier around heterogeneous routes to the destination and
intermediaries not being party to the CPA.]
Section 7.5.1
1655 a
6. Notify application of delivery success or failure (if
requested).
Section 7.5.2
1665-1666 s/generate an Acknowledgment Message (see section
7.5.3). Follow/follow/
1673-1676 [Move everything from this paragraph except the
first sentence into 7.5.3, assuming that section continues to have some useful
content. This is general information about all Acknowledgment messages
generated. Replace these sentences with ", as described in section
7.5.3".]
Section 7.5.3
1689-1691 d [Because the RefToMessageId element adds no value
to an Acknowledgment element, this paragraph means little.
If anything is necessary, section 7.3.2 should (somewhere) remind
people, as is done for Error messages, that the MessageData/RefToMessageId
value must be set appropriately.]
1692-1703 m [Most of this section attempts to redefine what's
already in 7.3.2. and 7.3.2.7 without adding much value and confusing some
issues (e.g. some bullets are generally true while others apply only to
stand-alone Ack messages). Copy what's not already in those sections
appropriately and make sure that section is now consistent. This
section (7.5.3) should be left with only a reference to 7.3.2 and the
"persisted storage" description from 7.5.2. Maybe, the last 3 bullets
could stay here.]
Section 7.5.5
1725-1737 m [This section should come after what's now 7.5.6,
reverse two sections]
1726 s/duplicate/duplicate and DuplicateElimination is
present/
1728 s/it/first that/
1729 s/that matches/matching/
1730 s/then/,/
1731 s/MSH that sent the received message/Sending MSH for the
duplicate message/
1732 s/and if/and/
1733 s/then/,/
s/that//
1734 s/same//
1735 s/that was//
1737 s/Message/Message (as described in section 7.5.3)/
Section 7.5.6
1744 s/the same RefToMessageId as/a RefToMessageId value
matching the MessageId of/
1752-1753 s/sent to the sender Party A)// [Note unbalanced
parentheses are also fixed by removing this unnecessary text.]
1753 a [TECHNICAL: If the recipient
ensures a duplicate is identical, we should say what happens if the check
fails.]
2a) The recipient of a duplicate message MAY confirm the
duplicate is indeed identical to the original, allowing for changes introduced
by intermediate nodes. If this is found not to be the case, the
receiving MSH SHOULD issue an error with errorCode of Inconsistent and a
severity of Error.
Section 8
1777 [Reword to use "A Message Status Response message" as
the subject, matching the previous bullet's style.]
Section 8.2
1827 a
#wildcard (see section 2.3.6 for details)
Section 8.3
1849 a
#wildcard (see section 2.3.6 for
details)
Section 8.3.3
1864 [TECHNICAL issue: We had some reason
for handling this requester error in the response element rather than using an
ErrorList. Did this have something to do with the possibility of sending
multiple StatusRequest elements in the same message? Either way, we need
text describing why this isn't handled using an Error message.]
1867-1872 [TECHNICAL issue: This expands
the list of possible values from those in MSH 1.0 without explanation.
Hadn't we agreed the additional status values (Processed and Forwarded) are
likely to be information the MSH doesn't know and shouldn't tell an outside
party?]
Section 9.1
1910 s|Boundary"|Boundary"; type="text/xml";
start="gobblelygook"|
1913 a
Content-Id: <gobbledygook>
1921 [Correct the xsi:schemaLocation for the ebXML MSH
namespace to use proper syntax: Repeat the string (identically).]
Section 9.2
1967 [Correct the xsi:schemaLocation for the ebXML MSH
namespace to use proper syntax: Repeat the string
(identically).]
Section 10
1993-1994 [Remove second sentence. Information is
better expressed in the next paragraph.]
Section
10.1
2006 a
#wildcard (see section 2.3.6 for details)
Section 10.1.1
2010 s/SequenceNumber/REQUIRED SequenceNumber/
[TECHNICAL issue: I made a mistake in this
suggestion. The SequenceNumber element is required inside an optional
element and therefore is not REQUIRED of all implementations. Remove
word again (sorry).]
Appendix B.2.2
2485 a [Current xsi:schemaLocation doesn't include the
namespace identifier for our schema, resulting in illegal syntax.
Probably, the second tuple in this attribute value (after addition below)
should be moved to separate xsi:schemaLocation attributes on the soap:Header
and soap:Body elements. Otherwise, we conflict with our own "one
namespace per such attribute" recommendations.]
http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
Appendix B.2.4
[I won't repeat all of the technical discussions of problems
in this section. My memory dims this late in the game but I seem to
recall issues with requiring SOAP Fault separately (since the SOAP processor
isn't something we're defining) and problems using the Fault element
asynchronously in any case (since it provides no context for the error
described).]
Appendix B.2.5
[I'm not sure this section is as clear as it could be.
It seems David had a different interpretation. Might need some
rewording.]
2555 s/Post/Post if the message is processed by an ebXML MSH
handler/
Appendix B.3.2
2622-1624 d [This header is defined only for HTTP
communication.]
2638 d [as above]
2656 [Correct the xsi:schemaLocation for the ebXML MSH
namespace to use proper syntax: Repeat the string (identically).]
2676 [Correct the xsi:schemaLocation for the ebXML MSH
namespace to use proper syntax: Repeat the string
(identically).]
References
[Entire section and all references in the text should
consistently use [RFC1234] for references to these documents. XMLMEDIA,
IPSEC,PGP/MIME,S/MIME* and TLS all violate this consistency.]
[Sort the RFC entries by their number.]
[Entire section should use a consistent format for the
references, order and contain similar information. For example,
references to RFC documents should all include the title of the RFC and
(probably, I don't remember the IETF standards) IETF RFC1234.]
[For documents available online (such as all ebXML documents
but likely excluding the RFC's, letting people head to their favourite RFC
source), please include URL values.]
[All references to W3C documents should consistently include
the date in their URL values.]
2787-2788 [This should refer to the section of the Unicode
Standard that defines UTF-8. This is an incomplete definition for the
term UTF-8.]
