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 Retry with Delivery Receipt


+1

TCP barring a MITM attack ensures that there is lossless
transmission of the message between the TCP endpoints
of the message is not "received".

Cheers,

Chris

Martin W Sachs wrote:
> 
> You are still postulating that there are transmission errors that won't be
> caught by either TCP or the underlying physical transport.  You need to
> make a convincing case that the can happen.
> 
> 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
> *************************************************************************************
> 
> "David Fischer" <david@drummondgroup.com> on 09/19/2001 10:43:42 PM
> 
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   "Dan Weinreb" <dlw@exceloncorp.com>, <ebxml-msg@lists.oasis-open.org>
> Subject:  RE: T2 Retry with Delivery Receipt
> 
> Actually NRR is exactly for making sure that the message arrived intact,
> either
> as a protection from transmission failures or from security breaches (e.g.
> man-in-the-middle attack).  It might be pretty bad if I ordered 2 items and
> there was a transmission failure and it got changed to 1,000,002 (actually
> it
> would be more binary than that).  The signature assures the To Party that
> it did
> not change and NRR assures back to the From Party that it did not change
> (round
> trip).
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, September 19, 2001 9:26 PM
> To: David Fischer
> Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org
> Subject: RE: T2 Retry with Delivery Receipt
> 
> NRR is a non-repudiation function.  It is not intended as a transmission
> error detector.  Someone will have to make a convincing case that TCP is
> not sufficient for detecting transmission errors.
> 
> 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
> ********************************************************************************
> 
> *****
> 
> David Fischer <david@drummondgroup.com> on 09/19/2001 10:46:21 AM
> 
> To:   Dan Weinreb <dlw@exceloncorp.com>
> cc:   ebxml-msg@lists.oasis-open.org
> Subject:  RE: T2 Retry with Delivery Receipt
> 
> Very good.  I agree with most of it.
> 
> One comment about check-sums.  We already have an transmission
> error-catching
> mechanism called NRR.
> 
> On the whole, I think this is very good.  The point is that there are some
> scenarios which would require a retry.  But I prefer to phrase the question
> differently -- why would an IM *ever* stop a retry from the end?  It is not
> the
> job of an IM to tell the ends what they may or may not send.  Since it is
> an
> easy thing to differentiate between an IM retry and an end retry, its not
> "why
> would we" but rather "why wouldn't we"?
> 
> This may all be moot since built-in problems with multi-hop (like not
> allowing
> end-to-end retries) could force IMs out of the picture.  I'd rather not,
> but . .
> . ?
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Wednesday, September 19, 2001 9:16 AM
> To: david@drummondgroup.com
> Cc: Chris.Ferris@sun.com; ebxml-msg@lists.oasis-open.org
> Subject: Re: T2 Retry with Delivery Receipt
> 
>    Date: Tue, 18 Sep 2001 15:34:58 -0500
>    From: David Fischer <david@drummondgroup.com>
> 
> <rhetoric-mode>
> 
>    "I don't want to" is not a valid reason.  "It's too complicated" is
> almost as
>    bad (how hard is it to concatenate two strings?).  We can allow retries,
> Chris
>    just doesn't want to.  Why?
> 
> The reason is "It wouldn't do any good".
> 
> If the reason the message didn't get through is that the (unreliable)
> transport layer dropped it, the regular ("hop-to-hop") retry mechanism
> exists to deal with that problem.  There is no need to impose a second
> retry mechanism on top of the first one: or, if there is, then there
> is also a need for a third and fourth layer and so on.
> 
> You said:
> 
>    <df>retries do not guarantee success and never will.  The question is
> what to
> do
>    when those failures occur.</df>
> 
> But what are you saying we should do?  You seem to be saying that we
> should retry some more.
> 
> </rhetoric-mode>
> 
> OK, OK, you're not really saying that.  And I don't really believe
> that they don't do any good under any scenarios.  I think the case for
> end-to-end retry should be made by clearly stating the scenarios where
> end-to-end retry adds value that hop-to-hop retry does not.
> 
> Let's consider why retrying the *same* message (same message ID, same
> digital signature, same contents, just as you say, everything the same
> except certain fields that are specific to the hop-to-hop layer of
> communication) *ever* does *any* good.  If it failed the first time,
> why won't it just keep on failing and failing?  I can see two
> categories of reason:
> 
> (1) There are *random* *transient* failures that happen often enough
> to worry about.  Simply trying again has a good chance of succeeding.
> 
> (2) Something in the external environment changes before the retry.
> I think that's what you had mind when you said "it might be manual"
> and "It might be now or after a fix."
> 
> The "unreliable IM" is an example of (1) that isn't handled by
> hop-to-hop retry and would be handled by automatic, right-now
> end-to-end retry.  It's still not clear that a convincing use
> case for this has been presented.
> 
> What are the scenarios in which (2) provides the justification for the
> retry?  David F, you presented some "example use cases", but some of
> them aren't what we need as scenarios, because they are effects rather
> than causes, e.g. "a DFN sent" or "an Error Message sent".  What I
> think of as a "scenario" has to explain why they were sent: what
> actually went wrong in the first place?
> 
> So let me try some scenarios.  I think scenarios break down into two
> categories: those in which the From party gets some kind of negative
> reply, and those where the From party times out.
> 
> Suppose I send a purchase order to Staples and I digitally sign it
> with a private key, and in the ds:keyInfo I send a certificate with
> the corresponding public key, but unfortunately this certificate
> expired a few days ago.  The To Party sees that the certificate has
> expired, so the digital signature is no good, so it rejects the
> message.  Automatic retries are clearly pointless.  The From people
> could transmit a new certificate out-of-band to the To people and tell
> them to force their MSH to use the new certificate on the existing
> message, but this seems kind of implausible for various reasons.  Or
> the From side could obtain a new certificate, and then send the
> message with the new certificate.  But then it's not the same message,
> as defined above.  Should it have the same messageID?  (I don't have
> an answer to this.)
> 
> Suppose Staples changes its address.  I sent a purchase order to
> Staples, and the CPA says to use HTTP to www.staples.com, and upon
> trying that I get an HTTP 404 (no such URL), or even a DNS error
> ("there's no such host name as "www.staples.com").  Automatic retries
> do no good.  But if administrators at the From host install a new CPA,
> then retrying the exact same message could succeed.
> 
> Suppose Staples's MSH machine has run out of disk space and rejects
> the incoming message.  Automatic retries could solve this, by simply
> retrying until ordinary work frees up disk space, or the
> administrators at Staples add a new disk.  On the other hand, the
> hop-to-hop retry mechanism could do that just as well.  But this
> brings up a question as to when retries ought to time out.  You could
> say that knowing when to really give up sometimes requires manual
> intervention or special knowledge; no simple time-interval value in a
> CPA can substitute for intelligent ways of deciding how long to retry.
> You might posit that a retry mechanism operating at the end-to-end
> level is better positioned to allow this kind of intelligence to be
> brought to bear than a hop-to-hop retry mechanism.
> 
> Related scenario: Staples installs a new release of its MSH software,
> the new release has bugs that cause it to wrongly reject messages; we
> retry after Staples goes back to the old release or installs a fix.
> Similarly, an administrator at Staples messes with the configuration
> settings so that our messages are wrongly rejected, etc.
> 
> (The From MSH might have some kind of fancy features allowing
> administrators finer control over retry.  There might be commands like
> "stop retransmitting this message but keep it in the MSH so that we
> can commence retranmsitting later".  None of this would be part of the
> normative protocol specification.  David F, I get the impression that
> have in mind something like this.)
> 
> Then there are timeout scenarios, e.g. what you called "lack of DR".
> Chris said "If the DR is sent reliably, then its absense is
> significant cause for concern."  I agree, but we still have to figure
> out how to react if a DR does not appear after a "reasonable timeout".
> What scenarios might produce this?  Actually, we don't really need a
> "scenario" as such.  Reliable messaging still allows for the
> possibility that the sender still (after any given time interval) does
> not know whether the message has actually been delivered yet.  So a DR
> can take longer than any "reasonable timeout" even if there has been
> no failure.  If the From side wants to learn whether the message was
> ever recieved, it can either just keep waiting, or it can send a
> message, which might be exactly the same as the original message, or
> might be a Message Status Request.
> 
> You mentioned "XML text corruption in transit".  If we are really
> concerned about data corruption that's not caught by the TCP checksum,
> then we really need to add an error-correcting-code as part of our own
> protocol.  If we don't add one, then we're clearly operating under the
> assumption that the transport layer can be trusted to never deliver
> corrupted data.  (Our failure model for the transport layer is that
> it's "unreliable" in the sense that it can drop messages, but it
> always detects data corruption and discards such messages, so it never
> delivers us corrupted bits.)
> 
> -- Dan
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC