IETF Logo Mail Archive

Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nico's suggestions - Re: Consensus Call:

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 11 May 2010 20:05 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F763A6A90 for <tls@core3.amsl.com>; Tue, 11 May 2010 13:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.168
X-Spam-Level:
X-Spam-Status: No, score=-4.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+Hfn-Y3ATpI for <tls@core3.amsl.com>; Tue, 11 May 2010 13:05:46 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 2A25B28C194 for <tls@ietf.org>; Tue, 11 May 2010 13:05:20 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 11 May 2010 16:04:46 -0400
Message-ID: <201005112005.o4BK54qO014241@stingray.missi.ncsc.mil>
In-Reply-To: <4BE9AFA9.5070607@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
Thread-Index: AcrxQAkaJOboZwuNRpW5VAsCKSa1xQAA1Vvg
References: <20100510221531.GC9429@oracle.com><201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp> <20100511152153.GF9429@oracle.com> <201005111803.o4BI3fhO006065@stingray.missi.ncsc.mil> <4BE9AFA9.5070607@extendedsubset.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 11 May 2010 20:06:17.0171 (UTC) FILETIME=[6A495A30:01CAF145]
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nico's suggestions - Re: Consensus Call:
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 20:05:47 -0000

If there is a script to FTP a bunch of files, and one of the files
fails, then either a human or a manifest-understanding application needs
to notice the error and retry.  FTP itself doesn't have to be as
persistent about recovery as wget, but something above it needs to be.
How would FTPS with a cache collision induced failure be different?

Dave


-----Original Message-----
From: Marsh Ray [mailto:marsh@extendedsubset.com] 
Sent: Tuesday, May 11, 2010 3:28 PM
To: Kemp, David P.
Cc: tls@ietf.org
Subject: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Nico's suggestions -
Re: Consensus Call:
Importance: Low

On 5/11/2010 1:03 PM, Kemp, David P. wrote:
> This sounds like a general problem unrelated to caching.
> 
> If a non-browser app cannot recover from failures, what happens when a
> bit error gets through multiple layers of detection and correction, or
a
> DSL connection dies and restarts?   "Stuff happens" all the time, and
> humans know how to hit the "retry" button.  An unattended application
> that doesn't know how to recover from unexplained errors is not ready
> for prime time.

FTP, telnet, and friends were considered to work well enough for a long
time. I think SSH still doesn't have any reconnection support in the
protocol.

- Marsh

v2.2.0 | Report a Bug | By Email