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

"todd glassey" <tglassey@earthlink.net> Thu, 17 May 2007 21:16 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 1HonKv-0005hV-A4; Thu, 17 May 2007 17:16:37 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hojyv-0004uo-OZ for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:41:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hojyv-0004ue-Ep for discuss@apps.ietf.org; Thu, 17 May 2007 13:41:41 -0400
Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hojyu-0003cm-4G for discuss@apps.ietf.org; Thu, 17 May 2007 13:41:41 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HZJdGaCyeVdmVtair3LEvSmj7Krt2gyO51X7/nVkEcwEM8IvWe/DYwwniP4y0Xgx; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Hojyp-0000Cg-8q; Thu, 17 May 2007 13:41:35 -0400
Message-ID: <004401c798aa$a08e6fa0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "John C Klensin" <john-ietf@jck.com>, "Sam Hartman" <hartmans-ietf@mit.edu>
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> <E09D6916A9D19A52976E4567@p3.JCK.COM>
Subject: Re: [ietf-dkim] Re: Use of LWSP in ABNF -- consensus call
Date: Thu, 17 May 2007 10:41:37 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796f43bd5d69a97acc7cf0b054c683efad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400
Cc: IETF General Discussion Mailing List <ietf@ietf.org>, Harald Alvestrand <harald@alvestrand.no>, Apps Discuss <discuss@apps.ietf.org>, Dave Crocker <dcrocker@bbiw.net>, Paul Overell <paul.overell@thus.net>, ietf-dkim@mipassoc.org
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

John - I would call this post of yours "Nothing but net" ... more commentary 
inline below.

T.

>
> Sam,
>
> Two observations; I hope you don't think they are contradictory.
>
> (1) We regularly get ourselves into intellectual and procedural
> difficulties by treating specifications about how protocol
> specifications are written as if they were protocol
> specifications.

WOW - talk about being 'right on the money'!

> When we try to avoid that, we get ourselves
> into worse problems.  Using rules that are more or less
> arbitrary,

And this is the operable term here, that being 'arbitrary'

> we make some of these documents Proposed Standards
> and then try to progress them, we make others into BCPs and,
> now, we make still others into IONs.

AMEN!

>
> If we are going to standardize a definitional requirement or
> method -- whether it is ABNF or IPR boilerplate or something --
> we need to get it right as a self-contained definition and then
> live with it.

RIGHT!

> We should certainly revise and replace it if it
> turns out to be unworkable (as has happened with IPR work) or if
> the definition turns out to be inadequate to permit an
> unambiguous interpretation (that issue spills over into my
> second observation, below)

Or its also brought to our attention that law and process is being violated 
by our methods per those works

> .  But, once other specifications
> start to depend on the definitions that are there, and show
> those definitions to be adequate, we should not be talking about
> deprecating definitions unless we are prepared to "that was
> wrong, we need to start over (even though some of the older
> material may still be useful)".    Again, please note the
> similarity to the IPR work.

AMEN!

>
> (2) If we pretend that the ABNF metalanguage and definitions are
> actually a protocol specification, then we need to evaluate it
> as one.  Then, we have the following criteria (which we usually
> don't state quite this precisely):
>
> (i) Is the definition good enough that interoperable
> implementations are possible?
>
> (ii) Do people care enough about the construct to
> actually use it in ways that show it is useful?
>
> Now, neither of those rules prevents non-conforming
> "implementations".  We may notice that those exist, but our
> concern is only about implementations that appear to conform to
> the spec and are (or are not) interoperable.  If non-conforming
> implementations happen by accident because the text isn't clear
> enough, we try to clarify the text.   But we don't say "well,
> there are non-conforming implementations, so the spec is
> broken".   That would make no sense at all, at least to me.
>
> The answer to (i) appears to be "yes".  There are lots of
> conforming cases.  And the answer to (ii) is, as Dave as pointed
> out repeatedly, "about 30 years worth".
>
> Is this construction dangerous if used in inappropriate
> contexts?  Sure.  Does that justify a warning note to the
> unwary?  Probably.  Is it possible to implement other things and
> call them by the same name (i.e., create a non-conforming
> implementation)?  Of course.  Should that invalidate the
> definition?  Not if we want to have anything left if the
> principle were applied broadly.
>
>     john
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf