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

Harald Tveit Alvestrand <> Thu, 17 May 2007 19:53 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Hom2X-0006tB-47; Thu, 17 May 2007 15:53:33 -0400
Received: from discuss by with local (Exim 4.43) id 1Hom2S-0006iq-T7 for; Thu, 17 May 2007 15:53:29 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Hom2R-0006eB-0V for; Thu, 17 May 2007 15:53:27 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Hom2H-0002RR-JG for; Thu, 17 May 2007 15:53:26 -0400
Received: from localhost ( []) by (Postfix) with ESMTP id E02C52596DC; Thu, 17 May 2007 21:53:16 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 24494-04; Thu, 17 May 2007 21:53:11 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTP id 809612596DA; Thu, 17 May 2007 21:53:11 +0200 (CEST)
Date: Thu, 17 May 2007 21:52:45 +0200
From: Harald Tveit Alvestrand <>
To: Sam Hartman <>, John C Klensin <>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Message-ID: <CF36D27A6AC084536D6D8F24@[]>
In-Reply-To: <>
References: <> <> <> <> <> <1504A69099CF1B62F66FE576@p3.JCK.COM> <> <E09D6916A9D19A52976E4567@p3.JCK.COM> <>
X-Mailer: Mulberry/4.0.7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: Apps Discuss <>, IETF General Discussion Mailing List <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

--On 17. mai 2007 15:32 -0400 Sam Hartman <> wrote:

> Right.  Here, I don't think the definition is wrong, I just think the
> term being defined is wrong.  We proposed a definition for a useful
> concept.

Actually we defined a concept (LWSP) in a way that turned out to be much 
troublesome in several contexts than we thought it would be (because it 
two different versions of "blank" lines to have different semantics).

>  The word we chose (LWSP) stuck in some places but not in
> others.  IN fact other people used the same word for a different
> although related concept.  sufficiently so that the definition we
> proposed in ABNF is not the most common definition in our standards.
> Clearly we should not invalidate existing uses of that term.  Clearly
> we do need a definition for the term: it is being used usefully.

I don't agree with the meaning I get from this statement. The problem is 
that the construct that ABNF calls "LWSP" causes problems in protocols that 
use it.
This problem is independent of the name of the construct; the problem is in 
defining a grammar where the sequence <CRLF><CRLF> has a different meaning 

Some protocols have addressed this problem by defining their own construct, 
and have used the term "LWSP" to refer to it - something that is legal by 
ABNF rules, but can cause people who read multiple specs to become confused.

There seems to be some reason to think that it's useful to warn people that 
there's reasons not to use the construct that is defined as "LWSP" in the 
ABNF spec. The revised version of the ABNF spec is one possible place to 
put that warning.

> I think that in this instance, the value of future clarity justifies
>  coming up with a new term that will unambiguously mean what LWSP
>  means in ABNF today.  That term will have to start at proposed
>  standard.
> LWSP will need to continue in ABNF.

I agree with the last statement.

> I see a desire to document our operational experience with the word:
> many people took this word and used it to mean something else.
> Perhaps to avoid confusion you should consider whether your use of the
> word is a good idea.  I think there is significant harm in choosing
> not to document this operational experience when advancing standards.
> After all, we both agree that it is this experience with running code
> that gives the IETF value.

Fully agree with this statement too, but since I don't agree with your 
interpretation (as given above) of what the problem is, I can't be sure 
that my agreement with this statement means anything....