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

Keith Moore <moore@cs.utk.edu> Fri, 18 May 2007 01:36 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 1HorNy-0006JG-Kb; Thu, 17 May 2007 21:36:02 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HorNx-0006J5-TI for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 21:36:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HorNx-0006Is-JZ for discuss@apps.ietf.org; Thu, 17 May 2007 21:36:01 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HorNw-0004Tn-8y for discuss@apps.ietf.org; Thu, 17 May 2007 21:36:01 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2A1791EE1E5; Thu, 17 May 2007 21:35:59 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2sahLWcl+Gm; Thu, 17 May 2007 21:35:52 -0400 (EDT)
Received: from lust.indecency.org (dialup-4.154.53.75.Dial1.Atlanta1.Level3.net [4.154.53.75]) by shu.cs.utk.edu (Postfix) with ESMTP id 70B521EE1D9; Thu, 17 May 2007 21:35:49 -0400 (EDT)
Message-ID: <464D02EF.6070607@cs.utk.edu>
Date: Thu, 17 May 2007 21:35:43 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
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> <464C8822.7020503@dcrocker.net> <tsl4pmbrw0z.fsf@mit.edu> <464CC8D3.2000700@dcrocker.net> <tslejlfnnef.fsf@mit.edu>
In-Reply-To: <tslejlfnnef.fsf@mit.edu>
X-Enigmail-Version: 0.95.0
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ietf-dkim@mipassoc.org, Apps Discuss <discuss@apps.ietf.org>, IETF General Discussion Mailing List <ietf@ietf.org>, dcrocker@bbiw.net, Paul Overell <paul.overell@thus.net>
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

it could be argued that the best thing to do is to remove ALL of the
rules from the ABNF spec, leaving only the language definition and
examples.  (actually I think I did argue this sometime around 1996, but
I'm too lazy to search through old email to find it.  I'm actually
surprised that a problem with one of those definitions has taken this
long to crop up.)

the rules could then be moved to a separate document, probably with
status informational.   I don't personally see any  problem with an
informational document being used to define terms that are referenced in
standards track publications - so long as the document being referenced
is not subject to change.    the referencing document should be
evaluated as if the definitions were incorporated into that document.

IMHO, sometimes we try too hard to make things fit into the standards track.

application of the proposed/draft/full criteria to ABNF has always been
a bit odd, because ABNF defines a notation rather than a protocol.  at
one time we thought about evaluating interoperability of ABNF by seeing
if there were multiple implementations (i.e. parser generators) that
when given the same grammar, recognized the same language.  but this
would be kind of meaningless given that ABNF is (in my experience)
almost never used as input to a parser generator for the purpose of
generating a protocol implementation.  which might be quite unfortunate.
> I think redefining the rule would require recycling at proposed.  I
> think it would be confusing and harmful to do so.
>
> I think removing the rule would is allowed by the process (and would
> require updates in referencing specs as they advance but would not
> break anything).  I think doing so would be harmful and is not
> supported by consensus.
>
> I do not object to deprecating the rule although I'm not completely
> convinced doing so is a great idea.I think it is clearly allowed if
> there is consensus.
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>