[ebxml-msg] New issues in 2.0 document

[Doug Bunting <dougb62@yahoo.com>]

Here's the remainder of the issues I noticed in my most recent read through this specification.  I've made every attempt to avoid
reiterating things already mentioned to the group, including my previous "Old comments" [1] email and the list Chris included in his
"Final voting reminder" [2] message.  My apologies if there remains some overlap.

 

[1] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00136.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00130.html

 

I've attempted to include more placement information than line numbers in deference to David's (off-line) comments about keeping
the PDF file open while making requested changes.  As with my previous list, everything is editorial unless called out to the
contrary.

 

I would appreciate everyone reading through this and the two emails referenced above, forming and expressing opinions to move us
towards closure on the technical issues described.  It is not appropriate for my proposed solutions to the issues to move into the
next version of the document without discussion.  In some cases, I've simply described one or two options rather than exact text for
a solution.  I'm certainly willing to turn those into text but would like to know my proposed direction works for the group.

 

Do we presently have an issue list or database that may be used to track our progress towards disposing of the issues presently
before the group?

 

Sorry this arrives so late in the week.

 

thanx,
    doug

 

   #Sec 1, 4th bullet in second set, 213 s/Next MSH/nextMSH/ [The document is not consistent with regards to "Next MSH",
     "next MSH" and "nextMSH" when referring to the software acting in the capacity described by our ".../nextMSH" soap:actor
     value.  I would suggest we consistently use "nextMSH" throughout.]
   #Sec 1.1.1, 1rst para, 232 a
     Examples are separated out as paragraphs with this background colour.  [Sorry, can't use such a colour in this email.]
   #Sec 3.1.1, end of 1rst para, 759 s/physical location/routable destination/ [I'm not positive "routable destination" is any
     improvement but an email address or URL doesn't strike me as a physical location.  We need something a bit more general
     that may be contrasted with an identifier.  "Location" may be enough.  Could also be helpful to remove "logical" from "logical
     identifier".  How about "contain identifiers, such as a DUNS number, or locations, such as an email address"?]
   #Sec 3.1.7, last para, 903 s/if there is a CPA with/if the CPA governing this message has/ [If we end up undoing our decision
     to require a prior agreement that might not be a physical CPA document, the existing phrasing still doesn't work.  (Where is
     this CPA?)  In that case, I'd recommend using "if a CPA governs this message has" as the replacement text.]
   #Sec 3.1.8, end of para, 909 s/Each occurrence/In a list of Description elements, each occurrence/
   #Sec 3.3.2, 1rst para, 975 s/then/,/
   #2nd para, 979 s/URI not a content id (URI scheme "cid"), and/URI that is not a content identifier or content location,/ [The
     "or content location" addition assumes correction of Chris' previous technical issue about this section.  Rest is purely
     editorial, making this paragraph structure mirror the first one's and removing a duplicate expansion for "content id".]
   #Sec 4.1.3, 6th para, 1058-1061 s/MAY/can/g [As mentioned in Chris' comments about "OPTIONAL" and line 784, we
     have a few other places where ordinality is meant and capitalised words are used.  While it's not possible to clean things up
     enough to remove the 3rd bullet in the conformance clause (section 1.3), we should strive to avoid the most obvious
     problems.  This one is something an sender MAY include but receivers MAY ignore that inclusion.  Something in lower case
     throughout this paragraph seems much more appropriate when describing the Type attribute.]
   #9th para, 1075-1078 m/Any intermediate node ...invalidate the signature/ 1244 [In other words, move the last 2 sentences
     from this paragraph to the end of section 4.1.5.  I'm getting confused as to how to count paragraphs.  Sorry if I've lost my
     place.  This comment is with respect to the explanation for the 2nd transform.]
   #12th para, 1085 s/either// [Sentence describes 3 options, "either" is inappropriate.  This paragraph sits between 2 notes.]
   #general comment on section: TECHNICAL: How is the security of URI resolution when it's not a content id described and
     enforced?  More specifically, do we have any recommendations with respect to validating a signature against the "snapshot"
     of an Internet resource captured in a payload container with a content-location (should the location be resolved or its value
     compared to those in the message)?  Are specific credentials used when retrieving referenced information from the Internet?
   #another general comment: TECHNICAL: This material implies an enveloping signature with a specific XPath narrowing of
     the signed material.  It makes it clear the 3rd transform, canonicalisation of that signed material, is only recommended. 
     However, the XPath should also be a recommendation.  For example, it's likely more secure to use element id's to exclude
     all but a few children of the soap:Header and soap:Body.  The XPath won't be pretty, of course (because it's not enough just
     to sign the children of interest since that would ignore the 3 SOAP elements).  This MAY or SHOULD should be called out
     in the document.
   #Sec 4.1.4.5, 1rst para, 1172 a and this remains true. [Sentence describes a historical decision but not how it applies to the
     current, 2.0 specification "the case" would be fine instead of "true".]
   #2nd para, 1174 s/by using/using/
   #Sec 4.1.4.7, 1185 s/based on/called/ [The TC engaged in this work is producing something called SAML, not basing new
     work on that one.]
   #1186 s/anticipated specification/anticipated specification (more narrowly, storage of SAML assertions a trusted authority has
     signed)/ [Provide some guidance about how SAML will fit into persistent authentication for ebXML Messaging.]
   #Sec 4.1.4.8, entire section: TECHNICAL Neither TLS nor IPSEC provide authorization mechanisms, just authentication. 
     For this section, SAML would be of more help.  Oh, back reference as well: SAML may be used to check (transient)
     authentication tokens (section 4.1.4.3).
   #Sec 4.1.5, entire section (or just title): TECHNICAL: This material should probably be non-normative and that should be
     obvious in the document.
   #6th para, 1226-1229 d [TECHNICAL: Unless I completely misunderstand xlink:role (quite possible), our Reference
     element and that in the XML Signature schema contain nothing semantically equivalent to the MIME content-type header. 
     At most, a reader of the Manifest may distinguish XML content from everything else.  I don't believe we have an issue with
     duplication of information, just with unprotected information sent in the clear and used by receivers to dispatch material to
     handlers.]
   #Sec 4.2.2, 1rst para, 1264 s/MSH needs/MSH may need/ [We hope it is not generally be true errors must be reported!]
   #2nd para, 1270 s/data communications protocols/a data communications protocol/ [Match later comments about "that
     communications protocol".]
   #Sec 4.2.3.2, last line, 1295 d [TECHNICAL: As Chris has mentioned, this line disagrees with the schema and most other
     descriptions of the Description element.]
   #Sec 4.2.3.2.5, 3rd para, 1318 s/then//
   #Sec 4.2.3.2.6, 1323 s/defined by/described by/ [The xml:lang attribute allows inclusion of a well-defined set of locale
     identifiers in XML documents.  It doesn't define those identifiers or the underlying locales.]
   #1325 Remove last sentence.  [TECHNICAL: As Chris has mentioned, this section disagrees against the schema and most
     other descriptions of the Description element.]
   #Sec 4.2.3.4.1, last line of table s/Error/Description/ [Just a reference not caught when moving this text down from Error.]
   #s/should/SHOULD/ [Make an actual recommendation the Description element is used for such a general error.]
   #Sec 4.2.3.4.2, last line of table s/Error/Description/
   #s/should/SHOULD
   #Sec 4.2.4.1, 1rst bullet, 1350 s/to which the message reporting the error should be sent// [Don't bother re-defining what's
     expressed in the very next section.]
   #Sec 4.2.4.2, 1rst para, 1364 s/that indicates/indicating/
   #Sec 5.1, 3rd para, 1399-1401 [TECHNICAL: Requiring this error is overly stringent because it prevents the last
     intermediary requesting a synchronous hop-to-hop acknowledgment message when semantics are end-to-end
     asynchronous.  In general, description of syncReplyMode interactions with SyncReply imply (perhaps allow only) a single
     hop.]
   #Sec 6.1.5, 1422 s/synchronous/a synchronous/
   #Sec 7, 2nd para, 1431-1432 s/Failure to receive an Acknowledgment Message by a Sending MSH/A Sending MSH's
     failure to receive an Acknowledgment Message within the RetryInterval/ [Not entirely sure my additional mention of the
     RetryInterval helps but it might be worthwhile.]
   #Sec 7.1, 1rst bullet, 1452 s/process/agent/
   #Sec 7.3.1, 1rst para, 1466 s/of the actor URI//
   #Sec 7.3.2, 1rst para, 1515 s/to another Message Service Handler that it has received a message/receipt of a message to
     anther MSH/
   #Sec 7.3.2.4 d [TECHNICAL: I forgot to reference my previous comments that Acknowledgment/From should be removed
     when making editorial suggestions for this section.  As Chris mentioned in his list, it's better to delete this element and section
     entirely.]
   #Sec 7.3.2.5, 1rst para, 1545 s/by including/when it includes/
   #2nd para, 1553 s/whether//
   #1555 s/by the recipient of the message being acknowledged//
   #3rd para, 1560 s/be identical to the/contain the same payload digests to corresponding/ [TECHNICAL: As mentioned
     elsewhere, it's not necessarily true an ds:Signature in an outbound message and eb:Acknowledgment in the response will
     even refer to the same subset of payload containers.  Even when they do, it's unlikely they'll have byte-for-byte identical
     content.  I'm suggesting we remove that implication.]
   #Sec 7.3.2.6, example, 1568 s/>/ SOAP:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH">/ [Likely to be split onto
     next line.]
   #1571 d [Another part of changes necessary to remove Acknowledgment/From if approved.]
   #Sec 7.4.5, 2nd para, 1616 s/For a reliably delivered message,/When present in the MessageHeader,/ [TECHNICAL:
     Current wording requires TimeToLive for all reliably delivered messages.  What's really necessary in that case is both parties
     agreeing to a persist duration and / or retry & retry interval parameter set.  TimeToLive adds an additional requirement over
     and above what's necessary for reliable messaging.]
   #Sec 7.5, last para, s/with a RefToMessageId/and a RefToMessageId in the MessageHeader/ [TECHNICAL: No need or
     use for Acknowledgment/RefToMessageId as mentioned in earlier comments.  This is one change I missed before necessary
     to remove it from specification.]
   #Section 7.5.1, last item, 1653 s/receipt of/
   #1654 s/and, if/6. If/ [Start a new item at this point.  This moves my previous suggested item addition down to number 7.]
   #s/, or if/or/
   #1655 s/then//
   #Sec 7.5.2, after 1rst list, 1660 a [TECHNICAL: Continuing to address problems with assumptions Error and
     Acknowledgment messages are sent without information of the "other" type or payload data.  For example, I commented on
     line 1713 in [1].]
     3. If message also contains payload information or an ErrorList element, continue with actions listed below.
   #after 2a) in 2nd list, 1672 a [TECHNICAL: As above.]
     b.  If message contains an ErrorList element, log the error and / or notify the application (as appropriate).
   #after 2b, now 2c, 1678 a
     d. Deliver the message to the application interface.
   #1 in 3rd list, 1680 s/element,/element/
   #s/then do nothing/do not continue with actions in this list.  In particular, do not deliver the duplicate message to the
     application interface./
   #a
     2. If message contains an ErrorList element, log the error and / or notify the application (as appropriate).
   #Sec 7.5.5, 1rst para, 1726 s/duplicate/duplicate and contains an AckRequested element targeted at this Receiving MSH/
     [TECHNICAL: Text implies its necessary to acknowledge all duplicates, regardless of whether they asked for it.  Note: My
     previous suggestion to add an "and" for DuplicateElimination should put that addition before this one (s/and/,/).]
   #1727 s/if the message is// [TECHNICAL: Storage of the Acknowledgment Message in the persistent store was required
     earlier in section 7.5.3.]
   #Sec 7.5.6, 1rst bullet, 1740 s/SOAP Header, Body and/SOAP Envelope, Header and Body elements, excluding content
     added or changed by intermediaries, and/ [TECHNICAL: Current text ignores the schemaLocation and other information
     present in the soap:Envelope.  Current text also pays attention to elements targeted at or added by intermediaries.]
   #Sec 7.5.7, 1rst para, 1759 s/DeliveryFailure/DeliveryFailure or other code associated with problems receiving or parsing the
     incoming message/ [TECHNICAL: Current text assumes the only problems an MSH can notice occur when attempting to
     forward the message.]
   #General comment on section, [TECHNICAL: A general delivery failure notification (one using code DeliveryFailure and not
     something more specific) should be optional if it will be sent end-to-end.  An originating node should know it didn't get an
     end-to-end Acknowledgment and this adds little value.  When hop-to-hop acknowledgments or no acknowledgments are
     requested, DFN becomes useful.  Start having a middle ground between "best effort" and "retry until I get an
     acknowledgment".  Something like "once or I get error from some random MSH telling me about a problem"?]
   #Sec 7.6, item 7 in table, 1771 s/and at the End//
   #Sec 10, 2nd para, 1998 s/section 10.1.1/section 10.1.1.1/
   #a [TECHNICAL: Did we decide to add a Note recommending same utilization of Message Order semantics throughout a
     conversation?  Even if not, wording further down in 10.1, line 2021 ("each application-prepared message") implies MSH
     signals sent separately from application payloads are outside the message ordering of a conversation.  That option should
     also be described here.]
   #Sec 10.1.1, 5th para to end, 2026 a
     10.1.1.1 status attribute
   #Sec 10.2, general comment on section, [TECHNICAL: This requirement seems bizarre in light of possible heterogeneous
     path through intermediaries.  A much better restriction would be requiring a MANIFEST element if we decide Message
     Order feature does apply only to "application-prepared" messages.]
   #Sec 11.1, 2nd para, 2066 s/The use of the duplicate elimination is not required for Intermediate nodes./Intermediate nodes
     MUST NOT perform duplicate elimination./
   #3rd para, 2069-1070 d [TECHNICAL: This is a CPA issue and lack shouldn't impact our document unless we start making
     an attempt to describe every parameter configuring an MSH implementation.  (From what I see, we make no such
     attempt.)]
   #Sec 11.1.3, 4th and 5th para, 2107-2114 d [TECHNICAL: Generation and receipt of Acknowledgment element has
     already been described.  At most, this section should describe differences in how hop-to-hop Acknowledgment messages
     are handled.]
   #Sec 11.1.4, 1rst para, 2120 s/NextMSH/nextMSH/
   #2nd para, 2122-2125 [Remove background colour because it implies this is an example.]
   #[TECHNICAL: Need an additional Transform to ignore elements carried end-to-end or sent to non-MSH intermediaries. 
     That is, this Transforms element should restrict signature to a particular Transform element alone.]