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