Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
Mark Crispin <MRC@Washington.EDU> Tue, 08 April 2008 17:53 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38HrnYI055880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 10:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38HrnOM055879; Tue, 8 Apr 2008 10:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38HreCn055862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-imapext@imc.org>; Tue, 8 Apr 2008 10:53:41 -0700 (MST) (envelope-from MRC@Washington.EDU)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m38HrcoI007251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2008 10:53:39 -0700
X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m38HrajX022212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Apr 2008 10:53:38 -0700
Date: Tue, 08 Apr 2008 10:53:14 -0700
From: Mark Crispin <MRC@Washington.EDU>
To: Russ Housley <housley@vigilsec.com>
cc: Bob Braden <braden@ISI.EDU>, ietf-imapext@imc.org, iab@iab.org, imapext-chairs@tools.ietf.org, rfc-editor@rfc-editor.org
Subject: Re: Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS' to Proposed Standard
In-Reply-To: <200804081502.m38F2cgx039326@balder-227.proper.com>
Message-ID: <alpine.WNT.1.10.0804081036510.5756@Tomobiki-Cho.CAC.Washignton.EDU>
References: <200804071739.KAA01643@gra.isi.edu> <200804081502.m38F2cgx039326@balder-227.proper.com>
User-Agent: Alpine 1.10 (WNT 1024 2008-04-07)
Organization: UW Technology
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.8.104239
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>
Bob: As the author in question, I assert that nobody EVER stated the existence of any such "norm" to me. I indeed copied RFC 822's form in the earliest IMAP RFC and retained it. In reviewing the titles of the RFCs that I have written I see no consistent application of case. Some are all-upper, others are title. The all-upper ones apparently began with a stripped down form of the IMAP RFC used as a template. Not only don't I care what case is used, I assert that the application of a standardized case for RFC titles is an RFC Editor function, *IF* there is such a standard. Is there? If not, why not? The matter is not worth raising with ietf-imapext, iab, or imapext-chairs. It may be worth raising with rfc-editor. Last, and certainly least: as someone who was frequently stuck behind a Model 33 or 35 Teletype prior to 1977, and in later years used early personal computers with no lowercase capability, I object to the comment about "network-illiterate Big Iron users". Some people who sent all-caps messages had no choice. On Tue, 8 Apr 2008, Russ Housley wrote: > > Bob: > > I am not pushing for one or the other for this document. I'm simply pointing > out that the authors used the same title case as the document that is being > updated. > > Russ > > At 01:39 PM 4/7/2008, Bob Braden wrote: > > >> *> >> *> See RFC 3501 >> *> >> >> Russ, >> >> I am trying to figure out whether you are serious. Of course, there >> have been individual failures in the past. In fact, 821 or 822 (I foreget >> which) was a title-case failure. But the existence of an occasional >> error does not seem to justify deliberately doing it wrong in the >> future. (I will have to admit to a certain bias... upper-cased >> titles remind me of the days when network-illiterate Big Iron >> users would sometimes send all-caps messages to the Internet.) It >> is generally agreed, I believe, that some reasonable uniformity of >> style is desirable in the RFC series. And the title appears in the >> index and a dumb-looking title stands out as a wierdness. >> >> Bob Braden >> >> *> At 05:27 PM 4/3/2008, Bob Braden wrote: >> *> >> *> >> *> > *> The IESG has approved the following document: >> *> > *> >> *> > *> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD >> EXTENSIONS ' >> *> > *> <draft-ietf-imapext-sort-20.txt> as a Proposed Standard >> *> > *> >> *> > >> *> >Why is this document shouting at us? Title case is the norm for >> *> >RFCs. >> *> > >> *> >RFC Editor/bb >> *> > >> *> > *> Two simple/optional improvements: >> *> > *> Add a normative reference to STD 63 (RFC3629) for UTF-8. >> *> > *> Instead of allowing any 8-bit in BLOBCHAR and NONWSP, >> *> > reference the rules >> *> > *> in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4). >> *> > *> >> *> > > -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
- Re: Protocol Action: 'INTERNET MESSAGE ACCESS PRO… Russ Housley
- Re: Protocol Action: 'INTERNET MESSAGE ACCESS PRO… Mark Crispin
- Re: Protocol Action: 'INTERNET MESSAGE ACCESS PRO… Alexey Melnikov
- Re: Protocol Action: 'INTERNET MESSAGE ACCESS PRO… Mark Crispin
- Re: Protocol Action: 'INTERNET MESSAGE ACCESS PRO… Russ Housley
- Protocol Action: 'INTERNET MESSAGE ACCESS PROTOCO… The IESG