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

John C Klensin <john-ietf@jck.com> Fri, 18 May 2007 14:03 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 1Hp33U-0003z5-2k; Fri, 18 May 2007 10:03:40 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hp33T-0003ys-10 for discuss-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:03:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp33S-0003yk-Nb for discuss@apps.ietf.org; Fri, 18 May 2007 10:03:38 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp33Q-00023t-BY for discuss@apps.ietf.org; Fri, 18 May 2007 10:03:38 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hp33M-000IqQ-50; Fri, 18 May 2007 10:03:32 -0400
Date: Fri, 18 May 2007 10:03:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: Tony Finch <dot@dotat.at>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Message-ID: <4EB341F4BEA39A01B2F9C84D@p3.JCK.COM>
In-Reply-To: <Pine.LNX.4.64.0705180849560.12940@hermes-1.csi.cam.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> <CF36D27A6AC084536D6D8F24@[192.168.1.119]> <4512BF1B1B2C8C4A9487E733@p3.JCK.COM> <Pine.LNX.4.64.0705180849560.12940@hermes-1.csi.cam.ac.uk>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: Apps Discuss <discuss@apps.ietf.org>, 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 Friday, 18 May, 2007 09:00 +0100 Tony Finch <dot@dotat.at>
wrote:

> On Thu, 17 May 2007, John C Klensin wrote:
>> 
>> After all <CRLF> Thing <SPACE><CRLF> could case similar
>> problems if some construction permitted it ...
> 
> This is not news. There have for a long time been problems with
> significant trailing space, which is why CRLF 1*WSP CRLF in a
> header is part of the obs- syntax of 2822, and why
> quoted-printable encodes WSP at the end of a line.
> 
>> ... and defining a grammar that would prohibit any
>> <SPACE><CRLF> construction isn't easy in ABNF for reasons
>> that have nothing to do with LWSP.
> 
> This is simply incorrect. It's trivial to define a whitespace
> construction that only allows CRLF at the beginning of a
> sequence:
> 
> 	NTWSP = [CRLF] 1*WSP ; non-trailing white space

Sure.  Except that much, if not most, of our textual
descriptions of these protocols describes lines, and line-like,
constructions as _ending_ in CRLF.  Moving to  "starting in
CRLF" creates a conceptual difference between prose definition
and formal syntax, which strikes me as a bad idea.   Of course,
in the above, since [CRLF] is optional, "1*WSP" alone satisfies
the production as written and still does not prevent
    <CRLF> space space space 
    <CRLF>
unless _all_ productions are written CRLF first... or one relies
on the comment as a restriction.   And a comment as the
restriction --in the prose-- is exactly what has been suggested,
IMO.

      john