Re: [ebxml-msg] ebXML Message Service Specification

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

Arvola,

What possible benefit is to be gained from changing the namespace
prefix from SOAP to SOAP-ENV other than to add an additional 4 characters
to each namespace prefixed SOAP element in our examples?

The value of the namespace prefix is not important except that it
match exactly the prefix used in the xmlns declaration of the document
in which the namespace qualified elements and attributes appear.

Cheers,

Chris

Arvola Chan wrote:

> 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.
> 
> 
> ebMS_v1.06.doc
> 
> Content-Type:
> 
> application/msword
> Content-Encoding:
> 
> BASE64
> 
>