RE: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt)
"Debbie Garside" <debbie@ictmarketing.co.uk> Tue, 11 September 2007 20:57 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 1IVCnY-0002Ki-VC; Tue, 11 Sep 2007 16:57:28 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCnX-0002Iq-8F for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:57:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCnW-0002IF-T9 for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:57:26 -0400
Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCnV-00078r-F0 for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:57:26 -0400
Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007214839.msg for <discuss@apps.ietf.org>; Tue, 11 Sep 2007 22:00:07 +0100
Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 11 Sep 2007 21:57:17 +0100
From: Debbie Garside <debbie@ictmarketing.co.uk>
To: ned.freed@mrochek.com, 'Keith Moore' <moore@cs.utk.edu>
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> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com>
Subject: RE: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 21:56:49 +0100
Message-ID: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110>
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Thread-Index: Acf0tHbuUjgnFndgS1K93T2ZSOfPrwAASNWw
X-Spam-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:07 +0100 (not processed: message from valid local sender)
X-MDRemoteIP: 62.197.41.145
X-Return-Path: prvs=177446d652=debbie@ictmarketing.co.uk
X-Envelope-From: debbie@ictmarketing.co.uk
X-MDaemon-Deliver-To: discuss@apps.ietf.org
X-MDAV-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:08 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
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
Reply-To: debbie@ictmarketing.co.uk
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
Ned wrote: > Very good point. Having lots of slightly varying definitions > of various terms could be hugely harmful. I agree. Which is why a Terms and Definitions section is darn useful as is an overall Term Bank. However, I will not labour the point as I have long ago found that trying to sell Terminology standardization to industry is practically impossible - unless you rename it as Knowledge Management. Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled egg and I, in interpreting your request, presented you with scrambled egg... You may be somewhat disappointed at breakfast! ;-) Best regards Debbie Garside > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: 11 September 2007 21:27 > To: Keith Moore > Cc: Ned Freed; Debbie Garside; ietf@ietf.org; > discuss@apps.ietf.org; 'Iljitsch van Beijnum'; > ietf-http-wg@w3.org; bmanning@ISI.EDU; saag@mit.edu; > ietf-http-auth@osafoundation.org > Subject: Re: Next step on web > phishingdraft(draft-hartman-webauth-phishing-05.txt) > > > > >> 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. > > My position is the exact opposite. Full and complete review > of drafts it of paramount importance and anything thqt > interferes with that is unacceptable. > And as I have pointed out, we have "running code" > demonstrating that these things are at best distracting and > at worst actively interfere with proper review. > > What's appropriate to appear in the final RFC is up to the > RFC Editor. That's what the word "editor" implies. If the RFC > Editor deems it appropriate to remove null sections that's > fine, if they feel they should be retained that's fine too. > Someone reading an RFC to learn how to implement something > has a definite goal in mind and isn't going to be (or at > least shouldn't be) distracted by boilerplate in the same way > a reviewer looking for issues - a far more nebulous > proposition - can be. > > > There are a lot of times when these sections aren't applicable, and > > having them in the final document just interferes with readability. > > It depends on what sort of reading you're doing. > > > 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.) > > Very good point. Having lots of slightly varying definitions > of various terms could be hugely harmful. > > RFC 2119 is a case in point. While I have some small issues > with how RFC 2119 defines its terms, I've come to realize > that having consistent meanings for these terms is far more important. > > Ned > > >
- 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