Re: 24 hour turnaround remarks on RE: initial draft of CPP-CPA Specification

[Martin W Sachs <mwsachs@us.ibm.com>]

Dale,

Thanks for your quick response.  I agree that we need to discuss all of
these issues.  I want to give a few quick replies.

Transport Timeouts:  I have assumed that a transport-level implementation
does timeout and retry underneath the messaging service.  If this is not
the case, then perhaps we should remove the transport-level timeouts.

Secton 8.7.5.1, HTTP:  We are waiting for TRP to complete its definition of
synchronous messaging, at which point we will add what is necessary to
support it in the CPP and CPA.  We also have work to do on defining send
properties, which is where I think an indication of synchronous response
would go (at least for HTTP).

Section 8.8.2.3:  This section is defining timeout and retry for reliable
messaging, so there is one less level than you indicate.
Transport-level timeouts may or may not be needed (see above).  Timings at
the BP level relate to the time for a business to respond to a BP-level
request.  This is an entirely different issue from RM timeouts since it
relates to service response times rather than communication
errors/failures. Service response times are on an entirely different time
scale (hours, days, weeks, rather than seconds) and have different causes
and recoveries than communication timeouts.  So in my opinion, we do have
to deal with both communications (probably just RM) and business-level
timings, and both have to be specified.

Regarding "If a BP specifies some actual values for retry-related
parameters..."  The plan is for the BP collaboration protocol definition to
express characteristics such as timeouts as variable parameters and for the
CPA to record what is agreed upon and to cause the values of the BP
parameters to be set.  Presumably we would provide a set of those
parameters perhaps as attributes of <CollaborationProtocol> or by means of
a subelement similar to <Characteristics> under <DeliveryChannel>.  This is
another area where we are currently waiting for another team (BP) to
solidify its work.

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
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/16/2001 05:31:07 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-tp@lists.ebxml.org,
      ebxml-ta-security@lists.ebxml.org
cc:
Subject:  24 hour turnaround remarks on RE: initial draft of CPP-CPA Specif
      ication





Hi Marty,

I am following through on the 24 hour turnaround for remarks,
which thankfully means that there are not a lot of them
yet.

I think we have a good start here but we have a substantial
number of issues ahead of us.

I think the general statements of direction and architecture
are good. Could we ask QR to focus on those for their review
if they are to do one?

Many details remain to be ironed out or at least explained
to me so I understand how the CPPs aid in arriving at a CPA
that promotes interoperable end to end (app to app) collaboration.
(I don't think we will be able to guarantee much beyond transport,
document exchange, and possibly security level interoperability
of course.)

I attach my comments below.

Dale