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

Dave Crocker <dhc2@dcrocker.net> Thu, 17 May 2007 21:28 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 1HonW3-0006bN-5w; Thu, 17 May 2007 17:28:07 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HonW1-0006bD-Og for discuss-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 17:28:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonW1-0006b5-F4 for discuss@apps.ietf.org; Thu, 17 May 2007 17:28:05 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HonVy-0000v1-TA for discuss@apps.ietf.org; Thu, 17 May 2007 17:28:05 -0400
Received: from [10.200.96.163] ([216.168.240.140]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4HLRpCH013775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2007 14:27:52 -0700
Message-ID: <464CC8D3.2000700@dcrocker.net>
Date: Thu, 17 May 2007 14:27:47 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.0 (Windows/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>
In-Reply-To: <tsl4pmbrw0z.fsf@mit.edu>
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: a7d6aff76b15f3f56fcb94490e1052e4
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


Sam Hartman wrote:
>     >> Ultimately cases like this should be evaluated based on whether
>     >> the final result is more clear overall.
> 
>     Dave> What about protecting the installed base for the existing
>     Dave> spec?
> 
> I think that is not a useful criteria when we are talking about an
> informative note.  I think that criteria matters somewhat more when we
> are talking about depricating a feature but retaining it, although
> even then I think the bar would be reasonably low.  The installed base
> will continue to work.


I think you are assuming a more constrained discussion than what I've been 
seeing on this thread.  The thread has discussed everything from removing the 
rule, to redefining it, to declaring it "deprecated", to adding some 
commentary text.

It appears you are only talking about the last, although I for one missed 
that. (For reference, when I said "change the specification" I mean normative 
change.)

Although I've seen some postings against even having a comment added to the 
text, my own reading of the postings is that there is a reasonable consensus 
that it would be ok.

My own view is that comments can be helpful and are, at worst, typically 
rather benign. Indeed, the IETF approach towards specification writing is 
rather friendly towards including whatever comments folk feel might be 
helpful, modulo the obvious danger that too many comments can wind up 
obscuring a document.  (And, no, I do not think that that is a danger here.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net