Re: Use of LWSP in ABNF -- consensus call

Douglas Otis <dotis@mail-abuse.org> Thu, 17 May 2007 15:58 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoiNF-0001Sv-8n; Thu, 17 May 2007 11:58:41 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HoMKH-0004Xg-1V for discuss-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 12:26:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMKG-0004XQ-Nq for discuss@apps.ietf.org; Wed, 16 May 2007 12:26:08 -0400
Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMKF-0000Fx-DI for discuss@apps.ietf.org; Wed, 16 May 2007 12:26:08 -0400
Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id DA6EC4142D; Wed, 16 May 2007 09:26:01 -0700 (PDT)
In-Reply-To: <20070515081053.GG33188@finch-staff-1.thus.net>
References: <BFE21101-5BC4-45FA-8905-89C2D4A1E593@osafoundation.org> <4648E8CB.3010502@dcrocker.net> <F5C06D62-639B-40CB-803F-6D9E50673768@osafoundation.org> <464926FC.30109@att.com> <20070515081053.GG33188@finch-staff-1.thus.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <27CD7D06-BEC7-4442-838C-76E4612C7E8B@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: Use of LWSP in ABNF -- consensus call
Date: Wed, 16 May 2007 09:25:56 -0700
To: Clive D.W. Feather <clive@demon.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400
Cc: Apps Discuss <discuss@apps.ietf.org>, Tony Hansen <tony@att.com>, IETF General Discussion Mailing List <ietf@ietf.org>, ietf-dkim@mipassoc.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

On May 15, 2007, at 1:10 AM, Clive D.W. Feather wrote:

> Tony Hansen said:
>>> I share your concerns about removing rules that are already in  
>>> use --
>>> that would generally be a bad thing.  However I'm interested in the
>>> consensus around whether a warning or a deprecation statement  
>>> would be a
>>> good thing.
>>
>> LWSP has a valid meaning and use, and its being misapplied somewhere
>> doesn't make that meaning and usage invalid. I could see a note being
>> added. However, anything more than that is totally inappropriate.
>
> +1
>
> Frank's text in
> <http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html>
> would be fine:
>
>   Authors intending to use the LWSP (linear white space) construct
>   should note that it allows apparently empty lines consisting only
>   of trailing white space, semantically different from really empty
>   lines.  Some text editors and other tools are known to remove any
>   trailing white space silently, and therefore the use of LWSP in
>   syntax is not recommended.
>
> However, it doesn't belong in "security considerations".

Discarding of lines is likely in response to some type of exploit.   
The consideration for not using LWSP would be in regard with how  
security requirements may create incompatibilities.  This is the  
correct section.


> What about moving LSWP, and this text, to a separate section of  
> Annex B:
> "B.3 Deprecated constructs"?

Agreed. That would also be appropriate.

Another problem regarding LWSP is in regard to _many_ differing  
definitions.  A profusion of differing definitions alone becomes a  
valid reason to deprecate the mnemonic.  This definition represents a  
poor practice as related to security which should not be facilitated  
through standardization.  By removing this problematic construct,  
better solutions are more likely to be found.  At least (ab)use of  
the mnemonic will have been discouraged.  Any continued use of this  
mnemonic should be discouraged and the note added should clarify one  
of the reasons for this mnemonic being deprecated is specifically due  
to its varied and checkered meanings in other drafts.

-Doug