Re: Use of LWSP in ABNF -- consensus call

Dave Crocker <dhc2@dcrocker.net> 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 1HoiNE-0001Qx-Br; Thu, 17 May 2007 11:58:40 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HnjRu-0008JS-30 for discuss-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 18:55:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnjRt-0008JK-Oz for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnjRs-0003A5-CH for discuss@apps.ietf.org; Mon, 14 May 2007 18:55:25 -0400
Received: from [10.2.2.93] (207.47.11.9.static.nextweb.net [207.47.11.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4EMt5Kl005914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 May 2007 15:55:05 -0700
Message-ID: <4648E8CB.3010502@dcrocker.net>
Date: Mon, 14 May 2007 15:55:07 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: Use of LWSP in ABNF -- consensus call
References: <BFE21101-5BC4-45FA-8905-89C2D4A1E593@osafoundation.org>
In-Reply-To: <BFE21101-5BC4-45FA-8905-89C2D4A1E593@osafoundation.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: dhc2@dcrocker.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-Mailman-Approved-At: Thu, 17 May 2007 11:58:36 -0400
Cc: Apps Discuss <discuss@apps.ietf.org>, Paul Overell <paul.overell@thus.net>, 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
Reply-To: dcrocker@bbiw.net
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


Lisa Dusseault wrote:
> The IESG reviewed 
> <http://www.ietf.org/internet-drafts/draft-crocker-rfc4234bis-00.txt> for 
> publication as Internet Standard and would like to know if there is 
> consensus to recommend against the use of LWSP in future specifications,

Lisa,

Process:

1   This issue was initially raised in the IESG by Chris Newman, who changed
his Discuss, with a statement that he recommended inserting a comment, along
the lines that others are also recommending.  Unless I've misread the record,
all other votes on advancing ABNF from Draft to Full are positive or neutral,.
except for your own Discuss.  Is this correct?

2.  The ABNF is a candidate for moving from Draft to Full.  Will removing a
rule (that is already in use?) or otherwise changing the semantics of the
specification, at this point, still permit the document to advance?  I had the
impression that moving to Full was based on some serious beliefs about a
specification's being quite stable.  Making this kind of change, this late in
the game, would seem to run counter to that.


> as it has caused problems recently in DKIM and could cause problems in 
> other places.

Semantics:

      "Could cause problems in other places"...  The DKIM hiccup was the first
one I'd heard about.

      By contrast, "linear-white-space" was defined in RFC733, in 1977, with
RFC822 retaining that definition.  It is defined in those places as
essentially the same as LWSP in the current ABNF Draft Standard specification.

      This seems to be one LWSP problem in 30 years. Is this really a
sufficient basis for changing the semantics of something that has been stable
and widely used for 10-30 years (depending upon how you count)?

      Are we reasonably comfortable that making the change will not create new
and different problems, such as for other uses of ABNF?


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net