[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)
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.] >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC