[ebxml-cppa-btp] re: Fletcher 11/28/2002: Comments on Draft BTP CPPAExtension

[Monica Martin <mmartin@certivo.net>]

Tony,
*	On Message_Timeout_Range, how does this map to ebMS, and BPSS
elements (and CPPA RetryInterval)?
<AMF> This is the message time out that the BTP state machine will apply
each time it sends a message out.  If it expires then it will take
whatever action is permitted / dictated by the BTP state tables, which
could be to re-send the message, send a different message, make an up
call on its interface with whatever is driving it and so on.  So no
*required* relationship to any internal timers that messaging might use
for its own reasons or with any that BPSS might set.  Having said that
there may well be sensible (ands not so sensible!) relationships between
timers used at different levels - so you may have a point.  I guess we
could add guidance that in general it might be best to set Application
(e.g. BPSS) timeouts >= BTP timeouts >= messaging timeouts  ?? </AMF>

<mm2: Need to think this more through and expand upon.>

*	On Standard_Qualifiers, how does this map to TimetoPerform in
BPSS and TimeToLive in ebMS?
<AMF> Similar answer to the one above.  The time related standard
Qualifiers are advisory times in BTP nothing actually has to happen if
they expire.  The guideline relationships could be:
  TimetoPerform (BPSS and BCP) >= Transaction timelimit
 TimetoPerform (BPSS and BCP) >= Transaction timelimit + Minimum
inferior timeout >> TimeToLive (ebMS)
TimetoPerform (BPSS and BCP) >> Minimum inferior timeout>= inferior
timeout </AMF>

<mm2: Need to communicate that.>

*	Appears to be duplication or overlap in function in the BTP
extension and other specification elements at the process and the
application transport level.  Is this practical?  Please differentiate
or validate.
 <AMF>See above, but no - the intention is for the extension to provide
the configuration information for the BTP implementation and any other
parts of the system that are related to the BTP implementation or
impacted by it.  Anything already covered in the existing CPP/A
specification does not need to be (and will not be) covered in this
extension.
</AMF>

<mm2: State explicitly.>

:>)
Monica