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@xxxxxxxxxxx] > Sent: 11 September 2007 21:27 > To: Keith Moore > Cc: Ned Freed; Debbie Garside; ietf@xxxxxxxx; > discuss@xxxxxxxxxxxxx; 'Iljitsch van Beijnum'; > ietf-http-wg@xxxxxx; bmanning@xxxxxxx; saag@xxxxxxx; > ietf-http-auth@xxxxxxxxxxxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf