RE: client requests ending \012
Maurizio Codogno <Maurizio.Codogno@cselt.it> Wed, 26 July 2000 09:37 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 FAA17627 for <drums-archive@odin.ietf.org>; Wed, 26 Jul 2000 05:37:27 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA28829; Wed, 26 Jul 2000 05:37:13 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 05:37:12 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id FAA28812; Wed, 26 Jul 2000 05:37:12 -0400 (EDT)
Received: from ss3000e.cselt.it (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA28799; Wed, 26 Jul 2000 05:37:04 -0400 (EDT)
Received: from ss3000e.cselt.it (163.162.41.5 -> ss3000e.cselt.it) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 05:37:08 -0400
Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FYA00BJOSO7GK@ss3000e.cselt.it> for drums@cs.utk.edu; Wed, 26 Jul 2000 11:21:43 +0200 (MET DST)
Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by beatles.cselt.it (8.9.3/8.9.3) with SMTP id LAA26383 for <drums@cs.utk.edu>; Wed, 26 Jul 2000 11:26:49 +0200 (MET DST)
Date: Wed, 26 Jul 2000 11:26:49 +0200
From: Maurizio Codogno <Maurizio.Codogno@cselt.it>
Subject: RE: client requests ending \012
To: drums@cs.utk.edu
Reply-to: Maurizio Codogno <Maurizio.Codogno@cselt.it>
Message-id: <200007260926.LAA26383@beatles.cselt.it>
MIME-version: 1.0
X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc
Content-type: TEXT/plain; charset="us-ascii"
Content-MD5: cAcvdCaSB7yDVGm1qWQhPw==
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>
> From: Edward Hibbert <EH@datcon.co.uk> > I disapprove of the "must not recognise" text. I think that: > - existing implementations will ignore this text in the proven interest of > interoperability > - any new implementor who follows the RFC will become very frustrated when > it later emerges that the RFC is explicitly encouraging them to add interop > problems to their code. but this means that you explicitly defy the scope of the standard, approving bad implementations and mandating good guys to accept them. ciao, .mau.
- 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