Re: [ebxml-msg] ebXML Message Service Specification

[Christopher Ferris <chris.ferris@sun.com>]

It isn't necessary to do so. The Transform(s) are
treated as a unix pipe (output of one is the input to the
next in lexical sequence).

Cheers,

Chris

David Fischer wrote:

> OK, I am confused.  How do we put the REC-xpath... algorithm and the
> REC-xml-c14... canonicalization algorithm on the same Transform?
> 
> Regards,
> 
> David.
> 
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Thursday, October 25, 2001 7:45 PM
> To: ebXML Msg
> Subject: Re: [ebxml-msg] ebXML Message Service Specification
> 
> 
> David:
> 
> Please see the attached Word document for the contexts of the following
> comments.
> 
> Regards,
> -Arvola
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Figure 1 needs to be put into the same format as other figures in this
> specification. The current figure seems to have very poor resolution. Also,
> the box labelled "Authentication,authorization and repudiation services"
> should be renamed "Authentication, Authorization and Non Repudiation
> Services".
> 
> Incorrect figure number.
> 
> We use the prefix SOAP-ENV to represent the SOAP namespace in the examples,
> but use the soap:prefix in the schema. Should we make these uniform? Should
> I change the schema to use SOAP-ENV instead of soap?
> 
> The TimeToLive element may be specified for a Best-Effort message. The
> corresponding semantics need to be explained in this section.
> 
> Strike this out in accordance with Marty's suggestion regarding the use of
> RFC2119 keywords.
> 
> The ';' is extraneous. Should mechanism be plural?
> 
> Since you are adding the canonicalization transform, doesn't that raise the
> total number of transforms to 3?
> 
> This paragraph seems to be left over from an earlier version of the spec. It
> is no longer quite relevant because (1) TraceHeaderList is now a sub-element
> of Via and (2) the Acknowledgment element targeted for the next MSH will
> also be excluded by the transform.
> 
> If this transform is always used, then one intermediary can never return a
> meaningfully signed (intermediate) Acknowledgment to another, because such
> an intermediate Acknowledgment will have an actor attribute value equal to
> the nextMSH and therefore be excluded from the signature.
> 
> The third ds:Transform.
> 
> The result of this transform is to canonicalize...
> 
> Why are you combining the XPath transform with the canonicalization
> transform? In the 1.0 spec, an algorithm of
> "http://www.w3.org/TR/1999/REC-xpath-19991116" was used for the XPath
> transform.
> 
> The spelling of soap needs to be in uppercase to be consistent with the rest
> of this example.
> 
> This section should explain how a delivery channel is selected for a given
> error condition.
> 
> This restriction seems unnecessarily severe. A DR may be piggybacked on a
> business message that asks for DR. The restriction should be applicable only
> when a DR message is sent on its own.
> 
> The two sentences in this paragraph contradict each other. Some rephrasing
> is necessary.
> 
> This part of the sentence is kind of circular. Suggest rephrasing as:
> "Reliable Messaging defines an interoperable protocol such that two Message
> Service Handlers (MSH) can reliably exchange messages using acknowledgment,
> retry, and duplicate detection and elimination mechanisms, resulting in the
> To Party receiving the message Once-And-Only-Once.
> 
> This overview should mention duplicate elimination as a component of
> reliable messaging.
> 
> This restriction should only be applicable when an Acknowledgment message is
> sent on its own, not being piggybacked on a business response message.
> 
> I don't think it is appropriate to reference a subsection within another
> optional module.
> 
> Will there be retries if the AckRequested element is not present?
> 
> I am not sure if the Retries parameter should govern retries due to
> communication errors. In the RosettaNet Implementation Framework, retries of
> PIP actions due to the non receipt of acknowledgment is distinct from
> retries due to communication failure.
> 
> This sentence is problematical. The behavior described below should only be
> exhibited by a Receiving MSH when it is the toPartyMSH!
> 
> I think the pointer should be to section 7.5.3.
> 
> This discussion really belongs in section 7.5.3.
> 
> This should always be true because the antecedant in item 2 above is: "If
> the message is not a duplicate".
> 
> This discussion belongs in section 7.5.3.
> 
> The format of the Heading 2 paragraph style needs to be adjusted (globally)
> to provide more spacing between the section number and the section title.
> The attribute value "hanging" needs to be increased. It was not meant to
> deal with a document with so many sections.
> 
> duplicateElimination is an attribute of QualityOfServiceInfo.
> 
> This statement is not true for a Best-Effort multi-hop message. There will
> not be an AckRequested element in such a message.
> 
> Is being returned?
> 
> We need to make sure that the CPP/A can model these combinations.
> 
> The format of the Heading 1 app paragraph style needs to be adjusted
> (globally) to provide more spacing between the appendix label and the
> appendix title.
> 
> I suggest that this sentence be struck out. The schema must be in sync with
> the specification because implementers will directly use the schema in their
> implementations.
> 
> -----Original Message-----
> From: David Fischer <david@drummondgroup.com>
> To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> Date: Thursday, October 25, 2001 7:18 AM
> Subject: [ebxml-msg] ebXML Message Service Specification
> 
> 
> I have been trying to capture the editorial comments as they come in.  We
> are
> starting to get duplicates which indicates it is time to put out a new
> version.
> Tracking is on and Arvola's schema has been inserted.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>