W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

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

From: Debbie Garside <debbie@ictmarketing.co.uk>
Date: Tue, 11 Sep 2007 21:56:49 +0100
To: <ned.freed@mrochek.com>, "'Keith Moore'" <moore@cs.utk.edu>
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>
Message-ID: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110>

 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
Received on Tuesday, 11 September 2007 20:57:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC