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).