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

Sam Hartman <hartmans-ietf@mit.edu> 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-0005iZ-HR; Thu, 17 May 2007 17:16:37 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Holhu-0002q2-Ha for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:32:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holhu-0002pq-7g for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:14 -0400
Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Holhr-00088m-V5 for discuss@apps.ietf.org; Thu, 17 May 2007 15:32:14 -0400
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CF14400F; Thu, 17 May 2007 15:32:11 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: John C Klensin <john-ietf@jck.com>
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> <E09D6916A9D19A52976E4567@p3.JCK.COM>
Date: Thu, 17 May 2007 15:32:11 -0400
In-Reply-To: <E09D6916A9D19A52976E4567@p3.JCK.COM> (John C. Klensin's message of "Thu, 17 May 2007 13:35:31 -0400")
Message-ID: <tsl7ir7utz8.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Approved-At: Thu, 17 May 2007 17:16:34 -0400
Cc: ietf-dkim@mipassoc.org, Apps Discuss <discuss@apps.ietf.org>, Harald Alvestrand <harald@alvestrand.no>, Dave Crocker <dcrocker@bbiw.net>, Paul Overell <paul.overell@thus.net>, IETF General Discussion Mailing List <ietf@ietf.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" == John C Klensin <john-ietf@jck.com> writes:

    John> If we are going to standardize a definitional requirement or
    John> method -- whether it is ABNF or IPR boilerplate or something
    John> -- we need to get it right as a self-contained definition
    John> and then live with it.  We should certainly revise and
    John> replace it if it turns out to be unworkable (as has happened
    John> with IPR work) or if the definition turns out to be
    John> inadequate to permit an unambiguous interpretation (that
    John> issue spills over into my second observation, below).  But,
    John> once other specifications start to depend on the definitions
    John> that are there, and show those definitions to be adequate,
    John> we should not be talking about deprecating definitions
    John> unless we are prepared to "that was wrong, we need to start
    John> over (even though some of the older material may still be
    John> useful)".  Again, please note the similarity to the IPR
    John> work.

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.

Clearly we should not invalidate existing uses of that term.  Clearly
we do need a definition for the term: it is being used usefully.

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.

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.