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? 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. 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 > > > >