[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