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

"todd glassey" <> Thu, 17 May 2007 21:16 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HonKv-0005hV-A4; Thu, 17 May 2007 17:16:37 -0400
Received: from discuss by with local (Exim 4.43) id 1Hojyv-0004uo-OZ for; Thu, 17 May 2007 13:41:41 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Hojyv-0004ue-Ep for; Thu, 17 May 2007 13:41:41 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Hojyu-0003cm-4G for; Thu, 17 May 2007 13:41:41 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; 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 [] (helo=gw) by with asmtp (Exim 4.34) id 1Hojyp-0000Cg-8q; Thu, 17 May 2007 13:41:35 -0400
Message-ID: <004401c798aa$a08e6fa0$>
From: "todd glassey" <>
To: "John C Klensin" <>, "Sam Hartman" <>
References: <><><><><> <1504A69099CF1B62F66FE576@p3.JCK.COM><> <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-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 <>, 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: <>, <>

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


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


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


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


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