RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Ned Freed <ned.freed@mrochek.com> Tue, 11 September 2007 19:30 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 1IVBRG-0003aS-Ur; Tue, 11 Sep 2007 15:30:22 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBRF-0003Wo-4C for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:30:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBRE-0003UJ-PW for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400
Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBRC-0004tA-33 for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8DYK2FIO00ALEH@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:15 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8D10E8SW003GRV@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:03 -0700 (PDT)
Message-id: <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
Date: Tue, 11 Sep 2007 12:04:01 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
In-reply-to: "Your message dated Tue, 11 Sep 2007 12:19:22 +0100" <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
MIME-version: 1.0
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>
To: Debbie Garside <debbie@ictmarketing.co.uk>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189539014; h=Date: From:Subject:MIME-version; b=Av7JmOtySlE3J9Cj6co1PPja1BeWUc1HXfz+gs 30B25RyRjKJdF+kLMhGUCLifVKQanIFTMUn5lO3mQRmM+dsQ==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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, 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
> > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, > > `it means just what I choose it to mean -- neither more nor less.' > 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. We don't need any more, and when such sections are always present but usually say "no such and such are present" they aren't helping. The last time this came up in the context of IANA considerations it was asserted that having such sections act as a useful check to make sure there are no needed definitions or considerations. The problem is people don't work this way. If the section is mandatory they'll add it when the document is first created. Sometimes they'll remember to keep it up to date and sometimes they won't. But when someone reviews the document they'll see that section and assume its presence means whatever has been checked. So the mandatory section approach can actually result in more errors and omissions, not less. It took me only a few minutes the last time we had one of these discussions to find a documentt (in the RFE Editor's queue, as I recall) where this had happened: A "there are no IANA considerations" section had been added early on but when the document acquired IANA considerations it wasn't updated. And nobody who reviewed the document caught it. Ned P.S. I've read a lot of ISO and CCITT specifications and I have found their terms and definitions material to be fairly hit or miss in terms of utility.
- Next step on web phishing draft (draft-hartman-we… Alexey Melnikov
- Re: [Ietf-http-auth] Next step on web phishing dr… Alexey Melnikov
- Re: [saag] Next step on web phishing draft (draft… der Mouse
- Re: [Ietf-http-auth] Next step on web phishing dr… Eric Rescorla
- Re: Next step on web phishing draft (draft-hartma… Bill Manning
- RE: Next step on web phishing draft(draft-hartman… Hallam-Baker, Phillip
- Re: Next step on web phishing draft (draft-hartma… Iljitsch van Beijnum
- Re: Next step on web phishing draft (draft-hartma… Iljitsch van Beijnum
- Re: [saag] Next step on web phishing draft(draft-… tom.petch
- RE: [Ietf-http-auth] Next step on web phishing dr… Paul Leach
- Re: [saag] [Ietf-http-auth] Next step on web phis… Jeffrey Hutzelman
- RE: Next step on web phishing draft(draft-hartman… Debbie Garside
- RE: Next step on web phishing draft(draft-hartman… Ned Freed
- Re: Next step on web phishing draft(draft-hartman… Keith Moore
- Re: Next step on web phishing draft(draft-hartman… Keith Moore
- RE: Next step on web phishingdraft(draft-hartman-… Debbie Garside
- Re: Next step on web phishingdraft(draft-hartman-… Keith Moore
- Re: [saag] [Ietf-http-auth] Next step on web phis… Shumon Huque
- Required doc sections (Re: [saag] Next step on we… Nicolas Williams