OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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



Arvola,

(This won't help the line-number mismatch, however.)

If you have full function Acrobat (e.g. Acrobat Distiller), Word has two
ways to generate PDFs.

1. You can simply print to Distiller.

2. There should be an Acrobat icon somewhere on your tool bar.  Using it
gets you the PDF with the navigation pane with all the subheads.

If you only have Acrobat Reader, you are stuck with the Word file.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Arvola Chan <arvola@tibco.com> on 01/17/2002 03:01:28 PM

To:    Christopher Ferris <chris.ferris@sun.com>, Ralph Berwanger
       <rberwanger@bTrade.com>
cc:    Doug Bunting <dougb62@yahoo.com>, ebxml-msg@lists.oasis-open.org
Subject:    Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09)



David distributed a Word document. How do I generate a PDF equivalent for
it?

Thanks,
-Arvola

-----Original Message-----
From: Christopher Ferris <chris.ferris@sun.com>
To: Ralph Berwanger <rberwanger@bTrade.com>
Cc: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Thursday, January 17, 2002 11:44 AM
Subject: Re: [ebxml-msg] Fw: Old comments (outstanding since 1.09)


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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC