Doug:
I have a hard time following your line number references. I
looked at the Word document online and also printed out a hard copy. The
frustrating thing is that the line numbers I see in the online Word document do
not even match those in the printed copy. In many instances, your referenced
line numbers match neither the online Word document nor the print
out.
Does anyone else encounter such line numbering problem? I am
using the version obtained from http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00055.html
viewed without change bars.
Thanks,
-Arvola
-----Original Message-----
From:
Doug Bunting <>
To:
<>
Date:
Thursday, January 17, 2002 7:07 AM
Subject: [ebxml-msg] Fw: Old
comments (outstanding since 1.09)
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.]
