Re: T2 Reliable Messaging w/o CPA or VIA...

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

My comments below.

*************************************************************************************

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



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 07/31/2001
03:22:15 PM

Sent by:  Chris.Ferris@Sun.COM


To:   ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
cc:
Subject:  Re: T2 Reliable Messaging w/o CPA or VIA...



Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
<snip/>
>
> The persistDuration "parameter" is a CPP/A artifact. It is not carried
> within the message envelope. Nor should it, IMO.
>
> MWS:  This is a classic example of the vagueness in the message service
> spec.  When I look at persistDuration, I see a definition that I have
> temerity to assume is part of the XML structucture.  If I back up to
> section 10.2, I see that the parameter information can be in the CPA or
the
> message header but nothing about which goes where.  To be able to parse
> 10.2 (and other places also?), I need to see, for each parameter, where
it
> is contained.  Of course the issue is muddied by the case where a
parameter
> is in the CPA but there is no CPA.  This needs a lot of clarifying.

Agreed.

>
> The purpose of this parameter, as I understand it, is to allow each party
> to declare its persistence capabilities such that the negotiation (or
> calculation
> of) the retries/retryInterval parameters that are to be used for
resending
> unacknowledged messages are acceptable to the receiving party. That is to
> say
> that if the intended recipient can only keep messages (or their artifacts
> as the case may be) for 5 minutes, then a computed value for
> (retries * retryInterval) that exceeds 5 minutes MAY present problems
> for the intended recipient since it cannot be guaranteed that it will
> have any record of the message being resent or its response message(s).
>
> MWS:  This clearly needs a lot more explanation in the CPP-CPA
> specification and
> is another example of a needed consistency check that the parser can't
do.

Agreed.

>
> In practice, when negotiating a CPA, the parties should (but who can
force
> them?)
> ensure that the computed value of the sender's retries * retryInterval
not
> exceed
> the intended recipient's persistDuration.
>
> MWS:  The consistency check mentioned above can enforce it if it is
stated
> as
> normative and built into the CPA tools.

But, the CPP/A specification isn't specifying a tool(s), only an XML
representation of the information that is a CPP/A document. Maybe what
this points to is the need for a CPP/A Composition Tool specification
that augments the CPP/A spec itself?

MWS:  Normative semantics statements should be a strong guide to the
tool builder.  However I would be amenable to a non-normative appendix that
discusses CPP/CPA semantics aspects of the tools.  Normative might
discourage
creative value-add thoughts on the part of the tool vendors.

Another possibility would be to express the document constraints
that are non-expressable using XML Schema using some other schema
language, such as RELAX-NG or Schematron.

>
> Nothing in the specification
> says that an MSH should discard a message (or its artifacts) from
> persistent
> store upon the expiration of persistDuration.
>
> MWS:  Yes there is.  See the second and third paragraphs of message
service
> 10.2.8.
> Granted it does say SHOULD...

It SHOULDn't ;-) Thanks for pointing that out.

>
> In fact, that would probably
> be a bad idea. I prefer to think of persistDuration as being the MINIMUM
> amount of time that a party can guarantee that it will preserve a message
> (or its artifacts) in persistent storage. This would help eliminate any
> potential problem with edge cases that compute retries and retryInterval
> to be some function of persistDuration (a practice I would recommend
> avoiding!)
>
> In practice, persistDuration should exceed retries * retryInterval by a
> wide
> margin.
>
> MWS:  I wonder if persistDuration should be eliminated and
> RetriesXRetryInterval
> defined as the time a message must be persisted.  There is still,
however,
> the case
> where the implementation's timeout exceed RetryInterval.  On the other
> hand, since
> the implementation knows its timeout, the rule can simply be that the
> message must
> be persisted long enough to perform the agreed number of retries and wait
> for the
> response to the final retry.

Again, persistDuration is a receiver parameter, not a sender parameter.
Your characterization above reflects the sender's perspective.

MWS:  But the CPA is an agreement; receivers should get some normative
thoughts from receiver parameters.  A bigger problem is that Retries,
and RetryInterval are in the delivery channel, hence they are receive
properties
although they really should be sender properties.  This may be another case
where
we need to expand sender properties and include document-exchange along
with
transport.

I think that persistDuration has value above and beyond retries *
retryInterval.
For one, when represented in a CPP, it delcares the party's capacity to
persistently store message artifacts such that reliable messaging can be
effected. When negotiating a CPA, this is quite useful. Its usefulness
in the CPA might be considered suspect as I would imagine that
persistDuration
wouldn't usually vary by party agreement. However, it could come in handy
to enable an implementation to vary persistDuration by agreement...

