IETF Logo Mail Archive

Re: Negotiated noncompliance

Dave Crocker <dcrocker@brandenburg.com> Wed, 16 August 2000 23:42 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 TAA05290 for <drums-archive@odin.ietf.org>; Wed, 16 Aug 2000 19:42:27 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA02570; Wed, 16 Aug 2000 19:42:09 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 16 Aug 2000 19:42:08 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id TAA02553; Wed, 16 Aug 2000 19:42:08 -0400 (EDT)
Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA02536; Wed, 16 Aug 2000 19:42:06 -0400 (EDT)
Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 16 Aug 2000 19:42:06 -0400
Received: from mg-209247130-141.ricochet.net (mg-209247130-141.ricochet.net [209.247.130.141]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id QAA19170 for <drums@cs.utk.edu>; Wed, 16 Aug 2000 16:42:03 -0700
X-Authentication-Warning: joy.songbird.com: mg-209247130-141.ricochet.net [209.247.130.141] didn't use HELO protocol
Message-Id: <4.3.2.20000816163616.00cb2c70@mail.bayarea.net>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Wed, 16 Aug 2000 16:41:38 -0700
To: drums@cs.utk.edu
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: Re: Negotiated noncompliance
In-Reply-To: <399B23B3.A53EC392@netscape.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

>  If an implementation receives protocol which is not
>permitted by the specification and the specification does not mandate
>the response to such illegal protocol, the implementation MAY consider
>the peer to have negotiated a nonstandard protocol.


In other words, a receiver is free to handle errors in any way it deems 
appropriate, unless the specification explicitly defines the handling of 
this particular effort.

Besides being on the wrong side of a slippery slope, this sort of language 
will only serve to make the distinction between "in spec" and "out of spec" 
more confused than it already is.

Any two consenting protocol engines may do anything they wish, in the 
privacy of their own interactions.  They do not need text to give them 
permission, especially when the text is of the form "if the sender goes 
outside the spec, you can choose whether top accept it."

The goal of a specification should be to remove choice, not add to it.

d/


=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

v2.23.0 | Report a Bug | By Email