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: Fri, 17 Aug 2001 09:01:51 -0700
   From: Arvola Chan <arvola@tibco.com>

   I agree that if intermediate MSHs do not perform duplicate
   elimination, then achieving end-to-end reliable messaging is
   easy. I also agree that simpler is better. Do you see a real
   adavantage in retaining the use of intermediate Acks?

With the two-layer approach, it's easy to do acks, duplicate
elimination, etc. hop-to-hop if you want to, although it's entirely
optional.  Is there a real advantage?  For each hop, the less reliable
the hop, the more advantage.  If a hop is less reliable
(statistically) than some threshold, then the extra costs of doing
acks and retransmits and duplicate elimination are more than offset by
the savings of not having to do the whole end-to-end trip multiple

   I find it cumbersome for the sending MSH to deal with two sets of
   retry parameters, one for the next MSH, the other for the
   destination MSH.

With the two-layer approach (and using reliability in the lower
layer), each protocol implementation only deals with one set of retry
parameters.  (The MSH pretty much corresponds to what I called the
HLPI in my previous mail.)  Each end party runs both the HLPI and the
LLPI, and each has its own retry parameters, but they don't know about
each other.

   CPA's currently don't work with intermediaries. The retry and
   retryInterval parameters to intermediaries can only be configured
   through proprietary means. I guess I am in favor of doing away with
   intermediate Acks altogether, or at least until they can be
   specified through CPA's.

So, you might ask me, is there both a high-layer CPA and a low-layer
CPA?  Certainly there's a high-layer CPA, which is basically the CPA
we have now.  I think it would be good if we could avoid the need for
a low-layer CPA (mainly to reduce the administrative burden of
creating and distributing low-layer CPA's all over the place).  The IP
protocol gets away without anything like a CPA, and so does TCP.  The
LLP does not need to be cognizant of a lot of the interesting stuff
that the CPA deals with, and so I think that an LLP connection would
need relatively few parameters, and they could be negotiated

   I agree. Now I see the advantage of XMLDSIG which allows the
   exclusion of certain elements from the signature.

That's a good thing about XMLDSIG, but with the two-layer approach I
don't think it's needed.  The HTPI constructs its HLP message, signs
and/or encrypts the whole thing, and passes it into the LLP.  The LLP
sees it as an opaque octet array.  All the stuff that you don't want
signed is in the LLP headers, and all the stuff that you do want
signed is in the HLP headers and payload.  So you don't need to use
the "sign some but not all" stuff, so everyting is simpler.

-- Dan

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

Powered by eList eXpress LLC