[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)
+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