OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo


   Date: Thu, 16 Aug 2001 21:36:10 -0500
   From: David Fischer <david@drummondgroup.com>

   Why can't end-to-end RM be completely independent of Intermediary RM.  I see no
   reason to mix them up like this.  This is making things too hard -- Simple is
   better.

Yes, absolutely.  This is exactly the kind of thing I am getting at
when I talk about using two layers of protocol.  The higher layer has
its own RM, and the lower layer can optionally have its own RM.
The two layers are defined separately and don't "know" about each
other except in a few carefully-specified ways.  Simple is better.

   RM does not automatically imply duplicate detection.  What about Intermediate RM
   with just Intermediate Acks so Intermediates do not worry about duplicates?
   This eliminates much of our problems.

Sure.  The IM's do not need to have duplicate elimination, and we could leave
it out entirely.

   Retries and RetryInterval are specified by the CPA.  CPPA does not consider
   Intermediaries so these are always end-to-end -- we have no choice (each end of
   a hop might/will also have a CPA with these parameters).  

(It would be a good idea to get straight whether there are CPA's
between IM's and endpoints, and also between IM's and IM's.  Different
opinions have been expressed both explicitly and tacitly in recent
mail.)

							     I don't like the idea
   that the Sender can't retry on lack of DeliveryReceipt because there may be
   cases where the Sender does not know there are Intermediates.  We can't have the
   end behavior dependant upon the hop count.  Ends must behave the same all the
   time.

I agree.  And since DeliveryReceipt is the end-to-end acknowledgement,
I definitely think that a From Party MSH should be able to retry on
lack of such acknowledgement (the DR).

   RetryCount would not cause a recalculation of the Signature if it was in Via

If layering were used, this whole question would not even arise.  The
signature would apply (only) to a higher-level-message.  The whole
high-level-message (body plus header) would appear to be an opaque
octet string to the lower-level protocol, and the
lower-level-protocol's header would, of course, not be signed.  It
would all be so simple that we would not even think of discussing it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC