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

John C Klensin <> Thu, 17 May 2007 19:50 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HolzK-0000Uq-5w; Thu, 17 May 2007 15:50:14 -0400
Received: from discuss by with local (Exim 4.43) id 1HolzI-0000Sr-DU for; Thu, 17 May 2007 15:50:12 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HolzH-0000SS-RZ for; Thu, 17 May 2007 15:50:11 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1HolzH-0001Tg-BW for; Thu, 17 May 2007 15:50:11 -0400
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1HolzE-0008Th-HM; Thu, 17 May 2007 15:50:08 -0400
Date: Thu, 17 May 2007 15:50:07 -0400
From: John C Klensin <>
To: Sam Hartman <>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Message-ID: <B72004EA211F8B332A31C671@p3.JCK.COM>
In-Reply-To: <>
References: <> <> <> <> <> <1504A69099CF1B62F66FE576@p3.JCK.COM> <> <E09D6916A9D19A52976E4567@p3.JCK.COM> <>
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: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: IETF General Discussion Mailing List <>, Harald Alvestrand <>, Apps Discuss <>, Dave Crocker <>, Paul Overell <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Sam, with one small exception, I think we are in complete
agreement.  The exception is noted below...

--On Thursday, 17 May, 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.  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.

Counting uses in this way so as to determine what is or is not
the "most common definition" is as tricky in our environment as
counting votes.  For the same reason, I'd rather that we avoid
it when we can.   However, if we do need to count, I think we
have to use some sort of system that attributes more weight to
documents that use the terminology that have been, effectively,
at full standard before some of the specifications that use
different definitions were even dreamt of.  I don't know how to
assign those weights, which, recursively, is why I don't like
counting.   But I don't think you can count up a handful of
recent misuses and then make an inference that the base
definition needs to be retired (which you haven't done, but
several others have), or even that it is not appropriately

> 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.

Pragmatically, perhaps yes.  But what I keep coming back to is
that it appears to me to be perfectly clear and unambiguous
"what LWSP means in ABNF today".  That is what is written into
the spec.  As far as I can tell, we are having a discussion
about two other things:

	(1) Other specifications that use the term "LWSP" to
	refer to something different from what is unambiguously
	defined in the ABNF spec.
	(2) Places where people might be tempted to use LWSP but
	where they have discovered that LWSP is either
	inappropriate or risky.

The second group clearly needs new and appropriate terminology
for what they do need and use.   The first group is, IMO, just

> LWSP will need to continue in ABNF.
> 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.

Again, I have no problems with making carefully-considered
comments about use and misuse.  I think it is a fine idea as
long as those comments do not imply that the misuses are a
failure in the base specification.  And I think everyone should
consider a stopping rule, lest, as I indicated in my
deliberately extreme example, we discover that we want to
retire, replace, or update "IP" because of some use in the legal
community that precedes the use in network protocols by many