Re: #1031 backward compatibility and handling incompatibilities
Richard Clayton <richard@highwayman.com> Sun, 12 June 2005 11:57 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29276 for <usefor-archive@lists.ietf.org>; Sun, 12 Jun 2005 07:57:23 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5CBsI2q052671 for <ietf-usefor-skb@above.proper.com>; Sun, 12 Jun 2005 04:54:18 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5CBsIv2052670 for ietf-usefor-skb; Sun, 12 Jun 2005 04:54:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f
Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5CBsGwa052651 for <ietf-usefor@imc.org>; Sun, 12 Jun 2005 04:54:17 -0700 (PDT) (envelope-from richard@highwayman.com)
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1DhR2d-000D1w-KP for ietf-usefor@imc.org; Sun, 12 Jun 2005 11:54:15 +0000
Message-ID: <6Eg937ACICrCFA8H@highwayman.com>
Date: Sun, 12 Jun 2005 12:52:34 +0100
To: ietf-usefor@imc.org
From: Richard Clayton <richard@highwayman.com>
Subject: Re: #1031 backward compatibility and handling incompatibilities
References: <Pine.BSI.3.91.1050609114753.10996C-100000@spsystems.net> <IHvsE0.Mpx@clerew.man.ac.uk>
In-Reply-To: <IHvsE0.Mpx@clerew.man.ac.uk>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.02 M <Hm3$+Pcr77fJAOKLReX+dOUPoc>
Sender: owner-ietf-usefor@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <IHvsE0.Mpx@clerew.man.ac.uk>, Charles Lindsey <chl@clerew.man.ac.uk> writes >I think he is upset because we use the term "header" rather than "header >field" and "header name" rather than "field name". > >I would point out that our drafts have always used this terminology (and >have carefully documented that usage). Although I have sympathy for the view that this is continuing the tradition of how "news" documentation is written, I think that's a mistake :( Considerable leverage is gained by defining "news" as a special case of "mail" (albeit, I sometimes wonder if -- when the minutiae is debated at such length -- the gain is entirely worth the pain). Whilst we continue down that path then it behoves us to use the jargon from "mail" in a consistent and user-friendly manner. Although there may be mileage in saying "In this standard we use frooble to mean 'some very long phrase that is hard to keep repeating'" I don't think that it does anything other than create confusion to use a substitute for quite short phrases AND what's more, to use a word "header" that so closely resembles what is being substituted. As a data point, I'm currently in the process of finally editing my PhD thesis (yes, they let you do PhDs even at my advanced age!) and realised that I'd been very sloppy with my own use of the word "header". It took less than an hour to work through the document and fix every mention to the correct 2822 jargon. I really do not think that it reads any worse now that I've done it, nor is it harder to understand for a neophyte. >RFC 1036 used the term "header" (though not consistently, since it >sometimes used "header line" - a quick look revealed no occurrence of >"field", though I have not grepped to confirm it). > >Son-of-1036 used the term "header". > >The NNTP draft, which has just completed its IETF Last Call period, uses the >term "header". of these three points, this is the _only_ one that would concern me (we are, I trust, hoping to reach a situation where only historians consult the other two documents, so who cares what they say?) ... so I checked the documents recently exiting last call, which appear to be: http://www.ietf.org/internet-drafts/draft-ietf-nntpext-authinfo-09.txt which contains the single phrase "This may be accomplished, for example, by inserting headers in the posted articles ..." ie: trivial change to "header fields" http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-06.txt which doesn't contain "header" at all http://www.ietf.org/internet-drafts/draft-ietf-nntpext-streaming-05.txt this uses "headers" twice, both of which can easily be changed to "header fields" http://www.ietf.org/internet-drafts/draft-ietf-nntpext-base-27.txt this uses "header" extensively in 3.6 (relating to folding) and would require a moderate amount of work :-( though in my view that work is mechanical and should not give rise to debate. >I move that we make no change to this long established practice. You can argue that both alternatives are "long established". The question is what is best going forward. And there the choice appears to be between creating significant consistency in the set of documents that future implementors consult; and in doing some mechanical editing to documents that are not yet set in stone (albeit some are already a long way towards that state). If we are still allowed to disrupt the smooth progress of the NNTP documents then, in my view, that is what we should do. - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBQqwiApoAxkTY1oPiEQJxlQCfYW+ouK3qXbqBNaJ6W/UB3EyMh0MAoPyW DEoNgSw/OtsbLPyaPg3MUeHZ =hUEZ -----END PGP SIGNATURE-----
- Re: #1022 Summary: Should dot be permitted in phr… Bruce Lilly
- #1022 Summary: Should dot be permitted in phrases? Harald Tveit Alvestrand
- Re: #1022 Summary: Should dot be permitted in phr… Russ Allbery
- Re: #1022 Summary: Should dot be permitted in phr… Harald Tveit Alvestrand
- Re: #1022 Summary: Should dot be permitted in phr… Bruce Lilly
- Re: #1022 Summary: Should dot be permitted in phr… Harald Tveit Alvestrand
- standard terminology and text (was #1022 Summary:… Bruce Lilly
- backward compatibility and handling incompatibili… Bruce Lilly
- Re: #1022 Summary: Should dot be permitted in phr… Bruce Lilly
- Re: backward compatibility and handling incompati… Henry Spencer
- documenting new fields (was #1022 Summary: Should… Bruce Lilly
- Re: standard terminology and text (was #1022 Summ… Forrest J. Cavalier III
- Re: backward compatibility and handling incompati… Forrest J. Cavalier III
- Re: documenting new fields (was #1022 Summary: Sh… Forrest J. Cavalier III
- #1030 Re: backward compatibility and handling inc… Harald Tveit Alvestrand
- #1031 Re: standard terminology and text (was #102… Harald Tveit Alvestrand
- #1032 documenting new fields (was #1022 Summary: … Harald Tveit Alvestrand
- Re: #1031 Re: standard terminology and text (was … Forrest J. Cavalier III
- Re: #1022 Summary: Should dot be permitted in phr… Charles Lindsey
- Re: #1031 Re: standard terminology and text Russ Allbery
- Re: #1022 Summary: Should dot be permitted in phr… Harald Tveit Alvestrand
- LTRU questions (was: #1022 Summary: Should dot be… Frank Ellermann
- Re: #1031 Re: standard terminology and text (was … Harald Tveit Alvestrand
- Re: #1031 Re: standard terminology and text (was … Bruce Lilly
- Admin: Please watch your language Harald Tveit Alvestrand
- Re: #1031 Re: standard terminology and text (was … Forrest J. Cavalier III
- Re: Admin: Please watch your language Forrest J. Cavalier III
- Re: #1031 Re: standard terminology and text Harald Tveit Alvestrand
- Re: #1022 Summary: Should dot be permitted in phr… Charles Lindsey
- Re: #1022 Summary: Should dot be permitted in phr… Forrest J. Cavalier III
- Re: #1031 Re: standard terminology and text Henry Spencer
- Re: #1031 Re: standard terminology and text Forrest J. Cavalier III
- Re: #1031 Re: standard terminology and text Frank Ellermann
- Re: #1031 backward compatibility and handling inc… Charles Lindsey
- Re: #1022 Summary: Should dot be permitted in phr… Charles Lindsey
- Re: Admin: Please watch your language Eivind Tagseth
- Re: #1022 Summary: Should dot be permitted in phr… Harald Tveit Alvestrand
- Re: #1022 Summary: Should dot be permitted in phr… Russ Allbery
- Re: #1022 Summary: Should dot be permitted in phr… Forrest J. Cavalier III
- Re: #1030 Re: backward compatibility and handling… Charles Lindsey
- Re: #1031 Re: standard terminology and text Bruce Lilly
- Re: #1031 Re: standard terminology and text Bruce Lilly
- Re: #1031 backward compatibility and handling inc… Bruce Lilly
- Re: #1031 Re: standard terminology and text Henry Spencer
- Re: #1031 Re: standard terminology and text Frank Ellermann
- Re: #1031 Re: standard terminology and text Frank Ellermann
- Re: #1031 backward compatibility and handling inc… Richard Clayton
- Re: #1031 backward compatibility and handling inc… Frank Ellermann
- Re: #1031 Re: standard terminology and text Charles Lindsey
- Re: #1031 Re: standard terminology and text Charles Lindsey
- Re: #1031 Re: standard terminology and text Harald Tveit Alvestrand
- Re: Admin: Please watch your language Bruce Lilly
- [off list] Re: Admin: Please watch your language Frank Ellermann
- OT Frank Ellermann
- Re: Admin: Please watch your language Bruce Lilly
- Re: Admin: Please watch your language Russ Allbery
- NEW USEPRO 7.9 gateway (was: LTRU questions) Frank Ellermann
- Re: NEW USEPRO 7.9 gateway (was: LTRU questions) Charles Lindsey