OASIS ebXML Messaging Services TC

Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId

  • 1.  Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId

    Posted 12-05-2001 13:21
    That's fine then.
    
    Martin W Sachs wrote:
    
    > Chris,
    > 
    > I agree with everything you say. You can't possibly use persistDuration to
    > control how long the conversationId has to be persisted.  No argument at
    > all.
    > 
    > I am simply less trusting than you are of "reasonable implementers" so I
    > suggested underlining that persistDuration is not applicable to message
    > ordering and conversationId retention.  That's all. If I really had my way,
    > I would capture a number of the points from your posting in the
    > non-normative statement that persistDuration is not applicable  to meesage
    > ordering and conversationId retention.
    > 
    > 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/05/2001 10:17:12 AM
    > 
    > To:    ebxml-msg@lists.oasis-open.org
    > cc:
    > Subject:    Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
    > 
    > 
    > 
    > 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.
    >>>
    >>>