OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09)

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.
-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org <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


  • 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.

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/&quot;/"/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 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 and (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.]
  • 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.]
  • 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.]
  • 885 s/messages,/messages (see section 4.2),/
  • 886 s/section 4.1.5/section
  • [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)
  • 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)]
  • 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.]
  • 1146-1150 [Move before line 1143, making this the first paragraph and allows it to introduce use of XML Signature.]
  • 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.]
  • 1160 s/,//
  • 1166 s/integrity check CRCs of/digests and comparisons of/
  • 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 Definitions.  We should at least have an intermediate heading or (probably easier) make 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,/
  • 1284 s/of any of the Error elements/of the grouped Error elements/
  • 1285 s/, otherwise/; otherwise,/
  • 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.]
  • 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?]
  • 1311 s/problem./problem.  (Other Error elements in the list may describe problems preventing further processing.)/
  • 1312 s/there is/there was/
  • 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.]
  • 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.
  • 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?]
  • 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.]
  • 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)
  • 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)
  • 1535-1537 d
  • 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.
  • 1554 s/derived/derived (as described in section [Note: This section contains more references than it did before.  It still doesn't refer to 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").]
  • 1570 d
  • 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 MUST be used.
  • 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 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.]
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).]
  • [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.]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC