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

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

From: Ned Freed <ned.freed@mrochek.com>
Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, Debbie Garside <debbie@ictmarketing.co.uk>, 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: <01ML8GHD48YO00005F@mauve.mrochek.com>
To: Keith Moore <moore@cs.utk.edu>

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

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.

Received on Tuesday, 11 September 2007 20:42:07 UTC

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