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(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: 11 September 2007 21:27
To: Keith Moore
Cc: Ned Freed; Debbie Garside; ietf(_at_)ietf(_dot_)org;
discuss(_at_)apps(_dot_)ietf(_dot_)org; 'Iljitsch van Beijnum';
ietf-http-wg(_at_)w3(_dot_)org; bmanning(_at_)ISI(_dot_)EDU;
saag(_at_)mit(_dot_)edu;
ietf-http-auth(_at_)osafoundation(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf