Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call

Douglas Otis <dotis@mail-abuse.org> Fri, 18 May 2007 16:39 UTC

Return-path: <ietf-dkim-bounces@mipassoc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5U5-0004bQ-Gz for ietf-dkim-archive@lists.ietf.org; Fri, 18 May 2007 12:39:17 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp5U2-0004qO-UX for ietf-dkim-archive@lists.ietf.org; Fri, 18 May 2007 12:39:17 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4IGbwtN023330; Fri, 18 May 2007 09:38:04 -0700
Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4IGbpFh023257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Fri, 18 May 2007 09:37:53 -0700
Received: from [IPv6:::1] (gateway.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1EB5741426; Fri, 18 May 2007 09:37:54 -0700 (PDT)
In-Reply-To: <op.tsiw7b106hl8nm@clerew.man.ac.uk>
References: <BFE21101-5BC4-45FA-8905-89C2D4A1E593@osafoundation.org> <4648E8CB.3010502@dcrocker.net> <F5C06D62-639B-40CB-803F-6D9E50673768@osafoundation.org> <4649FA12.30909@alvestrand.no> <4649FB9A.9000107@bbiw.net> <1504A69099CF1B62F66FE576@p3.JCK.COM> <tsllkfnwgfb.fsf@mit.edu> <E09D6916A9D19A52976E4567@p3.JCK.COM> <tsl7ir7utz8.fsf@mit.edu> <B72004EA211F8B332A31C671@p3.JCK.COM> <Pine.LNX.4.64.0705180011310.12940@hermes-1.csi.cam.ac.uk> <op.tsiw7b106hl8nm@clerew.man.ac.uk>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <5F6FE074-DF3C-42E9-AB56-30F673938703@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Date: Fri, 18 May 2007 09:37:54 -0700
To: Charles Lindsey <chl@clerew.man.ac.uk>
X-Mailer: Apple Mail (2.752.2)
X-Songbird: Clean, Clean
Cc: DKIM <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

On May 18, 2007, at 6:03 AM, Charles Lindsey wrote:
>
> Well do we know exactly how much Babel there is?

John Leslie published this list on the IETF reflector:

rfc0733 obs-by rfc0822
rfc0822 defs LWSP-char = SPACE / HTAB   obs-by rfc2822
rfc0987 refs rfc0822
rfc1138 refs rfc0822
rfc1148 refs rfc0822
rfc1327 refs rfc0822
rfc1486 refs rfc0822
rfc1505 refs rfc0822
rfc1528 refs rfc0822
rfc1848 defs <LWSP-char> ::= SPACE / HTAB
rfc2017 refs rfc0822
rfc2045 refs rfc0822
rfc2046 refs rfc0822
rfc2110 refs rfc0822
rfc2156 refs rfc0822
rfc2184 refs rfc0822
rfc2231 refs rfc0822
rfc2234 defs LWSP = *(WSP / CRLF WSP)   obs-by rfc4234
rfc2243 refs rfc0822
rfc2378 defs LWSP-char = SP | TAB
rfc2530 refs rfc2234
rfc2885 defs LWSP = *(WSP / COMMENT / EOL)
rfc3015 defs LWSP = *(WSP / COMMENT / EOL)
rfc3259 defs LWSP = *(WSP / CRLF WSP)
rfc3501 refs rfc2234
rfc3525 defs LWSP = *(WSP / COMMENT / EOL)
rfc3875 defs LWSP = SP | HT | NL
rfc4234 defs LWSP = *(WSP / CRLF WSP)
rfc4646 refs rfc2434

> If we deprecate LWSP for future use, then the remaining problem is  
> the set of existing standards that rely on it (plus a few that have  
> redefined it/whatever, but those are not strictly relying on it).

Deprecating LWSP would not _remove_ or _redefine_ this macro.  The  
deprecation note could simply state this construct often is  
problematic when addressing security issues or when dealing with  
trailing whitespace.  Any future use of this construct should be  
locally defined with a different mnemonic, and preferably employ a  
different construct where possible.   Any existing standard would  
simply reference a deprecated, existing, and unchanged definition  
that has been deprecated by such a note.

-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html