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
>
>
>