[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)
Chris/David: I believe you need the full-blown version of Acrobat for this purpose, and that is not freely downloadable. Can either one of you post a PDF version of the 2.0 spec? Thanks, -Arvola -----Original Message----- From: Christopher Ferris <chris.ferris@sun.com> To: Arvola Chan <arvola@tibco.com> Cc: Ralph Berwanger <rberwanger@bTrade.com>; Doug Bunting <dougb62@yahoo.com>; ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Thursday, January 17, 2002 12:07 PM Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09) Use Acrobat which, when installed adds a button to Word that allows one to "print" to distiller. Arvola Chan wrote: > David distributed a Word document. How do I generate a PDF equivalent for > it? > > Thanks, > -Arvola > > -----Original Message----- > From: Christopher Ferris <chris.ferris@sun.com> > To: Ralph Berwanger <rberwanger@bTrade.com> > Cc: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>; > ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> > Date: Thursday, January 17, 2002 11:44 AM > Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09) > > > >>+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.] >>> >>> >>> >>> >> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC