IETF Logo Mail Archive

Re: ABNF

Frank Ellermann <nobody@xyzzy.claranet.de> Fri, 02 February 2007 21:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5kb-0002f6-Ef; Fri, 02 Feb 2007 16:15:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5ka-0002eO-Dz for discuss@apps.ietf.org; Fri, 02 Feb 2007 16:15:16 -0500
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD5kY-0007mD-GM for discuss@apps.ietf.org; Fri, 02 Feb 2007 16:15:16 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HD5kW-0007aE-Mx for discuss@apps.ietf.org; Fri, 02 Feb 2007 22:15:13 +0100
Received: from 212.82.251.96 ([212.82.251.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <discuss@apps.ietf.org>; Fri, 02 Feb 2007 22:15:12 +0100
Received: from nobody by 212.82.251.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <discuss@apps.ietf.org>; Fri, 02 Feb 2007 22:15:12 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: discuss@apps.ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Subject: Re: ABNF
Date: Fri, 02 Feb 2007 22:08:19 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 48
Message-ID: <45C3A843.10A7@xyzzy.claranet.de>
References: <875A124D75A8B481E176CF06@p3.JCK.COM> <20070202113853.GW7742@finch-staff-1.thus.net> <20070202125012.GA18307@nic.fr> <45C345A9.1589@xyzzy.claranet.de> <20070202185856.GI68544@finch-staff-1.thus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 212.82.251.96
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

Clive D.W. Feather wrote:

> I pointed this out to Paul a while ago.

Thanks, apparently not yet noted as RFC 4234 "erratum".

But something happened, they've finally processed Ned's
simple 2045 erratum - as "unverified", now what's that, 
do they try to verify that the submitter is the author ?

>> IMO RFC 4234 is fine, its LWSP is an exception, FWS
>> as in RFC 2822 (excl. obs-FWS) would be better.

> I'm not sure what point you're trying to make here.

| LWSP =  *(WSP / CRLF WSP)

That allows multiple empty lines consisting only of WSP.

For FWS minus obs-FWS that's impossible (and a loophole
in CFWS is covered by a MUST NOT in the RFC 2822 prose):

| FWS  = ([*WSP CRLF] 1*WSP) /   ; Folding white space

The real damage is in the #rule in RFC 2068 ff. up to 2831bis:

| a rule such as "( *LWS element *( *LWS "," *LWS element )) "
| can be shown as "1#element".
[...]
| implied *LWS
|  The grammar described by this specification is word-based. Except
|  where noted otherwise, linear whitespace (LWS) can be included
|  between any two adjacent words (token or quoted-string), and
|  between adjacent tokens and delimiters (tspecials), without
|  changing the interpretation of a field. At least one delimiter
|  (tspecials) must exist between any two tokens, since they would
|  otherwise be interpreted as a single token.
[...]
| LWS   = [CRLF] 1*( SP | HT )

The same issue as in LWSP, but in RFC 2068 etc. it's hidden in the
#rule and the odd "implied *LWS":  It allows to insert constructs
like <CRLF><SP><CRLF><HT> anywhere.  RFC 2822 tries to eliminate
this possibility in its obs-FWS chapter (4.2), and in the USEFOR
I-Ds obs-FWS is explicitly verboten.  Trailing white space is evil.

Frank

v2.23.0 | Report a Bug | By Email