Re: client requests ending \012
Keith Moore <moore@cs.utk.edu> Wed, 26 July 2000 13:35 UTC
Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11577 for <drums-archive@odin.ietf.org>; Wed, 26 Jul 2000 09:35:41 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA12899; Wed, 26 Jul 2000 09:35:21 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 09:35:20 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id JAA12881; Wed, 26 Jul 2000 09:35:20 -0400 (EDT)
Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA12864; Wed, 26 Jul 2000 09:35:18 -0400 (EDT)
Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 09:35:18 -0400
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA29613; Wed, 26 Jul 2000 09:35:13 -0400 (EDT)
Message-Id: <200007261335.JAA29613@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Dave Crocker <dcrocker@brandenburg.com>
cc: Philip Hazel <ph10@cus.cam.ac.uk>, Michael Scharff <mscharff@real.com>, drums@cs.utk.edu
Subject: Re: client requests ending \012
In-reply-to: Your message of "Wed, 26 Jul 2000 03:46:43 PDT." <4.3.2.20000726034406.00bb9430@mail.bayarea.net>
Date: Wed, 26 Jul 2000 09:35:13 -0400
Sender: moore@cs.utk.edu
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>
> The difficulty is with imposing a fix for a local problem as a global > product default. except that it's not purely a local problem - the same clients could (and often do) crop up anywhere. and the vendor ends up dealing with this support issue again and again. much easier to just 'fix' the problem. I'd say that the difficulty is one of trying to get people to accept near-term pain to minimize long-term pain. and also the difficulty of replacing many broken clients when you can "fix" the problem on a small number of servers. Keith this may actually be a "flaw" in the traditional IETF notion of interoperability testing being sufficient - merely being able to interoperate doesn't mean that the implementations conform to the standard, or more importantly, that the implementations behave robustly in corner cases (like LF . LF in the middle of a message).
- Re: client requests ending \012 Charles Lindsey
- Re: client requests ending \012 Michael Scharff
- Re: client requests ending \012 Philip Hazel
- Re: client requests ending \012 Lee Thompson
- Re: client requests ending \012 Tony Hansen
- RE: client requests ending \012 Michael Scharff
- RE: client requests ending \012 Larry Osterman
- Re: client requests ending \012 Michael Richardson
- RE: client requests ending \012 Paul Hoffman / IMC
- RE: client requests ending \012 Philip Hazel
- RE: client requests ending \012 Edward Hibbert
- RE: client requests ending \012 Maurizio Codogno
- Re: client requests ending \012 Eliot Lear
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Charles Lindsey
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Dave Crocker
- Re: client requests ending \012 Keith Moore
- Re: client requests ending \012 Charles Lindsey
- Re: client requests ending \012 DRUMS WG Chair
- Re: client requests ending \012 D. J. Bernstein
- Re: client requests ending \012 Kai Henningsen
- Re: client requests ending \012 Kai Henningsen
- Re: client requests ending \012 Philip Hazel