Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

Keith Moore <moore@cs.utk.edu> Tue, 11 September 2007 20:11 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 1IVC57-0006dL-Ef; Tue, 11 Sep 2007 16:11:33 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVC53-0006Yd-35 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:11:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC51-0006Vn-QR for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:11:28 -0400
Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVC50-0005h6-Jl for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:11:27 -0400
Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id DA83E1035D0; Tue, 11 Sep 2007 16:11:24 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEkug96Ucdqd; Tue, 11 Sep 2007 16:11:22 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 858511034D9; Tue, 11 Sep 2007 16:11:06 -0400 (EDT)
Message-ID: <46E6F657.4040204@cs.utk.edu>
Date: Tue, 11 Sep 2007 16:11:03 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
In-Reply-To: <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
X-Enigmail-Version: 0.95.3
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' <iljitsch@muada.com>, ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside <debbie@ictmarketing.co.uk>, ietf-http-auth@osafoundation.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

>> There has been a discussion recently on LTRU as to whether a Terms and
>> Definitions section should be introduced within RFCs - much like those
>> within ISO Standards.
>>     
>
> And my response to this suggestion is the same as it was for the "IANA
> considerations" or "Internationalization considerations" section suggestions:
> By all means have a "terms and definitions" section or whatever in the document
> if there's a need for one, but don't make having one mandatory in all
> documents.
>
> We already have more than enough useless (from a technical content
> perspective) boilerplate in our documents. 
+1

Actually I don't have so much of a problem with having such sections in
drafts at review time, but I hate to see them clutter up published
RFCs.    There are a lot of times when these sections aren't applicable,
and having them in the final document just interferes with readability. 

I also think that a Terms and Definitions section might encourage
document authors to make up new terms when they're not necessary, which
would also interfere with readability.  (geeks love to create new language.)