Marty,
I respectfully disagree. I don't think that we need to say
anything.
persistDuration is a parameter that the parties have agreed
to use as the minimum amount of time that the party shall
commit to preserving message artifacts necessary for
support of the RM function (in many cases, messageId is
sufficient so that possible duplicate transmissions
of A MESSAGE can be detected).
A conversation will potentially have a SIGNIFICANTLY
longer duration than the lifetime of a single message
for purposes of reliable delivery. It could be weeks or
months. IMO it would be foolish to reuse the persistDuration
for purposes of determining how long to preserve the
conversational state of an exchange between parties
which would include SequenceNumber when used in conjunction
with message ordering.
Conversational state MUST be preserved for the life of the
conversation, period, full stop. One could include the list
of messageIds of all messages for a conversation in the
conversational state, but that would be potentially inefficient
w/r/t persistent store, especially given that after persistDuration
has expired the sending MSH should not (must not?) attempt
to redeliver a message to the receiving party that has been
unacknowledged.
The point is that the purpose of the persistDuration parameter
is to provide a reasonable limit on the amount of time that
a receiving party needs to preserve messageId in persistent
store for purposes of filtering out potential duplicate
transmissions of a single message. It has NOTHING to do with
the conversational state of an exchaneg between parties.
Cheers,
Chris
Martin W Sachs wrote:
> You need to say enough in the MSG spec to inform an implementer that
> persistDuration follows different rules for conversationId and
> last-ordered-message than for reliable messaging. Considering the amount
> of discussion we have had on this point, we cannot assume that a
> "reasonable implementer" will know what to do. There are plenty of examples
> in the newspapers about deadly mistakes made by reasonable implementers.
> The Risks Forum mut be full of them.
>
> 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
> *************************************************************************************
>
>
>
> Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 09:39:42 PM
>
> To: David Fischer <david@drummondgroup.com>
> cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <dlw@exceloncorp.com>,
> ebxml-msg@lists.oasis-open.org
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> The thing I have trouble with here is why we have to say anything
> in the spec. This is too suggestive of implementation detail
> IMO (although probably accurate). Why do we need to say anything
> about this at all?
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
>
>
>>OK, I think that will work, but it is not the whole message which needs
>>
> to be
>
>>saved. Once the message is delivered to the application, just the
>>
> MessageId,
>
>>CPAId, persistDuration, ConversationId, SequenceNumber (did I get
>>
> everything?)
>
>>need to be saved. The spec says now only the MessageId needs to be saved
>>
> but
>
>>that's not enough for MessageOrder.
>>
>>David.
>>
>>