RE: [ebxml-msg] ebXML Message Service Specification

[David Fischer <david@drummondgroup.com>]

Got it, thanks,

David.

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Friday, October 26, 2001 12:10 PM
To: David Fischer; ebXML Msg
Subject: Re: [ebxml-msg] ebXML Message Service Specification


David:

I think the following Transforms example (in section 4.1.3) in the 1.06
draft:

     <Transforms>
      <Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20010315">
       <XPath> not(ancestor-or-self::*[@soap:actor=
          "http://www.oasis-open.org/committees/ebxml-msg/nextMSH"] |

ancestor-or-self::*[@soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
])
       </XPath>
      </Transform>
     </Transforms>

should be changed to

<Transforms>
 <Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
 <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20010315"/>
 <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
  <XPath> not(ancestor-or-self::*[@soap:actor=
   "http://www.oasis-open.org/committees/ebxml-msg/nextMSH"] |

ancestor-or-self::*[@soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
])
  </XPath>
 </Transform>
</Transforms>

Regards,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; ebXML Msg
<ebxml-msg@lists.oasis-open.org>
Date: Friday, October 26, 2001 9:21 AM
Subject: RE: [ebxml-msg] ebXML Message Service Specification


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>