+1
PDF is also a little more platform neutral and more
accessible to those of us without MSFT Word.
Cheers,
Chris
Ralph Berwanger wrote:
> 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.
>
>
>
> 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 <dougb62@yahoo.com <mailto:dougb62@yahoo.com>>
> To: ebxml-msg@lists.oasis-open.org
> <mailto:ebxml-msg@lists.oasis-open.org>
> <ebxml-msg@lists.oasis-open.org
> <mailto:ebxml-msg@lists.oasis-open.org>>
> 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
> <http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.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.]
>
>
>