Use Acrobat which, when installed adds a button to Word
that allows one to "print" to distiller.
Arvola Chan wrote:
> David distributed a Word document. How do I generate a PDF equivalent for
> it?
>
> Thanks,
> -Arvola
>
> -----Original Message-----
> From: Christopher Ferris <chris.ferris@sun.com>
> To: Ralph Berwanger <rberwanger@bTrade.com>
> Cc: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>;
> ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
> Date: Thursday, January 17, 2002 11:44 AM
> Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09)
>
>
>
>>+1
>>
>>PDF is also a little more platform neutral and more
>>accessible to those of us without MSFT Word.
>>
>>Cheers,
>>
>>Chris
>>
>>Ralph Berwanger wrote:
>>
>>
>>>Arvola,
>>>
>>> We have always had that problem, that is why we elected to use the
>>>PDF formatted file as the record copy when making comments. Depending
>>>on local page settings, Word will format the document changing which
>>>line text occurs on. I can tell you from previous experience
>>>editing these documents that if we do not standardize on the PDF file,
>>>we will have continued difficulty.
>>>
>>>
>>>
>>>Ralph Berwanger
>>>
>>>
>>>
>>> -----Original Message-----
>>>From: Arvola Chan [mailto:arvola@tibco.com]
>>>Sent: Thursday, January 17, 2002 1:13 PM
>>>To: Doug Bunting; ebxml-msg@lists.oasis-open.org
>>>Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09)
>>>
>>> Doug:
>>>
>>>
>>>
>>> I have a hard time following your line number references. I looked
>>> at the Word document online and also printed out a hard copy. The
>>> frustrating thing is that the line numbers I see in the online Word
>>> document do not even match those in the printed copy. In many
>>> instances, your referenced line numbers match neither the online
>>> Word document nor the print out.
>>>
>>>
>>>
>>> Does anyone else encounter such line numbering problem? I am using
>>> the version obtained from
>>> http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00055.html
>>> viewed without change bars.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> -Arvola
>>>
>>> -----Original Message-----
>>> From: Doug Bunting <dougb62@yahoo.com <mailto:dougb62@yahoo.com>>
>>> To: ebxml-msg@lists.oasis-open.org
>>> <mailto:ebxml-msg@lists.oasis-open.org>
>>> <ebxml-msg@lists.oasis-open.org
>>> <mailto:ebxml-msg@lists.oasis-open.org>>
>>> Date: Thursday, January 17, 2002 7:07 AM
>>> Subject: [ebxml-msg] Fw: Old comments (outstanding since 1.09)
>>>
>>> The following material includes issues I've raised in the past
>>> but have not been discussed on the list or addressed in the
>>> specification. I've edited the list to remove things no longer
>>> relevant or already handled. The line numbers are for the 2.0
>>> document in PDF form (or Word form without change markings) and
>>> the suggestions start from the current text.
>>>
>>> The historical messages of interest are "[ebxml-msg] Comments on
>>> 1.09 first half" [1],"Re: [ebxml-msg] Comments on 1.09 first
>>> half" [2] (added point about missing section 4.2.1) and
>>> "[ebxml-msg] Comments on 1.09 second half". (My comments on the
>>> 1.09 schema were generally applied correctly but for the
>>> problems already mentioned in Chris' email.)
>>>
>>> [1]
>>>
>>>
> http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00323.html
>
>>> [2]
>>>
>>>
> http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00346.html
>
>>> [3]
>>>
>>>
> http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00351.html
>
>>> General:
>>>
>>> * Unless specifically called out to the contrary, all issues
>>> below are editorial.
>>> * Anything (maybe, almost anything) at the end of a line in
>>> square brackets is added explanatory comments or
>>> suggestions to the editor which should not appear in the
>>> specification directly.
>>> * I found a fair number of incorrect references to sections
>>> in the document. Why doesn't this document use links to
>>> correct sections so that edits don't mess them up?
>>> * Comments below suggest(ed) adding references to 2.3.6
>>> (then 2.2.6) where they were missing in the 1.09
>>> document. The 2.0 document instead contains no references
>>> at all to 2.3.6. Only the schema describes where wildcard
>>> element content is allowed. (The schema does, at my
>>> suggestion, allow <any> element content on all top-level
>>> SOAP extensions and the Error and Reference elements we
>>> define.) I'd recommend restoring the "#wildcard" lines
>>> from 1.09 and adding those mentioned below.
>>>
>>> thanx,
>>> doug
>>>
>>> -----------------------------------------------------------------
>>>
> -------
>
>>> New comments noticed while doing this comparison:
>>>
>>> * The word "then" appears often instead of a comma. The
>>> document might be significantly shorter the other way.
>>> * 223 s/normative/non-normative/ [This and following
>>> addition are a TECHNICAL change necessary to avoid
>>> problems with contradictions between Appendix A and the
>>> schema available directly from the web site.]
>>> * 224 a
>>> The XML Schema document found at
>>>
>>>
> http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
>
>>> is a normative part of this specification and supersedes
>>> the "snapshot" found in Appendix A.
>>> * 228 Section 1.1 is missing. Suggest adding "1.1
>>> Background" or some such.
>>> * 618, 621 Move these lines to the left to line up with
>>> other URI values called out in the specification. I guess
>>> it made sense to remove the background highlighting these
>>> lines (because it was also used for examples).
>>> Unfortunately, the removal of that attribute messed up the
>>> indentation.
>>> * 779-781 [TECHNICAL: Remove second sentence. It's not
>>> possible (or worthwhile) to determine whether or not
>>> something is a URI except by checking for a colon.]
>>> * 877-880 [TECHNICAL: This section on the Timestamp element
>>> doesn't require any particular precision for the value.
>>> All examples in this document are accurate only to
>>> seconds, likely not enough for reliable ordering of
>>> received messages (among other purposes). Timestamps
>>> generally include at least milliseconds and we should be
>>> at least that prescriptive.]
>>> * 1049,1053,1065,1068-1072 [To be consistent with the
>>> typographic changes to sections 2.3.1 and 2.3.2, removing
>>> the background from non-example material in section 4.1.3
>>> would seem appropriate. The lines referenced in this
>>> issue are the remaining cases of normative material
>>> against a grey background. That background should be
>>> removed.]
>>> * 1114,1116 s/"/"/g [No reason to use the character
>>> entity for quotation marks outside an attribute value.
>>> Just lessens readability of the example.]
>>> * 1407 Section 6.1 is missing. Suggest making 6.1.1 through
>>> 6.1.5 be 6.1 through 6.5. Chapter 6 has no lower or later
>>> sections.
>>> * 1486-1487 s/or by leaving this attribute out.//
>>> [TECHNICAL: I suggested adding a default actor option to
>>> the AckRequested and Acknowledgment elements. Later in
>>> the discussion, I was convinced by others in the group
>>> this wasn't a necessary addition and I withdrew it. Since
>>> the sender doesn't know whether another MSH is authorized
>>> to act on behalf of the To Party, toPartyMSH is enough.
>>> The document and schema unfortunately followed my
>>> suggestion and not its withdrawal.]
>>> * 1529-1530 Remove last sentence in paragraph. [Reasoning
>>> as above.]
>>> * 1713 s/Acknowledgment Messages/Acknowledgment Messages
>>> sent without payload data/ [TECHNICAL: We agreed that MSH
>>> doesn't support Ack on Ack. However, that should apply
>>> only to stand-alone Ack messages. Quite reasonable to
>>> send Ack and AckR together with a business response, maybe
>>> an ErrorList (containing warnings) too. Improvement may
>>> require some text changes earlier in the document as well.]
>>> * 1923-1924 d [These lines uselessly repeat the namespace
>>> and location declarations for our schema. Worse, the
>>> schemaLocation attribute does not have the correct syntax.]
>>> * 2093 d [Another Acknowledgment/RefToMessageId instance...]
>>>
>>> -----------------------------------------------------------------
>>>
> -------
>
>>> Section 1
>>>
>>> * 193 s/format type/format or type/
>>>
>>> Section 1.1.1
>>>
>>> * 208 s/ebXML SOAP/Basic ebXML SOAP/
>>> * 211 s/section 4.1.5/section 4.2/
>>> * 219 s/section 8/sections 8 and 9/
>>> * 221 s/(section 10.12),/(section 11)./ [note replacement of
>>> trailing comma with period.]
>>>
>>> Section 1.1.4
>>>
>>> * 262 s/and understand/ [Hard to read implications.]
>>> * 263 s/its implications/understand its implications/
>>> * 263 a [MINOR TECHNICAL: Section needs words covering
>>> inconsistencies between specification text and our
>>> schema. I believe we decided the schema "wins" but that
>>> isn't reflected here without this added paragraph.]
>>> The XML Schema definition for the ebXML SOAP extensions
>>> may conflict with the material in the body of this
>>> specification. In all such cases, the schema supersedes
>>> the specification.
>>>
>>> Section 1.2.1
>>>
>>> * 282 s/security and reliability//
>>> * 287 s/the ebMS/this document/
>>>
>>> Section 1.2.3
>>>
>>> * 361 s/the ebMS MAY/this document may/
>>> * 373 s/The CPA is/In [ebCPP], the CPA is/
>>> * 377 s/operations/operation/
>>>
>>> Section 1.2.4
>>>
>>> * 423 a
>>> Delivery Module -- an abstract service interface an MSH
>>> uses to interact with the communication protocol layers
>>> when sending and receiving messages.
>>> * Figure 2.1 s/Authentication, Authorization and
>>> Non-Repudiation services/Security Services
>>> (authentication, authorization and non-repudiation)/ [This
>>> and other changes attempt to align the document with the
>>> preceding list.]
>>> * s/Header Processing/Header Processing and Parsing/
>>> * s|Encryption and / or Digital Signatures|Security Services
>>> (encryption and / or digital signatures)|
>>> * s|Send/Receive Transport mapping and binding|(Send/Receive
>>> Transport mapping and binding)|
>>> * [Add Reliable Messaging box between "Message Packaging"
>>> and "Delivery Module" because message is packed once but
>>> (optionally) send multiple times).]
>>>
>>> Section 2.1
>>>
>>> * 462 s/logical MIME parts/types of MIME parts/
>>>
>>> Section 2.1.2
>>>
>>> * 508 s|non-multipart messages, which may occur|receipt of a
>>> SOAP message not packaged within a MIME multipart/related
>>> container. This packaging option is defined in the SOAP
>>> 1.1 [SOAP] specification. Senders MAY use this packaging|
>>>
>>> Section 2.2.1
>>>
>>> * 592 s/: version='1.0'// [Very confusing as it stands. We
>>> don't need to tell people what the XML Recommendation
>>> actually requires.]
>>>
>>> Section 2.3
>>>
>>> * 609 s/attribute/attributes/
>>>
>>> Section 2.3.2
>>>
>>> * 631 a [Text is necessary to avoid this URI appearing only
>>> in non-normative examples.]
>>> This schema is available at
>>>
>>>
> http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsdand
>
>>> SHOULD be referenced in a schemaLocation attribute in the
>>> SOAP Envelope element.
>>>
>>> Section 2.3.6
>>>
>>> * 699 a [Spills into a TECHNICAL issue: Our intentions
>>> should lean towards addition of new SOAP extensions rather
>>> than extending the ones we've defined when adding entirely
>>> new features.] [Don't include next paragraph if we decide
>>> to re-insert foreign attributes anywhere.]
>>> This extension mechanism is an exclusive choice. None of
>>> the elements defined in this specification support foreign
>>> namespace-qualified attributes. The wildcard elements are
>>> provided wherever extensions might be required for private
>>> extensions or future expansions to the protocol.
>>> Note: Extension elements should be included in ebXML SOAP
>>> extensions only when they expand the semantics of that
>>> particular element. This mechanism might be used, for
>>> example, to extend the eb:Error element by providing
>>> additional structured information about a problem. Wholly
>>> new features should be implemented using separate SOAP
>>> extensions.
>>>
>>> Section 2.3.9
>>>
>>> * 717-722 d [Defines SOAP, which shouldn't be necessary in
>>> our specification.]
>>> * OR [much prefer previous option but at least following
>>> change would define SOAP properly.]
>>> * 718 s/REQUIRED SOAP mustUnderstand attribute on SOAP
>>> Header extensions/SOAP mustUnderstand attribute/
>>> * 722 a [For either choice above.]
>>> For all ebXML SOAP Header extensions defined in this
>>> specification, the SOAP mustUnderstand attribute is
>>> REQUIRED and MUST have the value '1'. A compliant MSH
>>> MUST parse (but not necessarily support features
>>> associated with) all elements and attributes defined in
>>> this document.
>>>
>>> Section 2.3.10
>>>
>>> * 722 a [Defining a new section introducing the soap:actor
>>> attribute with the existing 2.3.10 and 2.3.11 becoming
>>> 2.3.10.1 and 2.3.10.2 (subsections). This section does
>>> not redefine the SOAP actor attribute (unlike lines
>>> 717-722 I'd recommend we delete).]
>>> 2.3.10 SOAP actor attribute
>>> All ebXML SOAP Header extensions defined in this
>>> specification that may be handled by an MSH node other
>>> than the ultimate recipient of a message allow inclusion
>>> of the SOAP actor attribute. If present, this attribute
>>> SHALL have one of the values defined in the following two
>>> subsections or the SOAP-defined value
>>> http://schemas.xmlsoap.org/soap/actor/next.
>>> [I've been told the actor described in existing section
>>> 2.3.11 will support an intermediate node acting on behalf
>>> of the To Party in returning an Acknowledgment (prior to
>>> the ultimate recipient seeing the message). That's a
>>> great use case, handling (for example) trusted store and
>>> forward MSH implementations in the destination's DMZ. If
>>> that's the case, we need to be clear this actor value is
>>> specifically for use in the AckRequested and
>>> Acknowledgment elements. I don't think it's useful
>>> elsewhere.
>>> Changing the above last sentence to read "If present in
>>> the AckRequested or Acknowledgment elements (see sections
>>> 7.3.1 and 7.3.2), this attribute SHALL have one of the
>>> values defined in the following two subsections." would
>>> work since the other use of soap:actor (in eb:SyncReply)
>>> is very explicit about allowed values.]
>>>
>>> * 732 s/when used in the context of the//
>>> * 729 a Such an actor MAY ignore SOAP Header extensions
>>> targeted to "urn:oasis:names:tc:ebxml-msg:actor:nextMSH"
>>> but not the "http://schemas.xmlsoap.org/soap/actor/next"
>>> actor (which all SOAP nodes, including an ebXML MSH, MUST
>>> adopt).
>>>
>>> Section 2.3.11
>>>
>>> * 732 s/when used in the context of the//
>>> * [TECHNICAL issue: Current text leaves reader asking "What
>>> is the semantic difference between toPartyMSH and the
>>> default SOAP actor? When would a sending MSH specify
>>> toPartyMSH rather than leaving the soap:actor attribute
>>> out?" This is not clear in this document and if I need to
>>> check the archives for the reasoning we're leaving
>>> something important out.]
>>>
>>> Section 3.1.2
>>>
>>> * 812-818 [split into 2 paragraphs one sentence later]
>>> * 812,813 s/the appropriate handling of the conflict is
>>> undefined by this specification/the conflict MUST be
>>> reported to the Sending MSH/ [TECHNICAL: This discussion
>>> (including following two points as well) did not reflect
>>> the decision to REQUIRE an error when a message / CPA
>>> consistency problem is detected.]
>>> * 815 s/If a receiver chooses to generate an error as a
>>> result of a detected inconsistency,/If a Receiving MSH
>>> detects an inconsistency,/
>>> * 816,817 s/If it chooses to generate an error because the
>>> CPAId/If the CPAId/ [This error shouldn't be optional
>>> either.]
>>>
>>> Section 3.1.3
>>>
>>> * 831 s/schema/scheme/ [Already mentioned (again) in Chris'
>>> message.]
>>>
>>> Section 3.1.4
>>>
>>> * 838-840 d [This discussion just confuses the issue because
>>> of its use of the word "role" without reference to the
>>> Role element. If there is a specific element in the CPA
>>> or BPSS documents that could be referenced here, fine.
>>> Otherwise don't mention it.]
>>>
>>> Section 3.1.4.1
>>>
>>> * 850-851 [TECHNICAL: Remove second sentence. It's not
>>> possible (or worthwhile) to determine whether or not
>>> something is a URI except by checking for a colon. Note
>>> as well: Unlike PartyId@type, we don't RECOMMEND that this
>>> attribute be a URI.]
>>> * [TECHNICAL issue: How are unrecognised services (those not
>>> mentioned in the BPSS referenced from the CPA for example)
>>> handled? Need to define error handling for that case.]
>>>
>>> Section 3.1.6.1
>>>
>>> * 872-873 [As Chris has mentioned, the second sentence of
>>> this paragraph should be removed. I mentioned earlier
>>> that RFC2822 mentions the local part of email addresses
>>> but doesn't distinguish between the left and right sides
>>> of a message id except with respect to possible generation
>>> rules. It never mentions "local part" when describing
>>> message id values.]
>>>
>>> Section 3.1.6.3
>>>
>>> * 885 s/messages,/messages (see section 4.2),/
>>> * 886 s/section 4.1.5/section 4.2.1.1/
>>>
>>> Section 3.1.6.4
>>>
>>> * [TECHNICAL issue: Should describe clock synchronization
>>> between MSH nodes. Is it required? Does it not matter
>>> because the durations expected are large values? I would
>>> prefer explicit mention of synchronization or clock
>>> accuracy as a deployment issue rather than ignoring the
>>> issue entirely. This is the only place in our
>>> specification where time values must be compared.]
>>>
>>> Section 3.1.9
>>>
>>> * 916,921,924,926 [replace "someType" and similar labels
>>> with example values, this is an example]
>>> * 926 d [Ignore previous comment about this line if you can
>>> perform this deletion. From the service and action
>>> values, this is a new order -- what message is referenced?]
>>>
>>> Section 3.2.1
>>>
>>> * 949 a [Was a correction to previous reference to 2.3.6
>>> material:
>>> 965 s/any namespace-qualified element content
>>> belonging to a foreign namespace// [References to
>>> 2.3.6 should be consistent in these lists.]]#wildcard (see
>>> section 2.3.6 for details)
>>>
>>> Section 3.2.1.1
>>>
>>> * 969 a [TECHNICAL issue: For schema references, should
>>> allow a "namespace" attribute. The location attribute in
>>> that case would be a preferred schemaLocation for the
>>> described schema. This would also require a small
>>> addition to the ebXML Messaging schema.]
>>> namespace -- If present, identifies the target namespace
>>> of the schema document found at the above location.
>>>
>>> Section 3.2.2
>>>
>>> * 979-981 [TECHNICAL issue: Error requirements here are
>>> overly restrictive. The problem might be a security
>>> failure accessing content elsewhere on the Internet, for
>>> example. Suggest adding something to the effect of "When
>>> no other defined error applies...".]
>>>
>>> Section 4.1
>>>
>>> * 1009 [move last sentence to end of line 1006 (the previous
>>> paragraph)]
>>>
>>> Section 4.1.2.1
>>>
>>> * 1035 s/payload./payload(s). The MSH takes and active part
>>> in providing these security measures, as part of its
>>> generation of the SOAP message and through the parameters
>>> it passes to the underlying communication protocol./
>>>
>>> Section 4.1.3
>>>
>>> * 1099 a [Current xsi:schemaLocation doesn't include the
>>> namespace identifier for our schema, resulting in illegal
>>> syntax. Probably, the second tuple in this attribute
>>> value (after addition below) should be moved to separate
>>> xsi:schemaLocation attributes on the soap:Header and
>>> soap:Body elements. Otherwise, we conflict with our own
>>> "one namespace per such attribute" recommendations.]
>>>
>>>
> http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
>
> <http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd>
>
>>> Section 4.1.4.1
>>>
>>> * 1146-1150 [Move before line 1143, making this the first
>>> paragraph and allows it to introduce use of XML Signature.]
>>>
>>> Section 4.1.4.2
>>>
>>> * 1154-1157 [TECHNICAL issue: This text disallows a
>>> receiving MSH returning a message saying "party B
>>> definitely received the message with id XYZ". Since that
>>> party likely has the message stored with party A's
>>> signatures, having to say "party B received the message
>>> with id XYZ and these contents" seems a burden only some
>>> relationships will require. It also stretches the
>>> previous definition of a signed message to mean just the
>>> inclusion of a Signature element in the soap:Header.
>>> Inclusion of ds:Reference elements should be an option
>>> even for signed acknowledgments.]
>>> * [TECHNICAL issue: Unlike the Manifest element we're
>>> defining, the dsig:Signature element is not required to
>>> reference every payload in a message. (Line 1084 says
>>> "requiring signing".) The copying described here is
>>> likely insufficient for the "and these contents" claim you
>>> want.]
>>>
>>> Section 4.1.4.3
>>>
>>> * 1160 s/,//
>>>
>>> Section 4.1.4.4
>>>
>>> * 1166 s/integrity check CRCs of/digests and comparisons of/
>>>
>>> Section 4.1.4.5
>>>
>>> * 1169 s/document(s)/document/
>>> * 1068-1078 [TECHNICAL issue: It's not clear how XML
>>> Encryption will address this problem except for payloads
>>> expressed as XML documents.]
>>>
>>> Section 4.2
>>>
>>> * 1251,1254 s/Faults/Fault messages/ [should not pluralize
>>> the name of an element even if only part is bold]
>>> * 1257 [The section 4.2.1 is missing -- we skip from 4.2
>>> Error Handling Module to 4.2.1.1 Definitions. We should
>>> at least have an intermediate heading or (probably easier)
>>> make 4.2.1.1 be 4.2.1.]
>>>
>>> Section 4.2.3
>>>
>>> * 1279 [TECHNICAL issue: I had a suggestion in this section
>>> to add an actor attribute to the ErrorList element. Even
>>> though intermediates may never hear about errors and DFN
>>> messages may take other routes back to the originator, the
>>> problem is likely reduced by the lack of duplicate
>>> elimination at intermediaries. I'd support adding this
>>> attribute in support of store-and-forward intermediaries
>>> performing retries to later destinations if someone
>>> proposes it again. I'm simply removing my
>>> suggestion because it didn't get any notice last time and
>>> might induce feature creep.]
>>> * 1281 a
>>> #wildcard (see section 2.3.6 for details)
>>> * 1282 s/reported then/reported,/
>>>
>>> Section 4.2.3.1
>>>
>>> * 1284 s/of any of the Error elements/of the grouped Error
>>> elements/
>>> * 1285 s/, otherwise/; otherwise,/
>>>
>>> Section 4.2.3.2
>>>
>>> * 1294 a
>>> #wildcard (see section 2.3.6 for details)
>>> * 1295 s/The content of the Description element MAY contain
>>> error message text.// [TECHNICAL: As Chris mentioned, the
>>> Description element MUST have content if present.]
>>>
>>> Section 4.2.3.2.2
>>>
>>> * 1301 s/errorCodes/errorCode attribute values/ [Should not
>>> pluralize our element names.]
>>> * s/then//
>>> * 1303 s/errorCodes/errorCode value(s)/
>>> * 1302-1304 [TECHNICAL issue: Our list of codes is
>>> comprehensive due to its inclusion of OtherXML and
>>> Unknown. How can "legal" additions to the list of error
>>> codes be created without violating these restrictions?]
>>>
>>> Section 4.2.3.2.4
>>>
>>> * 1311 s/problem./problem. (Other Error elements in the
>>> list may describe problems preventing further processing.)/
>>> * 1312 s/there is/there was/
>>>
>>> Section 4.2.3.2.5
>>>
>>> * 1315 a The value of this attribute MUST be a URL.
>>> [TECHNICAL issue: Need some text requiring the value of
>>> this attribute be a URL. Otherwise the later discussion
>>> doesn't make that much sense.]
>>> * 1319-1320 s/in the format cid:23912480wsr, where the text
>>> after the ":" is the value of the MIME part's
>>> content-id/using URI scheme "cid"/ [Don't redefine
>>> something well-described in another specification.]
>>> * 1318-1320 [A previous TECHNICAL issue about these lines
>>> has been partially resolved through limiting section 2.1.6
>>> to REQUIRING a SOAP Fault only in the outermost Message
>>> Package. Nonetheless, the ebXML handler is unlikely to be
>>> invoked when the payload containers or other MIME
>>> packaging is incorrect.]
>>>
>>> Section 4.2.4.1
>>>
>>> * 1352 a With the possible exception of retries to the
>>> message in error, additional messages in the conversation
>>> MUST NOT be sent after receiving any message containing
>>> such an ErrorList.
>>>
>>> Section 4.2.4.1.1
>>>
>>> * 1359 s/header SHOULD/header and no ErrorList with
>>> highestSeverity set to Error SHOULD/
>>> * 1360 [TECHNICAL issue: What does "ignore" mean in the
>>> context of HTTP with SyncReply true?]
>>>
>>> Section 4.2.4.2
>>>
>>> * 1369-1370 [TECHNICAL issue: Unparsable messages will be
>>> caught by the SOAP processor underlying most "layered" MSH
>>> implementations. It's not possible for us to specify the
>>> action of that SOAP processor.]
>>>
>>> Section 4.2.4.3
>>>
>>> * 1375 s/not being sent as a result of processing of an
>>> earlier message/being sent on its own, with no payload
>>>
> data/
>
>>> * 1376 s/if the highestSeverity is set to Error,//
>>> * [TECHNICAL: Actually, this section still makes little
>>> sense. I believe an attempt was made to describe the
>>> Service and Action when ErrorList is sent on its own.
>>> That may occur regardless of the highestSeverity and the
>>> problem is mostly addressed through the two changes
>>> above. In addition, "processing" is used in the first
>>> paragraph without context and we still need to remind
>>> users that ErrorList with highestSeverity="Error" can't be
>>> combined with payload data. Something at the end of the
>>> first paragraph like "This method MUST NOT be used if the
>>> highestSeverity is "Error". No further processing of the
>>> message in error could have occurred in that case." may
>>>
> help.]
>
>>> Section 5
>>>
>>> * [Entire section would be better placed as section 4.3.]
>>>
>>> Section 5.1
>>>
>>> * 1398 s/has the following attributes/consists of/
>>> * 1395 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> * 1406-1408 [TECHNICAL issue: This seems backwards.
>>> SyncReply s/b allowed if syncReplyMode is none (for the
>>> Acknowledgment message to come back synchronously); if
>>> syncReplyMode is not none and it's a synchronous
>>> communication protocol in use, SyncReply MUST be present.
>>> Further, intermediaries may have no idea about the CPA in
>>> use and could easily violate these overly strict
>>> restrictions (e.g. an intermediary just prior to the To
>>> Party requesting a synchronous hop-to-hop Acknowledgment).]
>>> * [TECHNICAL issue: During the discussion of this addition
>>> we agreed to add words about SOAP processors w/o full MSH
>>> understanding and their need to forward a like extension.
>>> Those words are missing. Note: Intermediate MSH nodes MAY
>>> forward using a different protocol than the incoming
>>> message and are therefore NOT REQUIRED to insert a copy of
>>> this element in all cases.]
>>> * [TECHNICAL issue: Should say the SyncReply element is not
>>> allowed in a synchronous response message.]
>>>
>>> Section 6
>>>
>>> * 1406 [TECHNICAL: Need lines for the interaction of
>>> SyncReply with other elements. Probably a new section
>>> saying "The SyncReply element MAY be present on any
>>> outbound message sent using a synchronous communication
>>> protocol." is needed.]
>>>
>>> Section 6.1.4
>>>
>>> * 1416-1417 s/except the StatusRequest element.// [Introduce
>>> in section 8.2.3]
>>> * 1420 [Why is this bullet all alone? Should be part of
>>> previous paragraph after recommended deletions.]
>>>
>>> Section 7
>>>
>>> * 1426 a
>>>
>>> For the purposes of this document, "Reliable Messaging" is
>>> defined to mean sending a message that both parties will
>>> know was received by the To Party's application intact once
>>> and only once, detect a permanent failure situation or retry
>>> until giving up.
>>>
>>> Note: Failure remains an option even when making full use of
>>> ebXML Reliable Messaging. In addition, this addresses
>>> duplication only when caused by errant MSH implementations
>>> or communication protocols: Applications may send distinct
>>> messages containing the same payload and receiving
>>> applications may need to handle these duplicates.
>>>
>>> * 1429 s/flexible/flexible with respect to intermediaries/
>>> * 1429 a
>>>
>>> The protocol is also flexible with respect to the features
>>> implemented by communications protocols, ebXML MSH software
>>> and applications. Options are available controlling MSH
>>> implementation of well-defined segments of the overall
>>> reliability requirements. Most of the following discussion
>>> assumes all ebXML reliable messaging options are enabled.
>>>
>>> Note: This assumption in the text should not prevent use of
>>> reliable communication protocols, idempotent application
>>> semantics, et cetera instead. ebXML Reliable Messaging
>>> semantics should be considered whenever such alternatives
>>> are not available or the MSH implementation is more
>>>
> efficient.
>
>>> * 1435 s/once/once (due to retries or the nature of the
>>> communications protocol in use)/
>>> * 1436 a Retries initiated by a Sending MSH and duplicates
>>> introduced by an unreliable communication protocol MUST be
>>> handled by the Receiving MSH or higher application layers
>>> at the To Party.
>>>
>>> Section 7.1
>>>
>>> * 1443 s/SHOULD/MUST/
>>> * 1455 a [TECHNICAL: All of the following information is
>>> presently missing which is internally inconsistent.]
>>>
>>> In order to associate an Acknowledgment element with the
>>> corresponding application state and to send retries, a
>>> Sending MSH SHOULD save the following in persistent storage:
>>>
>>> * MessageId of the sent message
>>> * Timestamp, RetryInterval and remaining Retries
>>> (elements and parameters to the MSH), providing
>>> support for a queue of messages awaiting retry or
>>> application failure notification
>>> * Entire SOAP message for use in later retries
>>> * links to application state for any required
>>> notifications
>>>
>>> The possible notifications from a Sending MSH to the From
>>> Party application are:
>>>
>>> * Successful delivery (Sending MSH has received an
>>> Acknowledgment element in a message not containing
>>> an ErrorList)
>>> * Acknowledged delivery with errors (Sending MSH has
>>> received a message containing both Acknowledgment
>>> and ErrorList elements; processing MAY have
>>> continued at the To Party in this case)
>>> * Timeout (TimeToLive expired or Retries have been
>>> exhausted)
>>>
>>> Section 7.3.1
>>>
>>> * 1473 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> Section 7.3.1.2
>>>
>>> * 1500-1502 [TECHNICAL issue: I previously suggested this
>>> case should result in an Error because it was inconsistent
>>> with the other Inconsistent errors, resulting in just a
>>> Warning. Now, the text requires Inconsistent/Warning
>>> where NotSupported/Error would be appropriate. It's
>>> gotten worse and should be Inconsistent/Error or the
>>> combination of that with a NotSupported/Error option.]
>>>
>>> Section 7.3.2
>>>
>>> * 1515-1517 s/The RefToMessageId element in an
>>> Acknowledgment element is used to identify the message
>>> being acknowledged by its MessageId.// [TECHNICAL: This
>>> isn't sensible and is a massive change from 1.0. Why
>>> would an Acknowledgment message be bundled into another
>>> message that isn't in response to the message in question?]
>>> * 1524 d [Again, this isn't reasonable.]
>>> * 1526 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> Section 7.3.2.3
>>>
>>> * 1535-1537 d
>>>
>>> Section 7.3.2.4
>>>
>>> * 1541 a This form SHOULD be used for hop-to-hop
>>> Acknowledgment messages from intermediate nodes,
>>> especially when the message also contains data from later
>>> nodes.
>>> * 1543 a This form SHOULD be used for all end-to-end
>>> Acknowledgment messages.
>>>
>>> Section 7.3.2.5
>>>
>>> * 1554 s/derived/derived (as described in section 4.1.4.2)/
>>> [Note: This section contains more references than it did
>>> before. It still doesn't refer to 4.1.4.2 but should.
>>> Some of the recent reference additions may be worth
>>> removing.]
>>> * 1557 s/element/list/ [TECHNICAL: Again, I disagree with
>>> this requirement because it disallows the To Party MSH
>>> acknowledging receipt of a message and signing the
>>> acknowledgment without also describing the contents. The
>>> message already has the RefToMessageId element and any
>>> disagreements about the contents of that message would be
>>> covered through the signing the original party did. I
>>> would prefer to strike this sentence and much of the
>>> surrounding discussion. It's a bit worse now that the
>>> text attempts to define "signed Acknowledgment Message"
>>> two ways simultaneously (signed Ack either means "it
>>> contains both Ack and Signature" or "contains both Ack
>>> with Reference list and Signature").]
>>>
>>> Section 7.3.2.6
>>>
>>> * 1570 d
>>>
>>> Section 7.3.2.7
>>>
>>> * 1577 a [TECHNICAL: I could go either way here (prefer
>>> either Action) but we haven't made a choice yet.]
>>>
>>> When an Acknowledgment message and Error message are
>>> combined without additional payloads (regardless of the
>>> highestSeverity attribute of the included ErrorList
>>> element), the service and action described in 4.2.4.3 MUST
>>> be used.
>>>
>>> Section 7.3.2.8
>>>
>>> * 1580 [Note TECHNICAL issue already raised about this last
>>> sentence. The inability to send a reliable Error (even
>>> when a Warning and combined with payload data) in the
>>> current text should be resolved by killing this sentence.
>>> This issue was resolved during the last face-to-face and
>>> Chris most recently mentioned it.]
>>>
>>> Section 7.4.1
>>>
>>> * 1568-1584 [This section repeats some of 3.1.7 and adds new
>>> information. The new information belongs better in
>>> 3.1.7. All that should be left here is information about
>>> the relation between the CPA flag and the
>>> DuplicateElimination element. At the moment, the
>>> semantics of the DuplicateElimination element are
>>> described again -- without reference to section 3.1.7.]
>>> * 1503 s/duplicate messages to be ignored/the To Party
>>> application never to see duplicate messages/
>>>
>>> Section 7.4.2
>>>
>>> * 1601-1603 d [This section attempts to re-define an element
>>> already described in section 7.3.1 and adds no new
>>> information. Just nuke the section. At most, mention
>>> that some configuration information must be available to
>>> the From Party MSH to determine whether or not an
>>> acknowledgment may be requested and whether or not
>>> it could be signed.]
>>>
>>> Section 7.4.4
>>>
>>> * 1613 s/between retries/between later retries/
>>>
>>> Section 7.4.6
>>>
>>> * 1621-1622 s/The timestamp for a reliably sent message
>>> (found in the message header), plus its PersistDuration
>>> (found in the CPA), must be greater than its TimeToLive
>>> (found in the message header)./For a reliably delivered
>>> message, TimeToLive MUST conform to:
>>>
>>> TimeToLive < TimeStamp + PersistDuration
>>>
>>> where TimeStamp comes from MessageData and PersistDuration
>>> is found in the CPA./ [The equation should describe
>>> something under MSH control when sending a message. Similar
>>> syntax to 7.4.5 makes it easier to read.]
>>>
>>> Section 7.4.7
>>>
>>> * 1630-1631 s/If the value of syncReplyMode is none and a
>>> SyncReply element is present,/If the value of
>>> syncReplyMode is not none, the communications protocol is
>>> synchronous and a SyncReply element is not present in a
>>> message,/ [This sentence should be joined with the
>>> previous paragraph.]
>>> * [TECHNICAL: The current wording disallows sending MSH
>>> signals synchronously. Above change allows SyncReply even
>>> when syncReplyMode is none (synchronous signals) but
>>> doesn't address problems raised earlier around
>>> heterogeneous routes to the destination and intermediaries
>>> not being party to the CPA.]
>>>
>>> Section 7.5.1
>>>
>>> * 1655 a
>>>
>>> 6. Notify application of delivery success or failure (if
>>> requested).
>>>
>>> Section 7.5.2
>>>
>>> * 1665-1666 s/generate an Acknowledgment Message (see
>>> section 7.5.3). Follow/follow/
>>> * 1673-1676 [Move everything from this paragraph except the
>>> first sentence into 7.5.3, assuming that section continues
>>> to have some useful content. This is general information
>>> about all Acknowledgment messages generated. Replace
>>> these sentences with ", as described in section 7.5.3".]
>>>
>>> Section 7.5.3
>>>
>>> * 1689-1691 d [Because the RefToMessageId element adds no
>>> value to an Acknowledgment element, this paragraph means
>>> little. If anything is necessary, section 7.3.2 should
>>> (somewhere) remind people, as is done for Error messages,
>>> that the MessageData/RefToMessageId value must be set
>>> appropriately.]
>>> * 1692-1703 m [Most of this section attempts to redefine
>>> what's already in 7.3.2. and 7.3.2.7 without adding much
>>> value and confusing some issues (e.g. some bullets are
>>> generally true while others apply only to stand-alone Ack
>>> messages). Copy what's not already in those sections
>>> appropriately and make sure that section is now
>>> consistent. This section (7.5.3) should be left with only
>>> a reference to 7.3.2 and the "persisted storage"
>>> description from 7.5.2. Maybe, the last 3 bullets could
>>> stay here.]
>>>
>>> Section 7.5.5
>>>
>>> * 1725-1737 m [This section should come after what's now
>>> 7.5.6, reverse two sections]
>>> * 1726 s/duplicate/duplicate and DuplicateElimination is
>>> present/
>>> * 1728 s/it/first that/
>>> * 1729 s/that matches/matching/
>>> * 1730 s/then/,/
>>> * 1731 s/MSH that sent the received message/Sending MSH for
>>> the duplicate message/
>>> * 1732 s/and if/and/
>>> * 1733 s/then/,/
>>> * s/that//
>>> * 1734 s/same//
>>> * 1735 s/that was//
>>> * 1737 s/Message/Message (as described in section 7.5.3)/
>>>
>>> Section 7.5.6
>>>
>>> * 1744 s/the same RefToMessageId as/a RefToMessageId value
>>> matching the MessageId of/
>>> * 1752-1753 s/sent to the sender Party A)// [Note unbalanced
>>> parentheses are also fixed by removing this unnecessary
>>> text.]
>>> * 1753 a [TECHNICAL: If the recipient ensures a duplicate is
>>> identical, we should say what happens if the check fails.]
>>>
>>> 2a) The recipient of a duplicate message MAY confirm the
>>> duplicate is indeed identical to the original, allowing for
>>> changes introduced by intermediate nodes. If this is found
>>> not to be the case, the receiving MSH SHOULD issue an error
>>> with errorCode of Inconsistent and a severity of Error.
>>>
>>> Section 8
>>>
>>> * 1777 [Reword to use "A Message Status Response message" as
>>> the subject, matching the previous bullet's style.]
>>>
>>> Section 8.2
>>>
>>> * 1827 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> Section 8.3
>>>
>>> * 1849 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> Section 8.3.3
>>>
>>> * 1864 [TECHNICAL issue: We had some reason for handling
>>> this requester error in the response element rather than
>>> using an ErrorList. Did this have something to do with
>>> the possibility of sending multiple StatusRequest elements
>>> in the same message? Either way, we need text describing
>>> why this isn't handled using an Error message.]
>>> * 1867-1872 [TECHNICAL issue: This expands the list of
>>> possible values from those in MSH 1.0 without
>>> explanation. Hadn't we agreed the additional status
>>> values (Processed and Forwarded) are likely to be
>>> information the MSH doesn't know and shouldn't tell an
>>> outside party?]
>>>
>>> Section 9.1
>>>
>>> * 1910 s|Boundary"|Boundary"; type="text/xml";
>>> start="gobblelygook"|
>>> * 1913 a
>>>
>>> Content-Id: <gobbledygook>
>>>
>>> * 1921 [Correct the xsi:schemaLocation for the ebXML MSH
>>> namespace to use proper syntax: Repeat the string
>>> (identically).]
>>>
>>> Section 9.2
>>>
>>> * 1967 [Correct the xsi:schemaLocation for the ebXML MSH
>>> namespace to use proper syntax: Repeat the string
>>> (identically).]
>>>
>>> Section 10
>>>
>>> * 1993-1994 [Remove second sentence. Information is better
>>> expressed in the next paragraph.]
>>>
>>> Section 10.1
>>>
>>> * 2006 a
>>>
>>> #wildcard (see section 2.3.6 for details)
>>>
>>> Section 10.1.1
>>>
>>> * 2010 s/SequenceNumber/REQUIRED SequenceNumber/ [TECHNICAL
>>> issue: I made a mistake in this suggestion. The
>>> SequenceNumber element is required inside an optional
>>> element and therefore is not REQUIRED of all
>>> implementations. Remove word again (sorry).]
>>>
>>> Appendix B.2.2
>>>
>>> * 2485 a [Current xsi:schemaLocation doesn't include the
>>> namespace identifier for our schema, resulting in illegal
>>> syntax. Probably, the second tuple in this attribute
>>> value (after addition below) should be moved to separate
>>> xsi:schemaLocation attributes on the soap:Header and
>>> soap:Body elements. Otherwise, we conflict with our own
>>> "one namespace per such attribute" recommendations.]
>>>
>>>
> http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd
>
>>> Appendix B.2.4
>>>
>>> * [I won't repeat all of the technical discussions of
>>> problems in this section. My memory dims this late in the
>>> game but I seem to recall issues with requiring SOAP Fault
>>> separately (since the SOAP processor isn't something we're
>>> defining) and problems using the Fault element
>>> asynchronously in any case (since it provides no context
>>> for the error described).]
>>>
>>> Appendix B.2.5
>>>
>>> * [I'm not sure this section is as clear as it could be. It
>>> seems David had a different interpretation. Might need
>>> some rewording.]
>>> * 2555 s/Post/Post if the message is processed by an ebXML
>>> MSH handler/
>>>
>>> Appendix B.3.2
>>>
>>> * 2622-1624 d [This header is defined only for HTTP
>>> communication.]
>>> * 2638 d [as above]
>>> * 2656 [Correct the xsi:schemaLocation for the ebXML MSH
>>> namespace to use proper syntax: Repeat the string
>>> (identically).]
>>> * 2676 [Correct the xsi:schemaLocation for the ebXML MSH
>>> namespace to use proper syntax: Repeat the string
>>> (identically).]
>>>
>>> References
>>>
>>> * [Entire section and all references in the text should
>>> consistently use [RFC1234] for references to these
>>> documents. XMLMEDIA, IPSEC,PGP/MIME,S/MIME* and TLS all
>>> violate this consistency.]
>>> * [Sort the RFC entries by their number.]
>>> * [Entire section should use a consistent format for the
>>> references, order and contain similar information. For
>>> example, references to RFC documents should all include
>>> the title of the RFC and (probably, I don't remember the
>>> IETF standards) IETF RFC1234.]
>>> * [For documents available online (such as all ebXML
>>> documents but likely excluding the RFC's, letting people
>>> head to their favourite RFC source), please include URL
>>> values.]
>>> * [All references to W3C documents should consistently
>>> include the date in their URL values.]
>>> * 2787-2788 [This should refer to the section of the Unicode
>>> Standard that defines UTF-8. This is an incomplete
>>> definition for the term UTF-8.]
>>>
>>>
>>>
>>>
>>
>