>
> As for persistDuration being applied to messages being sent, I would like
> to
> think that it has nothing to do with the sending MSH's behavior at all.
> The specification doesn't (correctly, IMO) say anything about
> persistDuration
> applying to messages being sent and their persistence. Maybe it could be
> made clearer to the reader that this parameter applies EXCLUSIVELY to
> messages received.
>
> MWS:  I agree.
>
> Note that this parameter applies ONLY to the persistence related to
> reliable
> messaging. It should not be interpreted to mean anything "application"
> specific
> (such as persistence related to auditing, non-repudiation or some other
> function).
>
> MWS:  I agree.
>
> Cheers,
>
> Chris
>
> Martin W Sachs wrote:
> >
> > David,
> >
> > The short answer is that persistDuration should be in either the header
> or
> > the CPA but probably not in both places.  In the header means that the
> > message sender always controls persistDuration.  In the CPA,
> > persistDuration should mean that both parties have agreed on a single
> > value.  However persistDuration is in the delivery channel which
denotes
> > receive properties, so there is still the possibility of a mismatch.
The
> > CPPA team may wish to prescribe agreement between the two Parties,
which
> > may mean that has to be the same in all delivery channels.
> >
> > The real question, however, is what is the value of persistDuration and
> why
> > is it needed along side the Retries/RetryInterval pair?
> >
> > 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
> >
>
*************************************************************************************

>
> >
> > "Burdett, David" <david.burdett@commerceone.com> on 07/30/2001 06:58:28
> PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
> > cc:   "'David Fischer'" <david@drummondgroup.com>
> > Subject:  RE: T2 Reliable Messaging w/o CPA or VIA...
> >
> > If persistDuration is in the header (instead of the CPA), what does it
> > mean?
> > Does it mean that the recipient should persist the message for the
> duration
> > specified? Or should it be ignored and the recipient rely by whatever
> they
> > put in their CPP. It is more flexible if it the length of time the
> message
> > is persisted as the recipient could always flag an error if it
considers
> > the
> > value too long.
> >
> > David
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Monday, July 30, 2001 3:48 PM
> > To: ebxml-msg@lists.oasis-open.org
> > Cc: 'David Fischer'; Burdett, David
> > Subject: RE: T2 Reliable Messaging w/o CPA or VIA...
> >
> > Regarding persistDuration, the message service spec (line 1758-59)
states
> > "If a message cannot be sent successfully before persistDuration has
> > passed, then the Sending MSH should report a delivery failure." Lines
> > 1756-1757 also place some responsibility on the sending MSH.
> >
> > The above statements mean that the persistDuration also applies to the
> > sending MSH and must be in the header. Or it could mean that it has to
be
> > in the CPA (or whatever you want to use instead of a CPA), where it in
> fact
> > is, so that both parties agree on the value.
> >
> > 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
> >
>
****************************************************************************

>
> >
> > *********
> >
> > ---------------------- Forwarded by Martin W Sachs/Watson/IBM on
> 07/30/2001
> > 06:38 PM ---------------------------
> >
> > "Burdett, David" <david.burdett@commerceone.com> on 07/30/2001 03:29:50
> PM
> >
> > To:   "'David Fischer'" <david@drummondgroup.com>
> > cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> > Subject:  RE: T2 Reliable Messaging w/o CPA or VIA...
> >
> > David
> >
> > Let's  take of these in turn ...
> >
> > mshTimeAccuracy
> > >>>This is the accuracy to which a recipient  of a message claims to
keep
> > their internal system clocks. This should probably  be part of a CPP
and
> > not vary from message to message therefore it does not need  to be in
the
> > MessageHeader
> >
> > reliableMessagingMethod
> > >>>This needs to be in the Via since it can vary on each hop of  a
> > multi-hop message. I suppose though that, if you are not doing
multi-hop
> > then  it forces use of the Via element. I think we could either:
> > 1. Put  reliableMessagingMethod in the main  MessageHeader with the
copy
> in
> > the Via element over-riding it, or
> > 2. Change  the definition of the Via element to suggest that it to be
> used
> > when there is no  intermediary
> > Thoughts?
> >
> > ackRequested
> > >>>This is in Via for the same reason as for  reliableMessagingMethod -
> it
> > can vary from hop-to-hop
> >
> > retries& retryInterval
> > >>>These are both parameters that apply to the  sender of a message and
> > over which the receiver of message can have no effective  control.
There
> is
> > therefore no need for them to be in the header. They should  however be
> in
> > the CPP for the sender
> >
> > persistDuration
> > >>>PersistDuration only applies to the  recipient of a message as it
> > specifies the minimum time the recipient will keep  a message. The
sender
> > cannot (should not?) control this, therefore there is no  need for it
to
> go
> > in the header.
> >
> > I'd  appreciate your thoughts.
> >
> > David
> > -----Original Message-----
> > From: David Fischer  [mailto:david@drummondgroup.com]
> > Sent: Monday, July 23, 2001 7:07  PM
> > To: Burdett, David
> > Cc: ebXML Msg
> > Subject: T2  Reliable Messaging w/o CPA or VIA...
> >
> > Section 10.2 (line 1695) says:
> >
> > This  parameter information can be specified in the CPA or in the
> > MessageHeader
> >
> > But I can't find anywhere in  the MessageHeader to set the following
> > parameters:
> >
> > mshTimeAccuracy
> > reliableMessagingMethod
> > ackRequested
> > retries
> > retryInterval
> > persistDuration
> >
> > This seems like a formidable problem when  doing reliable messaging
> > (ackRequested) without an intermediary (no  Via).  If we put this
> > information back in the MessageHeader, why is  it also in the Via?
This
> > was in the MessageHeader in v0.91 but it was  taken out... probably
> > shouldn't have been.
> >
> > Regards,
> >
> > David Fischer
> > Drummond  Group.
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org