Arvola,
We have always had that problem,
that is why we elected to use the PDF formatted file as the record copy when
making comments. Depending on local page settings, Word will format the
document changing which line text occurs on. I can tell you from previous
experience editing these documents that if we do not standardize on the PDF
file, we will have continued difficulty.
Ralph
Berwanger
-----Original Message----- From:
Arvola Chan [mailto:arvola@tibco.com] Sent: Thursday, January 17, 2002
1:13 PM To: Doug Bunting;
ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Fw: Old
comments (outstanding since 1.09)
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.
Thanks,
-Arvola
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
and 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
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
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
#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
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
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
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
#wildcard (see section 2.3.6 for details)
Section 8.3
#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
#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.]
|