From falk@ISI.EDU Wed Jan 21 16:51:46 2004 Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0M0pkD14720 for ; Wed, 21 Jan 2004 16:51:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <286DD361-4C75-11D8-B67F-000A95DBDB84@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: rfc-interest@rfc-editor.org From: Aaron Falk Date: Wed, 21 Jan 2004 16:51:48 -0800 X-Mailer: Apple Mail (2.609) Subject: [rfc-i] testing Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: testing From falk@ISI.EDU Wed Jan 21 17:19:33 2004 Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i0M1JXD13443 for ; Wed, 21 Jan 2004 17:19:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <0A52DC78-4C79-11D8-B67F-000A95DBDB84@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: rfc-interest@rfc-editor.org From: Aaron Falk Date: Wed, 21 Jan 2004 17:19:35 -0800 X-Mailer: Apple Mail (2.609) Subject: [rfc-i] up & running... Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: The rfc-interest list appears to be functional. --aaron From jkrey@ISI.EDU Fri Feb 6 11:48:00 2004 Received: from akamai.isi.edu (akamai.isi.edu [128.9.160.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i16Jlxv23961; Fri, 6 Feb 2004 11:47:59 -0800 (PST) Message-Id: <200402061947.i16Jlxv23961@boreas.isi.edu> Date: Fri, 6 Feb 2004 11:47:59 -0800 (PST) From: Joyce Reynolds Reply-To: Joyce Reynolds To: rfc-interest@rfc-editor.org Cc: rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ariy12oH2uXTt1guo6qgBA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [rfc-i] RFC Editor report Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: Greetings. Enclosed is a report on the RFC Editor's recent activities. We will be sending this type of information to this list periodically. Joyce (for RFC Editor) =============================================================== - We are preparing a set of RFC Editor rules on how to implement RFCs-to-be: draft-ietf-ipr-submission-rights-08.txt, draft-ietf-ipr-technology-rights-12.txt, and draft-ietf-ipr-wg-guidelines-05.txt. They will be posted on the RFC Editor web site and relayed to the IETF Secretariat so that they may update their website and pertinent files. - The RFC Editor has set up and announced a new mailing list, rfc-interest@rfc-editor.org, as a home for discussions particularly related to the functions and procedures of the RFC Editor. - RFC Editor has been in discussions with the IESG w.r.t. the IESG's role in reviewing RFC Editor documents. It is not an easy topic to resolve. The IESG and RFC Editor will continue to collaborate and continue this thread at the Seoul IETF and at the IESG Retreat at the end of March. - We are processing more documents using XML submissions to generate nroff. - The recent document flood is growing the queue (http://www.rfc-editor.org/queue-stats/). We've increased editor level of effort to respond. - We've added a search function to errata web page (http://www.rfc-editor.org/errata.html). From gih@telstra.net Sun Feb 8 16:13:09 2004 Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i190D8v27111 for ; Sun, 8 Feb 2004 16:13:09 -0800 (PST) Received: from gihz1.telstra.net (rsdhcp4.telstra.net [203.50.0.196]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i190CDuY001546; Mon, 9 Feb 2004 11:12:16 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040209110901.01bea938@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 09 Feb 2004 11:12:06 +1100 To: Kireeti Kompella , Basavaraj.Patil@nokia.com From: Geoff Huston Cc: wgchairs@ietf.org, rfc-interest@rfc-editor.org In-Reply-To: <20040206145020.Q31943@kummer.juniper.net> References: <697DAA22C5004B4596E033803A7CEF44013EFC4A@daebe007.americas.nokia.com> <20040206145020.Q31943@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rfc-i] Re: Archives of WGs that are no longer active Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: yep - rfc-index.xml would be a good place to see this information e.g.: foo individual Submission Geoff At 09:52 AM 7/02/2004, Kireeti Kompella wrote: > > More specifically does anyone know what WG produced RFC2396 > > (Uniform Resource Identifiers (URI): Generic Syntax) > >Wouldn't it be nice if every RFC that was the product of a WG simply >said so? > >Kireeti. >------- From jkrey@ISI.EDU Wed Feb 11 13:41:55 2004 Received: from akamai.isi.edu (akamai.isi.edu [128.9.160.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i1BLfsv13543 for ; Wed, 11 Feb 2004 13:41:54 -0800 (PST) Message-Id: <200402112141.i1BLfsv13543@boreas.isi.edu> Date: Wed, 11 Feb 2004 13:41:54 -0800 (PST) From: Joyce Reynolds Reply-To: Joyce Reynolds To: rfc-interest@rfc-editor.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B1031Qr1hfk5i5o7zIRwBg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [rfc-i] Questions about April 1st RFC Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: F.Y.I. ------------- Begin Forwarded Message ------------- Date: Wed, 21 Jan 2004 11:25:32 -0800 From: RFC Editor To: Victoria Fineberg Cc: "Fineberg, Victoria - DISA" , RFC Editor Subject: Re: Questions about April 1st RFC Victoria, The deadline for submitting April 1 RFCs this year (2004) is March 19, 3:00 PST. April 1 RFCs are usually short. There are no size limits, but we prefer to keep it as small and consise as possible, as it is rare that we find an elongated document humorous enough to publish. It is acceptable to publish the document without an affiliation as long as there is some type of contact information present. Please let us know if you have any further questions. Thank you. RFC Editor On Mon, Jan 19, 2004 at 09:22:13AM -0500, Victoria Fineberg wrote: > Dear RFC Editor, > > I am considering submitting a humorous RFC for the > April 1, 2004, publication. > > Please clarify for me the related current practices: > > 1. What is the dead-line for submitting April 1 RFCs? > > 2. Is there a limit on the size of the RFC, i.e., what > is the minimum and/or maximum size you accept? > > 3. If I am unable to clear my proposed RFC with my > current employer (US government), can I publish it > under my name only, without employment affiliation? > > > Thank you very much for your response, > > Victoria > > > > Victoria Fineberg > fineberg@illinoisalumni.org > fineberv@ncr.disa.mil > ------------- End Forwarded Message ------------- From jkrey@ISI.EDU Thu Feb 19 09:05:39 2004 Received: from akamai.isi.edu (akamai.isi.edu [128.9.160.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i1JH5dv16959; Thu, 19 Feb 2004 09:05:39 -0800 (PST) Message-Id: <200402191705.i1JH5dv16959@boreas.isi.edu> Date: Thu, 19 Feb 2004 09:05:39 -0800 (PST) From: Joyce Reynolds Reply-To: Joyce Reynolds To: iab@ietf.org, iesg@ietf.org Cc: rfc-editor@rfc-editor.org, rfc-interest@rfc-editor.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fUs7pX6rLv//d56IcsGfUw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [rfc-i] RFC Copyrights and Disclaimers for IPRs Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: Following the publication of BCP 78 (RFC 3667), BCP 79 (RFC 3668), and RFC 3669 on Feb 18, 2004, the RFC Editor has begun to incorporate into all documents slated for RFC publication the copyright and intellectual property rights statements called for by these documents. We have placed on our web pages the current RFC Editor rules governing RFC copyrights and disclaimers for intellectual property rights, derived from the above IETF documents: http://www.rfc-editor.org/copyright.html Joyce (for RFC Editor) From pekkas@netcore.fi Sat Feb 28 22:47:04 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1T6l3F00930 for ; Sat, 28 Feb 2004 22:47:04 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1T6kQn14163; Sun, 29 Feb 2004 08:46:26 +0200 Date: Sun, 29 Feb 2004 08:46:26 +0200 (EET) From: Pekka Savola To: mpowr@ietf.org cc: rfc-interest@rfc-editor.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rfc-i] Increasing WG chair role in RFC-editor editing process? Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: Hi, This little practicality has hit me as WG chair a couple of times, so.. perhas this is just a matter of RFC editor changing its process, but if not, this should be another tiny improvement in the process. When a document which is product of a WG is being edited by the RFC editor, any questions/issues/etc. are addressed to the document authors and the shepherding AD. My argument is that this list should be the document authors (or editor, whatever's the case), WG chairs, and the shepherding AD. The AD's job would be just to ensure that WG chairs don't get out of hand.. and the final check & balance would be at AUTH48, AD approving that the document hasn't been substantially modified. This kind of slight "power raise" helps in the scenario where the document authors have gone dormant, and are not responding to their mails in {days, weeks, months, never}. Currently either the AD has to take care of these issues, or act as an SMTP relay between the RFC editor and the chairs. Would make sense? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From braden@ISI.EDU Sun Feb 29 12:03:32 2004 Received: (from braden@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i1TK3Wf22360; Sun, 29 Feb 2004 12:03:32 -0800 (PST) Date: Sun, 29 Feb 2004 12:03:32 -0800 (PST) From: Bob Braden Message-Id: <200402292003.i1TK3Wf22360@boreas.isi.edu> To: pekkas@netcore.fi Subject: Re: [rfc-i] Increasing WG chair role in RFC-editor editing process? Cc: rfc-interest@rfc-editor.org X-Sun-Charset: US-ASCII Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: *> *> Hi, *> *> This little practicality has hit me as WG chair a couple of times, *> so.. perhas this is just a matter of RFC editor changing its process, *> but if not, this should be another tiny improvement in the process. *> *> When a document which is product of a WG is being edited by the RFC *> editor, any questions/issues/etc. are addressed to the document *> authors and the shepherding AD. *> *> My argument is that this list should be the document authors (or *> editor, whatever's the case), WG chairs, and the shepherding AD. *> *> The AD's job would be just to ensure that WG chairs don't get out of *> hand.. and the final check & balance would be at AUTH48, AD approving *> that the document hasn't been substantially modified. *> *> This kind of slight "power raise" helps in the scenario where the *> document authors have gone dormant, and are not responding to their *> mails in {days, weeks, months, never}. *> *> Currently either the AD has to take care of these issues, or act as an *> SMTP relay between the RFC editor and the chairs. *> *> Would make sense? *> Pekka, This makes good sense to me, and I believe that the RFC Editor would welcome such a change that improves communication. The cost is a little bit of extra book-keeping. It might be helpful if the IESG included the email addresses of the relevant chairs in their submission message to the RFC Editor. Perhaps we could add the info to our queue entries (but the staff needs a chance to talk this over, probably after IETF.) (We also note that this change, to empower WG chairs in the publication process, is consistent with one of the suggested directions for IETF reorganization.) Thanks for the suggestion. Bob Braden, for the RFC Editor From dmm@1-4-5.net Sun Feb 29 14:13:13 2004 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1TMDDF07583 for ; Sun, 29 Feb 2004 14:13:13 -0800 (PST) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i1TMCe3K002155; Sun, 29 Feb 2004 14:12:40 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i1TMCeAj002154; Sun, 29 Feb 2004 14:12:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 29 Feb 2004 14:12:40 -0800 From: David Meyer To: Pekka Savola Cc: mpowr@ietf.org, rfc-interest@rfc-editor.org Message-ID: <20040229221240.GA2130@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Subject: [rfc-i] Re: [mpowr] Increasing WG chair role in RFC-editor editing process? Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: On Sun, Feb 29, 2004 at 08:46:26AM +0200, Pekka Savola wrote: >> Hi, >> >> This little practicality has hit me as WG chair a couple of times, >> so.. perhas this is just a matter of RFC editor changing its process, >> but if not, this should be another tiny improvement in the process. >> >> When a document which is product of a WG is being edited by the RFC >> editor, any questions/issues/etc. are addressed to the document >> authors and the shepherding AD. >> >> My argument is that this list should be the document authors (or >> editor, whatever's the case), WG chairs, and the shepherding AD. >> >> The AD's job would be just to ensure that WG chairs don't get out of >> hand.. and the final check & balance would be at AUTH48, AD approving >> that the document hasn't been substantially modified. >> >> This kind of slight "power raise" helps in the scenario where the >> document authors have gone dormant, and are not responding to their >> mails in {days, weeks, months, never}. >> >> Currently either the AD has to take care of these issues, or act as an >> SMTP relay between the RFC editor and the chairs. >> >> Would make sense? Pekka, I think this would be a place there there is good "bang for the WG time buck", and fits well in the "Chair as shepherd" framework that is developing. Dave From paul.hoffman@vpnc.org Sun Feb 29 14:30:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1TMUkF08436 for ; Sun, 29 Feb 2004 14:30:46 -0800 (PST) Received: from [172.16.40.255] ([210.93.162.110]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1TMUcIS055113 for ; Sun, 29 Feb 2004 14:30:40 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200402292003.i1TK3Wf22360@boreas.isi.edu> References: <200402292003.i1TK3Wf22360@boreas.isi.edu> Date: Mon, 1 Mar 2004 07:30:37 +0900 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Increasing WG chair role in RFC-editor editing process? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: At 12:03 PM -0800 2/29/04, Bob Braden wrote: >This makes good sense to me, and I believe that the RFC Editor would >welcome such a change that improves communication. The cost is a >little bit of extra book-keeping. It might be helpful if the IESG >included the email addresses of the relevant chairs in their submission >message to the RFC Editor. Perhaps we could add the info to our queue >entries (but the staff needs a chance to talk this over, probably after >IETF.) Given that WG chairs change over time, sometimes while a document is in the RFC Editor's queue, it would probably be better to have the WG name, not the chair's names, attached to the document in the queue. When the RFC Editor makes the message for the (now heavily-misnamed) 48-hour notice, they look up the WG chairs contact info from the IETF pages. --Paul Hoffman, Director --VPN Consortium From housley@vigilsec.com Sun Feb 29 15:24:57 2004 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i1TNOtF03755 for ; Sun, 29 Feb 2004 15:24:57 -0800 (PST) Received: (qmail 20518 invoked by uid 0); 29 Feb 2004 23:21:33 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.228.199) by woodstock.binhost.com with SMTP; 29 Feb 2004 23:21:33 -0000 Message-Id: <5.2.0.9.2.20040229181554.044752d8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 29 Feb 2004 18:18:14 -0500 To: Paul Hoffman / VPNC , rfc-interest@rfc-editor.org From: Russ Housley Subject: Re: [rfc-i] Increasing WG chair role in RFC-editor editing process? In-Reply-To: References: <200402292003.i1TK3Wf22360@boreas.isi.edu> <200402292003.i1TK3Wf22360@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: Maybe we can have the Secretariat make mail lists -chair@ietf.org. That way, the RFC Editor will always be able to send email to the current WG leadership. Russ At 07:30 AM 3/1/2004 +0900, Paul Hoffman / VPNC wrote: >At 12:03 PM -0800 2/29/04, Bob Braden wrote: >>This makes good sense to me, and I believe that the RFC Editor would >>welcome such a change that improves communication. The cost is a >>little bit of extra book-keeping. It might be helpful if the IESG >>included the email addresses of the relevant chairs in their submission >>message to the RFC Editor. Perhaps we could add the info to our queue >>entries (but the staff needs a chance to talk this over, probably after >>IETF.) > >Given that WG chairs change over time, sometimes while a document is in >the RFC Editor's queue, it would probably be better to have the WG name, >not the chair's names, attached to the document in the queue. When the RFC >Editor makes the message for the (now heavily-misnamed) 48-hour notice, >they look up the WG chairs contact info from the IETF pages. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >rfc-interest mailing list >rfc-interest@rfc-editor.org >http://www.rfc-editor.org/mailman/listinfo/rfc-interest > From narten@us.ibm.com Sun Feb 29 16:25:53 2004 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i210PqF05672 for ; Sun, 29 Feb 2004 16:25:52 -0800 (PST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i210PeF4540536; Sun, 29 Feb 2004 19:25:40 -0500 Received: from cichlid.raleigh.ibm.com ([9.49.178.195]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i210Pcr0149410; Sun, 29 Feb 2004 17:25:39 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i210NtB04243; Sun, 29 Feb 2004 19:23:56 -0500 Message-Id: <200403010023.i210NtB04243@cichlid.raleigh.ibm.com> To: Bob Braden cc: rfc-interest@rfc-editor.org Subject: Re: [rfc-i] Increasing WG chair role in RFC-editor editing process? In-Reply-To: Message from braden@ISI.EDU of "Sun, 29 Feb 2004 12:03:32 PST." <200402292003.i1TK3Wf22360@boreas.isi.edu> Date: Sun, 29 Feb 2004 19:23:49 -0500 From: Thomas Narten Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: > *> When a document which is product of a WG is being edited by the RFC > *> editor, any questions/issues/etc. are addressed to the document > *> authors and the shepherding AD. > *> > *> My argument is that this list should be the document authors (or > *> editor, whatever's the case), WG chairs, and the shepherding AD. > This makes good sense to me, and I believe that the RFC Editor would > welcome such a change that improves communication. I thought this was already being done, and I have some mail in my inbox (i.e., from 48 hours notificatoin) that indicates that this is the case. But maybe there is a lack of consistency? Thomas From pekkas@netcore.fi Sun Feb 29 17:44:09 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i211i8F11743 for ; Sun, 29 Feb 2004 17:44:08 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i211hiv25642; Mon, 1 Mar 2004 03:43:48 +0200 Date: Mon, 1 Mar 2004 03:43:40 +0200 (EET) From: Pekka Savola To: Thomas Narten cc: Bob Braden , Subject: Re: [rfc-i] Increasing WG chair role in RFC-editor editing process? In-Reply-To: <200403010023.i210NtB04243@cichlid.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rfc-interest-admin@rfc-editor.org Errors-To: rfc-interest-admin@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for discussion of the RFC series and RFC Editor functions. List-Unsubscribe: , List-Archive: On Sun, 29 Feb 2004, Thomas Narten wrote: > > This makes good sense to me, and I believe that the RFC Editor would > > welcome such a change that improves communication. > > I thought this was already being done, and I have some mail in my > inbox (i.e., from 48 hours notificatoin) that indicates that this is > the case. But maybe there is a lack of consistency? AFAIR, AUTH48 has indeed been copied to WG chairs. I was thinking of the situations, during the process (e.g., asking for clarifications during EDIT or RFC-EDITOR states), where the RFC editor wants to contact the authors. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mrose+internet.ietf.rfc-interest@dbc.mtview.ca.us Thu Mar 18 13:37:22 2004 Received: from drakken.dbc.mtview.ca.us (64-73-228-56.cust.telepacific.net [64.73.228.56]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2ILbHQ05182 for ; Thu, 18 Mar 2004 13:37:17 -0800 (PST) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id i2ILbHI9001949; Thu, 18 Mar 2004 13:37:17 -0800 (PST) Date: Thu, 18 Mar 2004 13:37:17 -0800 From: Marshall Rose To: rfc-interest@rfc-editor.org Message-Id: <20040318133717.72f0bce4.mrose+internet.ietf.rfc-interest@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: mrose+internet.ietf.rfc-interest@dbc.mtview.ca.us Subject: [rfc-i] how to interpret / information X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 21:37:22 -0000 how should the contents of the element be interpreted? in looking at rfc-index.xml, i'm trying to understand what the keywords mean. something like this APPN-MIB is obvious, but what about Border,gateway,protocol,Open,shortest,path,first,routing or [--------|h] /mtr From braden@ISI.EDU Thu Mar 18 14:23:31 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2IMMqQ19669; Thu, 18 Mar 2004 14:22:52 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id OAA26834; Thu, 18 Mar 2004 14:22:52 -0800 (PST) Date: Thu, 18 Mar 2004 14:22:52 -0800 (PST) Message-Id: <200403182222.OAA26834@gra.isi.edu> To: rfc-interest@rfc-editor.org, mrose+internet.ietf.rfc-interest@dbc.mtview.ca.us Subject: Re: [rfc-i] how to interpret / information X-Sun-Charset: US-ASCII X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 22:23:35 -0000 *> *> how should the contents of the element be interpreted? *> *> in looking at rfc-index.xml, i'm trying to understand what the keywords *> mean. something like this *> *> APPN-MIB *> *> is obvious, but what about Marshall, the keywords in the XML index mean the same thing they have always meant in the RFC Editor's search engine, and they "mean" the same thing that keywords in any publication mean. We welcome input on how to improve our choice of keywords to make searching more useful. *> *> Border,gateway,protocol,Open,shortest,path,first,routing *> *> or *> *> [--------|h] (That "means" we made a mistake. This internal encoding should not have been included in the XML. We will fix it ASAP! Thanks for pointing it out.) Bob Braden for the RFC Editor *> *> /mtr *> _______________________________________________ *> rfc-interest mailing list *> rfc-interest@rfc-editor.org *> http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> From falk@ISI.EDU Thu Mar 18 14:51:23 2004 Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2IMowQ29414 for ; Thu, 18 Mar 2004 14:50:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7-411326754" To: rfc-interest@rfc-editor.org From: Aaron Falk Date: Thu, 18 Mar 2004 14:50:58 -0800 X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Subject: [rfc-i] test -- please ignore X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 22:51:23 -0000 --Apple-Mail-7-411326754 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed This is a test of the rfc-interest mail server. Please ignore. --aaron --Apple-Mail-7-411326754 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAWifS/i95hBY97NERAnQdAJ4saMBKDrjZH8AN9DB+TZP1XlwjeACfQ1Nn 6/GD5d7mturjdp61TJcV4Vk= =hPLw -----END PGP SIGNATURE----- --Apple-Mail-7-411326754-- From gih@telstra.net Thu Mar 18 19:44:32 2004 Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2J3hjq19187; Thu, 18 Mar 2004 19:43:45 -0800 (PST) Received: from gihz1.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i2J3h6uW064708; Fri, 19 Mar 2004 14:43:08 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040319134936.01c4dec0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 19 Mar 2004 13:52:20 +1100 To: Bob Braden , rfc-interest@rfc-editor.org, mrose+internet.ietf.rfc-interest@dbc.mtview.ca.us From: Geoff Huston Subject: Re: [rfc-i] how to interpret / information In-Reply-To: <200403182222.OAA26834@gra.isi.edu> References: <200403182222.OAA26834@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: gih@telstra.net Cc: rfc-editor@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 03:44:36 -0000 At 09:22 AM 19/03/2004, Bob Braden wrote: >Marshall, the keywords in the XML index mean the same thing they >have always meant in the RFC Editor's search engine, and they "mean" >the same thing that keywords in any publication mean. We welcome >input on how to improve our choice of keywords to make searching >more useful. > > *> > *> Border,gateway,protocol,Open,shortest,path,first,routing > *> > *> or > *> > *> [--------|h] > >(That "means" we made a mistake. This internal encoding should not >have been included in the XML. We will fix it ASAP! Thanks for >pointing it out.) Just to clarify here (as someone else who attempts to parse the XML, are _both_ cases Marshall provided mistakes? - i.e. is the intended to include a only a single word, and multiple words are to be listed with multiple elements? Thanks, Geoff From braden@ISI.EDU Fri Mar 26 09:20:06 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2QHJbq26068; Fri, 26 Mar 2004 09:19:37 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA25711; Fri, 26 Mar 2004 09:19:37 -0800 (PST) Date: Fri, 26 Mar 2004 09:19:37 -0800 (PST) Message-Id: <200403261719.JAA25711@gra.isi.edu> To: rfc-interest@rfc-editor.org, rfced-ietf@ietf.org X-Sun-Charset: US-ASCII X-ISI-4.28.6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org Subject: [rfc-i] Errata linked to RFC search engine X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2004 17:20:10 -0000 The RFC Editor's RFC search engine is now linked to our Errata data base. In a search result line, the "More Info" field, in addition to Obsoletes and Updates entries, will have an "Errata" hyperlink for any RFC for which a correction has been noted. Clicking on that link will take you directly to the Errata entry for that RFC. EG try searching for 3885. Let us know if any problems are noted, and of course we are always open to suggestions for improvement. The RFC Editor From braden@ISI.EDU Fri Mar 26 09:57:15 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2QHuVq07671; Fri, 26 Mar 2004 09:56:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA25799; Fri, 26 Mar 2004 09:56:31 -0800 (PST) Date: Fri, 26 Mar 2004 09:56:31 -0800 (PST) Message-Id: <200403261756.JAA25799@gra.isi.edu> To: rfc-interest@rfc-editor.org, rfced-ietf@ietf.org, braden@ISI.EDU X-Sun-Charset: US-ASCII X-ISI-4.28.6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org Subject: [rfc-i] Re: Errata linked to RFC search engine X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2004 17:57:19 -0000 *> *> EG try searching for 3885. Make that 3385. Sorry. *> *> Let us know if any problems are noted, and of course we are always *> open to suggestions for improvement. *> *> The RFC Editor *> From falk@ISI.EDU Wed Mar 31 08:57:12 2004 Received: from [206.117.31.166] ([206.117.31.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VGuGq24339 for ; Wed, 31 Mar 2004 08:56:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--634240687" To: rfc-interest@rfc-editor.org From: Aaron Falk Date: Wed, 31 Mar 2004 08:56:14 -0800 X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Subject: [rfc-i] rfc-info needs your help! X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 16:57:12 -0000 --Apple-Mail-10--634240687 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed The RFC Editor maintains a service for the retrieval of RFCs via email known as rfc-info. Instructions for using this service can be found at http://www.isi.edu/in-notes/rfc-editor/rfc-info.help. Before you start sending email to rfc-info@rfc-editor.org, you should be warned that you probably won't get a response, or at least not for a while. The reason is that the automate retrieval system is totally clogged up with spam and worse, spam backscatter, because the mail address for this service appears in every RFC announcement and, so, is in the hands of many spam generators. (As of this writing, there are 1200 messages pending processing, nearly all spam). The service generates automated help responses which have the vulnerability that they tend to get in loops with other services that have automated responses. (Once, a couple years ago, rfc-info got locked into a death-grip battle with the majordomo at ietf.org, each one trying vainly to give the other enough help -- by _appending_ it to the received message -- information to allow it to successfully complete its transaction. Eventually, the server fell over when the log file grew to be 700MB. We fixed this by manually blocking the source address 'majordomo'. Unfortunately, there are many other automated services with other names.) So, we have a service that doesn't work so well and would like some input from the community on what we might do about it. Here are some options: 1. Use a tool like SpamAssassin to reduce the assault on the inbox. This is an obvious improvement, if not a solution, but is challenging for several reasons. The rfc-info service is over 12 years old and currently runs on an old OS (SunOS 4.1.4) that is marginally supported by our IT department. For example, the app is built on perl 4.0 and the system doesn't have procmail. Moving it to another platform could be quite painful as more modern versions of the OS & apps may break rfc-info. 2. Find and integrate a more modern email-based document retrieval system. I.e., start from scratch with another app. Suggestions for candidate apps would be welcome. This may be the path of least pain, if such a replacement application is available. 3. Drop the service all together. Let people use the RFC Editor web and ftp services to retrieve documents. This seems undesirable as the service does get used and there are places where web access is limited. We'd strongly like to preserve email as a method of retrieving RFCs. 4. Use scripts to purge all backed up messages when backups grow beyond a certain level. This is about what we're doing now (except without the scripts). The problem here is that valid messages get discarded along with spam during the purge/reset. This solution is crude, somewhat effective, and ultimately, makes an unreliable service. 5. Modify rfc-info so that it silently discards messages it doesn't understand. This may be the most elegant solution but requires an understanding of Perl beyond mine. :) We're interested in opinions on these options, or other suggestions, as well as volunteers to help sort this out. Beware, though, that most of this was written circa 1992 and has been tweaked and hacked since then, so it's not for the faint of heart. Best regards, --aaron (for the RFC Editor) --Apple-Mail-10--634240687 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAavgu/i95hBY97NERAsKhAJ9yDjJ4LhpcA8ttKZ6DGZhn1dl7XACfdirK RJIW34xpms5D8iVPu2mH3Fk= =EpBF -----END PGP SIGNATURE----- --Apple-Mail-10--634240687-- From pekkas@netcore.fi Wed Mar 31 09:07:16 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VH6jq27190 for ; Wed, 31 Mar 2004 09:06:45 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2VH6VB22494; Wed, 31 Mar 2004 20:06:31 +0300 Date: Wed, 31 Mar 2004 20:06:31 +0300 (EEST) From: Pekka Savola To: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: pekkas@netcore.fi Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:07:17 -0000 On Wed, 31 Mar 2004, Aaron Falk wrote: > 3. Drop the service all together. Let people use the RFC Editor web > and ftp services to retrieve documents. This seems undesirable as the > service does get used and there are places where web access is limited. > We'd strongly like to preserve email as a method of retrieving RFCs. I've always wondered about the applicability of this. My vote would go for dropping this. This scenario was useful 10, 15, 20 years ago, but not really anymore. At the moment, all this seems to be doing is increasing the length & complexity of RFC announcements :) It might be interesting trying to figure out the profile of the legitimate users of the service, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From falk@ISI.EDU Wed Mar 31 09:10:17 2004 Received: from [206.117.31.166] ([206.117.31.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VH9dq28179; Wed, 31 Mar 2004 09:09:39 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12--633437351" Message-Id: <30C38DB6-8336-11D8-8DCB-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! Date: Wed, 31 Mar 2004 09:09:37 -0800 To: Pekka Savola X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:10:18 -0000 --Apple-Mail-12--633437351 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 31, 2004, at 9:06 AM, Pekka Savola wrote: > It might be interesting trying to figure out the profile of the > legitimate users of the service, though. Unfortunately the logs have been ruined by spam but my cursory viewing of them shows mostly latin and south american users. --aaron --Apple-Mail-12--633437351 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAavtR/i95hBY97NERAs1tAJ9VdE5U7fKycM5ttMBkks3aQyXNhACfVqgn 2BrbcTGIRjYVgCfKCbR6obw= =sLly -----END PGP SIGNATURE----- --Apple-Mail-12--633437351-- From paul.hoffman@vpnc.org Wed Mar 31 09:14:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHDsq29881 for ; Wed, 31 Mar 2004 09:13:54 -0800 (PST) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VHDg6M013937; Wed, 31 Mar 2004 09:13:43 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 31 Mar 2004 09:13:45 -0800 To: Pekka Savola , Aaron Falk From: Paul Hoffman / VPNC Subject: Re: [rfc-i] rfc-info needs your help! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:14:13 -0000 At 8:06 PM +0300 3/31/04, Pekka Savola wrote: >I've always wondered about the applicability of this. My vote would >go for dropping this. Pekka is right. There is essentially no need for someone who can only use email, not the web or FTP, to be reading Internet standards and associated documents. --Paul Hoffman, Director --VPN Consortium From dmm@1-4-5.net Wed Mar 31 09:17:18 2004 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHGrq00716 for ; Wed, 31 Mar 2004 09:16:53 -0800 (PST) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2VHGmDg000447; Wed, 31 Mar 2004 09:16:48 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) id i2VHGmcX000446; Wed, 31 Mar 2004 09:16:48 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 31 Mar 2004 09:16:48 -0800 From: David Meyer To: Paul Hoffman / VPNC Subject: Re: [rfc-i] rfc-info needs your help! Message-ID: <20040331171648.GA440@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: dmm@1-4-5.net Cc: rfc-interest@rfc-editor.org, Aaron Falk , Pekka Savola X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:17:19 -0000 On Wed, Mar 31, 2004 at 09:13:45AM -0800, Paul Hoffman / VPNC wrote: >> At 8:06 PM +0300 3/31/04, Pekka Savola wrote: >> >I've always wondered about the applicability of this. My vote would >> >go for dropping this. >> >> Pekka is right. There is essentially no need for someone who can only >> use email, not the web or FTP, to be reading Internet standards and >> associated documents. Second (or third :-) that... Dave From rousskov@measurement-factory.com Wed Mar 31 09:28:14 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHS1q04199 for ; Wed, 31 Mar 2004 09:28:01 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VHRxuH004087; Wed, 31 Mar 2004 10:27:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VHRxSi004086; Wed, 31 Mar 2004 10:27:59 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 10:27:59 -0700 (MST) From: Alex Rousskov To: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> Message-ID: References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:28:14 -0000 On Wed, 31 Mar 2004, Aaron Falk wrote: > 3. Drop the service all together. Let people use the RFC Editor web > and ftp services to retrieve documents. This seems undesirable as > the service does get used and there are places where web access is > limited. We'd strongly like to preserve email as a method of > retrieving RFCs. Without seeing the actual usage counts and analyses, I have to assume that the number of users without web access is negligible compared to the total number of users retrieving documents over the web. Since RFC Editor already has more high-priority work than it can handle, my recommendation would be to suspend this marginal service. While trying to support minority needs is noble, there is always a point where it becomes prohibitively expensive. For example, RFC Editor does not offer hand-delivery of documents to those without network access! Finally, if current service users without alternatives truly need this, they should help themselves by installing a web-to-email proxy on a third party computer. If such a proxy does not exist, a simple version of it can be written without much effort. It seems to me that such a proxy would offer 90% of what the current custom interface provides. On a side note, it would be great to hear from web-challenged people so that their needs in retrieving documents over e-mail are adequately represented. HTH, Alex. From mcr@sandelman.ottawa.on.ca Wed Mar 31 09:37:24 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHaIq07042 for ; Wed, 31 Mar 2004 09:36:19 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VHa8g27360 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 12:36:10 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VHdar01509 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 12:39:42 -0500 (EST) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VHYD8o000577 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 Mar 2004 12:34:13 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VHYCGo000574; Wed, 31 Mar 2004 12:34:13 -0500 To: rfc-interest@rfc-editor.org In-Reply-To: Message from Aaron Falk of "Wed, 31 Mar 2004 08:56:14 PST." <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 31 Mar 2004 12:34:12 -0500 Message-ID: <573.1080754452@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! Cc: Aaron Falk X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:37:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Aaron" == Aaron Falk writes: Aaron> 2. Find and integrate a more modern email-based document Aaron> retrieval system. I.e., start from scratch with another app. Aaron> Suggestions for candidate apps would be welcome. This may be Aaron> the path of least pain, if such a replacement application is Aaron> available. I think that given that you don't want to drop the service, that you should replace it with something more modern, on more modern equipment. even majordomo1 with a backstore of rfc's likely has better spam protection. Ideally, you want to integrate one of these filters that sends out a "I don't know you, please reply to me so you'll get past my spam filter" type filters. Aaron> 3. Drop the service all together. Let people use the RFC Aaron> 5. Modify rfc-info so that it silently discards messages it - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQGsBE4qHRg3pndX9AQHnogQA8DCDVVIDD46qyXx6Bp/33r/O3kAogHNz aCDkgAfIVTMNskkjd21KA7cJ+Y7lGithtgm6ECMsAuZL5BzcsPrJsNgbY9iihjEJ Z6660RsdKP4n3XkTYuu4sroZzGd7aJWFGUNxtyMh7ce+Kc2lDELBNVTSerkwqj2k rXRmul7bOAU= =gVOX -----END PGP SIGNATURE----- From falk@ISI.EDU Wed Mar 31 09:41:59 2004 Received: from [206.117.31.166] ([206.117.31.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHeqq08423; Wed, 31 Mar 2004 09:40:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15--631563954" Message-Id: <8D65312B-833A-11D8-8DCB-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Date: Wed, 31 Mar 2004 09:40:51 -0800 To: rfc-interest@rfc-editor.org X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Cc: RFC Editor Subject: [rfc-i] html anchors in rfc-editor queue X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:42:00 -0000 --Apple-Mail-15--631563954 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi- Here's a nifty thing. We've added anchors to entries in the RFC Editor queue to allow linking directly to a document of interest. For example, try http://www.rfc-editor.org/queue.html#draft-ietf-ipv6-rfc2012-update Be aware that we're just rolling this out so there may be bugs. Please play with it and send us comments or even if you just find it useful. Thanks, --aaron (for the RFC Editor) --Apple-Mail-15--631563954 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAawKj/i95hBY97NERAgdUAJ9fa7pa8chw34En7n1VjOtUUPd0YACgoina B8fN2b/KurAZr5pkc5LiGns= =tYXQ -----END PGP SIGNATURE----- --Apple-Mail-15--631563954-- From mcr@sandelman.ottawa.on.ca Wed Mar 31 09:49:21 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHmoq10713 for ; Wed, 31 Mar 2004 09:48:50 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VHmkg27449 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 31 Mar 2004 12:48:49 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VHpFr01792 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 31 Mar 2004 12:51:21 -0500 (EST) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VHk28o001255 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 Mar 2004 12:46:02 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VHk2of001252 for ; Wed, 31 Mar 2004 12:46:02 -0500 To: rfc-interest@rfc-editor.org In-Reply-To: Message from Paul Hoffman / VPNC of "Wed, 31 Mar 2004 09:13:45 PST." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 31 Mar 2004 12:46:02 -0500 Message-ID: <1251.1080755162@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:49:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 8:06 PM +0300 3/31/04, Pekka Savola wrote: >> I've always wondered about the applicability of this. My vote >> would go for dropping this. VPNC> Pekka is right. There is essentially no need for someone who VPNC> can only use email, not the web or FTP, to be reading Internet VPNC> standards and associated documents. There are lots of places with rather restrictive policies. This may be because of politics ("great firewall of china"), or because bandwidth is so expensive that doing anything "interactive" like FTP/WWW is slow. On the other hand, email happens asynchronous to the user, and can get queued up for later use. I hate that we use email for this - my opinion is that if we had a good non-interactive file transfer protocol that people would never send documents by email, and therefore our virii problem would never have occured. So, I too, would ask if there is a way for these folks that need this service to get things another way - but I think just saying they have no business is not right. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQGsD2YqHRg3pndX9AQEosQQAnA88tI5v45986FRD6C++ZUdMjzjgOFAL haftVwD6ISPUv1/mBDDVYINXiSHjsIs9GcfeeaNXymfnr5bSSIgr/Q1YXvr7OPdP EJr8WBpH/Aj4cY6Xcd6fPtKVK2SbnqM7pIlezSR8YLw5T+v2eS2ZJqjSnoJjHc1O 6Zd4oIaXWbo= =MeQi -----END PGP SIGNATURE----- From falk@ISI.EDU Wed Mar 31 09:50:17 2004 Received: from [206.117.31.166] ([206.117.31.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VHntq11215; Wed, 31 Mar 2004 09:49:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16--631021348" Message-Id: Content-Transfer-Encoding: 7bit From: Aaron Falk Date: Wed, 31 Mar 2004 09:49:53 -0800 To: rfc-interest@rfc-editor.org X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Cc: RFC Editor Subject: [rfc-i] errata improvements X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:50:20 -0000 --Apple-Mail-16--631021348 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed A couple of other things that might be of interest to this list. (These have been in place for a couple of weeks, so you may have noticed them already.) We've added a search field to the errata page to allow quicker access to errata. You'll see this at http://www.rfc-editor.org/errata.html. Also, links to errata now show up in RFC search results in the 'More Info' column. For example, try going to http://www.rfc-editor.org/rfcsearch.html and searching for '3530'. Hope you find these helpful, --aaron --Apple-Mail-16--631021348 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAawTB/i95hBY97NERAsQ6AJ41PaQARBG0jjfwHRm9+N0Zwtd2UwCfSCg6 5rEehIUM3aBOXQ+xFkkUsnw= =InbE -----END PGP SIGNATURE----- --Apple-Mail-16--631021348-- From julian.reschke@gmx.de Wed Mar 31 09:51:16 2004 Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i2VHocq11563 for ; Wed, 31 Mar 2004 09:50:38 -0800 (PST) Received: (qmail 19326 invoked by uid 65534); 31 Mar 2004 17:50:30 -0000 Received: from pD950C3A8.dip.t-dialin.net (EHLO gmx.de) (217.80.195.168) by mail.gmx.net (mp025) with SMTP; 31 Mar 2004 19:50:30 +0200 X-Authenticated: #1915285 Message-ID: <406B04D6.4040705@gmx.de> Date: Wed, 31 Mar 2004 19:50:14 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Falk Subject: Re: [rfc-i] html anchors in rfc-editor queue References: <8D65312B-833A-11D8-8DCB-000A95DBDB84@isi.edu> In-Reply-To: <8D65312B-833A-11D8-8DCB-000A95DBDB84@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org, RFC Editor X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:51:16 -0000 Aaron Falk wrote: > Hi- > > Here's a nifty thing. We've added anchors to entries in the RFC Editor > queue to allow linking directly to a document of interest. > > For example, try > > http://www.rfc-editor.org/queue.html#draft-ietf-ipv6-rfc2012-update > > Be aware that we're just rolling this out so there may be bugs. Please > play with it and send us comments or even if you just find it useful. > > Thanks, > > --aaron (for the RFC Editor) Works great, thanks! -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From housley@vigilsec.com Wed Mar 31 09:53:24 2004 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i2VHqJq11977 for ; Wed, 31 Mar 2004 09:52:19 -0800 (PST) Received: (qmail 2910 invoked by uid 0); 31 Mar 2004 17:41:37 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (206.117.31.141) by woodstock.binhost.com with SMTP; 31 Mar 2004 17:41:37 -0000 Message-Id: <5.2.0.9.2.20040331124724.03497030@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 31 Mar 2004 12:51:51 -0500 To: Aaron Falk , rfc-interest@rfc-editor.org From: Russ Housley Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: housley@vigilsec.com Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 17:53:24 -0000 Aaron: It would be interesting to see if Spam Assasin and Virus Scanning would eliminate enough of the bogus message traffic. This could probably be done fairly easily. If that is not sufficient, then it is probably not worth much more effort to preserve the service. Russ At 08:56 AM 3/31/2004 -0800, Aaron Falk wrote: The RFC Editor maintains a service for the retrieval of RFCs via email known as rfc-info. Instructions for using this service can be found at http://www.isi.edu/in-notes/rfc-editor/rfc-info.help. Before you start sending email to rfc-info@rfc-editor.org, you should be warned that you probably won't get a response, or at least not for a while. The reason is that the automate retrieval system is totally clogged up with spam and worse, spam backscatter, because the mail address for this service appears in every RFC announcement and, so, is in the hands of many spam generators. (As of this writing, there are 1200 messages pending processing, nearly all spam). The service generates automated help responses which have the vulnerability that they tend to get in loops with other services that have automated responses. (Once, a couple years ago, rfc-info got locked into a death-grip battle with the majordomo at ietf.org, each one trying vainly to give the other enough help -- by _appending_ it to the received message -- information to allow it to successfully complete its transaction. Eventually, the server fell over when the log file grew to be 700MB. We fixed this by manually blocking the source address 'majordomo'. Unfortunately, there are many other automated services with other names.) So, we have a service that doesn't work so well and would like some input from the community on what we might do about it. Here are some options: 1. Use a tool like SpamAssassin to reduce the assault on the inbox. This is an obvious improvement, if not a solution, but is challenging for several reasons. The rfc-info service is over 12 years old and currently runs on an old OS (SunOS 4.1.4) that is marginally supported by our IT department. For example, the app is built on perl 4.0 and the system doesn't have procmail. Moving it to another platform could be quite painful as more modern versions of the OS & apps may break rfc-info. 2. Find and integrate a more modern email-based document retrieval system. I.e., start from scratch with another app. Suggestions for candidate apps would be welcome. This may be the path of least pain, if such a replacement application is available. 3. Drop the service all together. Let people use the RFC Editor web and ftp services to retrieve documents. This seems undesirable as the service does get used and there are places where web access is limited. We'd strongly like to preserve email as a method of retrieving RFCs. 4. Use scripts to purge all backed up messages when backups grow beyond a certain level. This is about what we're doing now (except without the scripts). The problem here is that valid messages get discarded along with spam during the purge/reset. This solution is crude, somewhat effective, and ultimately, makes an unreliable service. 5. Modify rfc-info so that it silently discards messages it doesn't understand. This may be the most elegant solution but requires an understanding of Perl beyond mine. :) We're interested in opinions on these options, or other suggestions, as well as volunteers to help sort this out. Beware, though, that most of this was written circa 1992 and has been tweaked and hacked since then, so it's not for the faint of heart. Best regards, --aaron (for the RFC Editor) From rousskov@measurement-factory.com Wed Mar 31 10:04:14 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VI3Sq15840 for ; Wed, 31 Mar 2004 10:03:28 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VI3QuH005414; Wed, 31 Mar 2004 11:03:27 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VI3QlK005413; Wed, 31 Mar 2004 11:03:26 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 11:03:26 -0700 (MST) From: Alex Rousskov To: Aaron Falk Subject: Re: [rfc-i] errata improvements In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:04:14 -0000 On Wed, 31 Mar 2004, Aaron Falk wrote: > links to errata now show up in RFC search results in the 'More > Info' column. For example, try going to > http://www.rfc-editor.org/rfcsearch.html and searching for '3530'. > > Hope you find these helpful, The errata link from search results is not just helpful, it is essential! While this is still far from making the existence of errata known to readers, this is a big step forward. Thanks a lot, Alex. From rousskov@measurement-factory.com Wed Mar 31 10:20:37 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VIJBq20514 for ; Wed, 31 Mar 2004 10:19:11 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VIJBuH006000; Wed, 31 Mar 2004 11:19:11 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VIJBnB005999; Wed, 31 Mar 2004 11:19:11 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 11:19:11 -0700 (MST) From: Alex Rousskov To: Michael Richardson Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <1251.1080755162@marajade.sandelman.ottawa.on.ca> Message-ID: References: <1251.1080755162@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:20:37 -0000 On Wed, 31 Mar 2004, Michael Richardson wrote: > There are lots of places with rather restrictive policies. This may > be because of politics ("great firewall of china") IMO, RFC Editor should not be in business of providing backdoor to those who try to circumvent local policies (even if those policies are considered evil by IETF majority). Others like friends and colleagues abroad can provide such backdoors. > or because bandwidth is so expensive E-mail transfers are unlikely to save much bandwidth compared to targeted HTTP or FTP requests. Perhaps you meant to say "scarce"? > that doing anything "interactive" like FTP/WWW is slow. Slow does not mean "does not work". Wget, for example, is not interactive and can be tuned to tolerate very long delays. It can also use range requests to receive data in small pieces, if needed. > On the other hand, email happens asynchronous to the user, and can > get queued up for later use. So is the output of wget; and wget can run in the background. > my opinion is that if we had a good non-interactive file transfer > protocol that people would never send documents by email, and > therefore our virii problem would never have occured. HTTP is not interactive. Browsing is, but these users do not have to browse online; they can browse offline. Please do not get me wrong -- I am not saying that readers with restricted or slow web access are somehow inferior to IETF. I am saying that RFC Editor is the wrong entity to solve their problems today and that many of them can and should help themselves. Alex. From bob.hinden@nokia.com Wed Mar 31 10:22:15 2004 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VILRq21295 for ; Wed, 31 Mar 2004 10:21:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VILCX09476; Wed, 31 Mar 2004 10:21:12 -0800 X-mProtect: <200403311821> Nokia Silicon Valley Messaging Protection Received: from pc-b209.wlan.inet.fi (194.89.117.209, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd2qziXv; Wed, 31 Mar 2004 10:21:09 PST Message-Id: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 10:20:03 -0800 To: Michael Richardson From: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <1251.1080755162@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: bob.hinden@nokia.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:22:15 -0000 Michael, > There are lots of places with rather restrictive policies. > This may be because of politics ("great firewall of china"), or >because bandwidth is so expensive that doing anything "interactive" >like FTP/WWW is slow. > > On the other hand, email happens asynchronous to the user, and can get >queued up for later use. I hate that we use email for this - my opinion >is that if we had a good non-interactive file transfer protocol that >people would never send documents by email, and therefore our virii >problem would never have occured. > > So, I too, would ask if there is a way for these folks that need this >service to get things another way - but I think just saying they have >no business is not right. I agree. I think it is important to maintain the ability to receive an RFC by email, but I think we can eliminate the email request mechanism. Instead something where the user fills in a simple web form with an RFC number (or list of RFC numbers) and his/her email address. This would retain the ability to obtain RFCs via email and avoid the current plans with SPAM. Bob From mcr@sandelman.ottawa.on.ca Wed Mar 31 10:32:15 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VIVGq24715 for ; Wed, 31 Mar 2004 10:31:17 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VIVDi27844 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 31 Mar 2004 13:31:16 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VIaGr03011 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 31 Mar 2004 13:36:22 -0500 (EST) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VIUr8o004438 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 31 Mar 2004 13:30:53 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VIUraE004435 for ; Wed, 31 Mar 2004 13:30:53 -0500 To: rfc-interest@rfc-editor.org In-Reply-To: Message from Bob Hinden of "Wed, 31 Mar 2004 10:20:03 PST." <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 31 Mar 2004 13:30:53 -0500 Message-ID: <4433.1080757853@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:32:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Hinden writes: Bob> I agree. I think it is important to maintain the ability to Bob> receive an RFC by email, but I think we can eliminate the email Bob> request mechanism. Instead something where the user fills in a Bob> simple web form with an RFC number (or list of RFC numbers) and Bob> his/her email address. This would retain the ability to obtain Bob> RFCs via email and avoid the current plans with SPAM. You have to make sure that they email is legit before sending stuff to it. So, it would be best if they logged in - i.e. created an account confirmed by email address, and then could start requesting eRFCs. Otherwise, the server becomes a way to get the RFC editor to spam people :-( Fortunately, almost all CMS's/phpSlash/back-end, etc. have this facility pretty much built in. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQGsOXIqHRg3pndX9AQFZ2AP+KgpG6HyVzAJlFy2wa8yu7jr6by3CGTfD TyxdNlZOSXdr0hTF40pcBAoA2+1AyXx+jhKtsaAjOyk3QYYcU92/KdKruxrWAdZ8 0ozkP8DTrqB1sUQlhq4jeP+0T/cuF1GJ1lYFmMT1fF8DGsyMkfHagZ6UBNFx5Y+Y 1EDZoXnT9IM= =Uoke -----END PGP SIGNATURE----- From rousskov@measurement-factory.com Wed Mar 31 10:37:15 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VIb3q26375 for ; Wed, 31 Mar 2004 10:37:03 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VIaluH006753; Wed, 31 Mar 2004 11:36:48 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VIaln9006752; Wed, 31 Mar 2004 11:36:47 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 11:36:47 -0700 (MST) From: Alex Rousskov To: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> Message-ID: References: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: Michael Richardson , rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:37:15 -0000 On Wed, 31 Mar 2004, Bob Hinden wrote: > Instead something where the user fills in a simple web form with an > RFC number (or list of RFC numbers) and his/her email address. > This would retain the ability to obtain RFCs via email and avoid the > current plans with SPAM. Can you provide a specific technical reason why a user that is able to fill a web form and receive RFC via e-mail is not able to fetch the same RFC document via HTTP? Thanks, Alex. From braden@ISI.EDU Wed Mar 31 10:42:09 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VIeRq27710; Wed, 31 Mar 2004 10:40:27 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA27296; Wed, 31 Mar 2004 10:40:27 -0800 (PST) Date: Wed, 31 Mar 2004 10:40:27 -0800 (PST) Message-Id: <200403311840.KAA27296@gra.isi.edu> To: rfc-interest@rfc-editor.org, mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 18:42:10 -0000 *> *> On the other hand, email happens asynchronous to the user, and can get *> queued up for later use. I hate that we use email for this - my opinion *> is that if we had a good non-interactive file transfer protocol that *> people would never send documents by email, and therefore our virii *> problem would never have occured. *> As a matter of fact, you do! Please see RFC 1068. But sometimes FTP is blocked too. Bob Braden From mcr@sandelman.ottawa.on.ca Wed Mar 31 11:05:18 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VJ4Rq06042 for ; Wed, 31 Mar 2004 11:04:27 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VJ3qk28061 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 14:04:26 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VJ4pr03719 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 14:04:57 -0500 (EST) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VIxc8o005507 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 Mar 2004 13:59:39 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VIxcQB005504; Wed, 31 Mar 2004 13:59:38 -0500 To: Bob Braden In-Reply-To: Message from Bob Braden of "Wed, 31 Mar 2004 10:40:27 PST." <200403311840.KAA27296@gra.isi.edu> References: <200403311840.KAA27296@gra.isi.edu> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 31 Mar 2004 13:59:38 -0500 Message-ID: <5503.1080759578@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 19:05:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Braden writes: Bob> user, and can get *> queued up for later use. I hate that we Bob> use email for this - my opinion *> is that if we had a good Bob> non-interactive file transfer protocol that *> people would Bob> never send documents by email, and therefore our virii *> Bob> problem would never have occured. *> Bob> As a matter of fact, you do! Please see RFC 1068. Bob> But sometimes FTP is blocked too. perhaps I used the wrong term. When I said "interactive", I really meant "real time" I know about wget, ftp, etc. it is not the same thing as: uucp rfceditor!/pub/rfc/rfc1068.txt $HOME/rfc/rfc1068.txt Which would run later on, and let me know when it was done. Sure, one could trivially build such a thing with wget underneath, but I'm not aware of any widely deployed system that can do that. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQGsVGYqHRg3pndX9AQGF7wP/Tcs1P8Wj+gppT8C+GE1rFN0fYDdcWrkm n+KIvveNJodML+JQXthwUymIslsBAHwwpLcIgfsXWzknYFfrl0shZbyibPJPd9D5 OZS+S+vpNAo0wgDoF5dnW3vQwYFFfBidOI9t6ANVQg+74/27AljNqp8k4AASxhf+ MpAbBbeIIv4= =1eKU -----END PGP SIGNATURE----- From henrik@levkowetz.com Wed Mar 31 11:40:17 2004 Received: from av3-2-sn3.vrr.skanova.net (av3-2-sn3.vrr.skanova.net [81.228.9.110]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VJe9q15874 for ; Wed, 31 Mar 2004 11:40:10 -0800 (PST) Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0FDB537F3E; Wed, 31 Mar 2004 21:40:01 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id F2B7A37EEF; Wed, 31 Mar 2004 21:40:00 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id A27F838036; Wed, 31 Mar 2004 21:40:00 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1B8lZA-0004D6-00; Wed, 31 Mar 2004 21:40:00 +0200 Date: Wed, 31 Mar 2004 21:39:59 +0200 From: Henrik Levkowetz To: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! Message-Id: <20040331213959.7cc941c9.henrik@levkowetz.com> In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: henrik@levkowetz.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 19:40:17 -0000 Hi Aaron, Wednesday 31 March 2004, Aaron Falk wrote: ... > 1. Use a tool like SpamAssassin to reduce the assault on the inbox. > This is an obvious improvement, if not a solution, but is challenging > for several reasons. The rfc-info service is over 12 years old and > currently runs on an old OS (SunOS 4.1.4) that is marginally supported > by our IT department. For example, the app is built on perl 4.0 and > the system doesn't have procmail. Moving it to another platform could > be quite painful as more modern versions of the OS & apps may break > rfc-info. It seems to me that the easiest way of keeping the current application and adding Spamassassin (or Dspam) would be to run the spam filter on a separate box before sending the mails on to the old SunOS box, rather than moving the application to a new box. > 2. Find and integrate a more modern email-based document retrieval > system. I.e., start from scratch with another app. Suggestions for > candidate apps would be welcome. This may be the path of least pain, > if such a replacement application is available. Hmm. Might be possible. I'm checking up some leads. > 3. Drop the service all together. Let people use the RFC Editor web > and ftp services to retrieve documents. This seems undesirable as the > service does get used and there are places where web access is limited. > We'd strongly like to preserve email as a method of retrieving RFCs. Not personally sure it's worth the effort, but fair enough. > 4. Use scripts to purge all backed up messages when backups grow beyond > a certain level. This is about what we're doing now (except without > the scripts). The problem here is that valid messages get discarded > along with spam during the purge/reset. This solution is crude, > somewhat effective, and ultimately, makes an unreliable service. Stopgap, not a solution. > 5. Modify rfc-info so that it silently discards messages it doesn't > understand. This may be the most elegant solution but requires an > understanding of Perl beyond mine. :) It's probably just as easy to put together a new implementation of the service with the state of the code you indicate. ---- So in summary, I'd suggest 1. above, with filtering on a second machine as a short-term solution, and possibly 2. as a longer-term one. I'll check on some options for that. Henrik From bob.hinden@nokia.com Wed Mar 31 12:03:17 2004 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VK2Oq22010 for ; Wed, 31 Mar 2004 12:02:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2VK1VL30025; Wed, 31 Mar 2004 12:01:31 -0800 X-mProtect: <200403312001> Nokia Silicon Valley Messaging Protection Received: from pc-b209.wlan.inet.fi (194.89.117.209, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdKF6EAk; Wed, 31 Mar 2004 12:01:28 PST Message-Id: <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 12:00:21 -0800 To: Alex Rousskov From: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: References: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: bob.hinden@nokia.com Cc: Michael Richardson , Bob Hinden , rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 20:03:17 -0000 Alex, >Can you provide a specific technical reason why a user that is able to >fill a web form and receive RFC via e-mail is not able to fetch the >same RFC document via HTTP? No, nor do I think that is the issue. I see the ability to receive RFC's by email is a useful service. Now that I think about it, I might even use it sometime myself because it is easier than having to right click, selecting "save link as file", etc. in a browser. Especially if I had a list of RFCs I wanted to retrieve. Bob From rousskov@measurement-factory.com Wed Mar 31 12:07:17 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VK5Hq23095 for ; Wed, 31 Mar 2004 12:05:17 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VK5GuH011351; Wed, 31 Mar 2004 13:05:17 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VK5GEH011350; Wed, 31 Mar 2004 13:05:16 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 13:05:16 -0700 (MST) From: Alex Rousskov To: Michael Richardson Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <5503.1080759578@marajade.sandelman.ottawa.on.ca> Message-ID: References: <200403311840.KAA27296@gra.isi.edu> <5503.1080759578@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 20:07:17 -0000 On Wed, 31 Mar 2004, Michael Richardson wrote: > I know about wget, ftp, etc. it is not the same thing as: > uucp rfceditor!/pub/rfc/rfc1068.txt $HOME/rfc/rfc1068.txt Looks pretty much equivalent to me (as far as this discussion is concerned): wget -O - ftp://ftp.rfc-editor.org/in-notes/rfc1068.txt | mail $USER or wget -O $HOME/rfc/rfc1068.txt ftp://ftp.rfc-editor.org/in-notes/rfc1068.txt etc. Alex. From rousskov@measurement-factory.com Wed Mar 31 12:19:17 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VKIRq27148 for ; Wed, 31 Mar 2004 12:18:27 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VKIBuH011946; Wed, 31 Mar 2004 13:18:12 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VKIBHV011945; Wed, 31 Mar 2004 13:18:11 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 13:18:11 -0700 (MST) From: Alex Rousskov To: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> Message-ID: References: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.no> <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 20:19:18 -0000 On Wed, 31 Mar 2004, Bob Hinden wrote: > I see the ability to receive RFC's by email is a useful service. I agree that the service is useful, but that is irrelevant. There are two relevant and related questions: - Is the service essential? - Does RFC Editor have far more important things in the queue? My answers to the above are "no" and "yes". That is why I suggested to suspend the service, given the fact that it is currently seriously broken. Alex. P.S. > Now that I think about it, I might even use it sometime myself > because it is easier than having to right click, selecting "save > link as file", etc. in a browser. Especially if I had a list of > RFCs I wanted to retrieve. If you have a list of RFCs, you can use wget to fetch that list. No right clicking is required. With little effort, you can even setup a local RFC mirror on your laptop! Again, RFC Editor should provide mainstream access to RFCs. The rest can be done by individuals or 3rd party groups that need alternatives. From mcr@sandelman.ottawa.on.ca Wed Mar 31 12:25:10 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2VKNeq28597 for ; Wed, 31 Mar 2004 12:23:41 -0800 (PST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VKNDk28694 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 15:23:17 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i2VKRlr05882 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 31 Mar 2004 15:27:53 -0500 (EST) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VKMY8o009445 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 31 Mar 2004 15:22:34 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VKMYcx009441; Wed, 31 Mar 2004 15:22:34 -0500 To: rfc-interest@rfc-editor.org In-reply-to: Your message of "Wed, 31 Mar 2004 13:05:16 MST." X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Wed, 31 Mar 2004 15:22:33 -0500 Message-ID: <9440.1080764553@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: Re: [rfc-i] rfc-info needs your help! Cc: Alex Rousskov X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 20:25:10 -0000 >>>>> "Alex" == Alex Rousskov writes: >> I know about wget, ftp, etc. it is not the same thing as: uucp >> rfceditor!/pub/rfc/rfc1068.txt $HOME/rfc/rfc1068.txt Alex> Looks pretty much equivalent to me (as far as this discussion Alex> is concerned): Alex> wget -O - ftp://ftp.rfc-editor.org/in-notes/rfc1068.txt | mail Alex> $USER Now, do this while your network is not plugged in. Then, reboot your computer. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From paul.hoffman@vpnc.org Wed Mar 31 16:43:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i310hKq07068 for ; Wed, 31 Mar 2004 16:43:20 -0800 (PST) Received: from [63.202.92.152] (host69.concoursecommunications.com [65.214.230.69] (may be forged)) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i310hDFp048010 for ; Wed, 31 Mar 2004 16:43:14 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.no> <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> Date: Wed, 31 Mar 2004 18:43:14 -0600 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] rfc-info needs your help! Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 00:43:25 -0000 At 12:00 PM -0800 3/31/04, Bob Hinden wrote: >No, nor do I think that is the issue. I see the ability to receive >RFC's by email is a useful service. There are lots of useful services that the RFC Editor can provide that will be of greater value to a larger audience, possibly for the same amount of effort as dealing with this service as viruses and spam get worse. --Paul Hoffman, Director --VPN Consortium From bob.hinden@nokia.com Wed Mar 31 17:31:30 2004 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i311VKq21033 for ; Wed, 31 Mar 2004 17:31:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i311V7l19448; Wed, 31 Mar 2004 17:31:07 -0800 X-mProtect: <200404010131> Nokia Silicon Valley Messaging Protection Received: from pc-b209.wlan.inet.fi (194.89.117.209, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdyPgT1E; Wed, 31 Mar 2004 17:31:04 PST Message-Id: <4.3.2.7.2.20040331172200.033aaa08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Mar 2004 17:29:56 -0800 To: Alex Rousskov From: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: References: <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: bob.hinden@nokia.com Cc: rfc-interest@rfc-editor.org, Bob Hinden X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 01:31:30 -0000 Alex, > > I see the ability to receive RFC's by email is a useful service. > >I agree that the service is useful, but that is irrelevant. There are >two relevant and related questions: > - Is the service essential? > - Does RFC Editor have far more important things in the queue? > >My answers to the above are "no" and "yes". That is why I suggested to >suspend the service, given the fact that it is currently seriously >broken. We don't agree and I had suggested a different way to do it that would avoid the current problems. > If you have a list of RFCs, you can use wget to fetch that list. > No right clicking is required. With little effort, you can even > setup a local RFC mirror on your laptop! Again, RFC Editor should > provide mainstream access to RFCs. The rest can be done by > individuals or 3rd party groups that need alternatives. Yes, but only if one has "wget" on their platform. I was also thinking about other types of platforms such as smart phones, PDAs, etc. Bob From rousskov@measurement-factory.com Wed Mar 31 17:49:25 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i311nGq27052 for ; Wed, 31 Mar 2004 17:49:16 -0800 (PST) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i311n7uH025595; Wed, 31 Mar 2004 18:49:07 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i311n7gF025594; Wed, 31 Mar 2004 18:49:07 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 18:49:06 -0700 (MST) From: Alex Rousskov To: Bob Hinden Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <4.3.2.7.2.20040331172200.033aaa08@mailhost.iprg.nokia.com> Message-ID: References: <4.3.2.7.2.20040331115253.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331101228.033ebfe8@mailhost.iprg.nokia.com> <4.3.2.7.2.20040331172200.033aaa08@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 01:49:25 -0000 On Wed, 31 Mar 2004, Bob Hinden wrote: > I had suggested a different way to do it that would > avoid the current problems. My point is that there are other, far more important problems good folks at RFC Editor should work on. Nobody is saying that there is no solution for the problem. Sometimes, avoiding the problem is better than solving it. > Yes, but only if one has "wget" on their platform. I was also > thinking about other types of platforms such as smart phones, PDAs, > etc. Folks that care about platforms with e-mail and no http, folks that want to reboot their computers while fetching RFCs, folks that want RFC translations, folks behind overly restrictive firewalls, etc. etc. are welcome to setup their own proxies/services/wrappers/etc. Raw data is available for them. Again, IMO, accommodating all platforms/environments should not be the RFC Editor job, at least not today. Providing web access is sufficient to cover at least 95% of current use cases and no service will accommodate 100% of possible use cases. I was worried this question would end up in the discussion about weather RFC Editor is in business of helping politically oppressed folks to get RFCs. I did not expect it to turn into a discussion whether RFC Editor is in business of accommodating web-challenged platforms! -oo- Alex. From mallman@guns.icir.org Thu Apr 1 06:06:45 2004 Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i31E6eq22001 for ; Thu, 1 Apr 2004 06:06:40 -0800 (PST) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 6462C77AA8D; Thu, 1 Apr 2004 09:06:34 -0500 (EST) To: Alex Rousskov From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Murder Incorporated MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 01 Apr 2004 09:06:34 -0500 Sender: mallman@guns.icir.org Message-Id: <20040401140634.6462C77AA8D@guns.icir.org> X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mallman@guns.icir.org Subject: Re: [rfc-i] rfc-info needs your help! Cc: rfc-interest@rfc-editor.org, Bob Hinden X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: mallman@icir.org List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 14:06:46 -0000 --=-=-= > 3. Drop the service all together. Let people use the RFC Editor web > and ftp services to retrieve documents. This seems undesirable as the > service does get used and there are places where web access is > limited. We'd strongly like to preserve email as a method of > retrieving RFCs. Note the part where the rfc-ed says "this service does get used". I think your opinion has been noted at this point. Why does everything have to be a long and drawn out discussion in the IETF? We don't know what is important and what is not. I thought it was pretty clear from the original message that they wanted to preserve the service and not incur great cost in doing so (e.g., they didn't even sound like they were willing to upgrade the hardware - which would be a pretty cheap undertaking). Why do folks feel like they need to micro-manage everything the rfc-ed does? If the rfc-ed does not tackle this little problem do you think there will be a noticeable increase in their output rate? Why are we engaged in this hairsplitting? Go review a document in last call. It will help much more than continuing this thresd. Sheesh! (Yeah, I should be sentenced to two last call documents.) allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAbCHqWyrrWs4yIs4RAmpMAJ9qX5q/MOu1x08Hsu0WHqIQ9uPsoACeNqv6 MsrJAT0dVbgcb8aCCaJCG7s= =6blD -----END PGP SIGNATURE----- --=-=-=-- From braden@ISI.EDU Thu Apr 1 11:50:31 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i31Jo3N20511 for ; Thu, 1 Apr 2004 11:50:03 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA28180 for rfc-interest; Thu, 1 Apr 2004 11:50:02 -0800 (PST) Date: Thu, 1 Apr 2004 11:50:02 -0800 (PST) Message-Id: <200404011950.LAA28180@gra.isi.edu> To: rfc-interest@ISI.EDU X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: Subject: [rfc-i] RFCs as important historical documents X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 19:50:31 -0000 The early RFCs contain many interesting gems. Recently I was looking for a reference for protocol layering, and I found a statement of the layering principle in RFC 46, April 1970, by Ed Meyer of MIT. Bob Braden From braden@ISI.EDU Thu Apr 1 13:33:34 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i31LWfN11030; Thu, 1 Apr 2004 13:32:41 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA28286; Thu, 1 Apr 2004 13:32:40 -0800 (PST) Date: Thu, 1 Apr 2004 13:32:40 -0800 (PST) Message-Id: <200404012132.NAA28286@gra.isi.edu> To: rfc-interest@rfc-editor.org, paul.hoffman@vpnc.org Subject: Re: [rfc-i] rfc-info needs your help! X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 21:33:40 -0000 *> There are lots of useful services that the RFC Editor can provide *> that will be of greater value to a larger audience, possibly for the *> same amount of effort as dealing with this service as viruses and *> spam get worse. *> Paul, We welcome suggestions. Bob Braden *> --Paul Hoffman, Director *> --VPN Consortium *> _______________________________________________ *> rfc-interest mailing list *> rfc-interest@rfc-editor.org *> http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> From braden@ISI.EDU Fri Apr 2 12:29:52 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i32KT5N10311; Fri, 2 Apr 2004 12:29:05 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id MAA28544; Fri, 2 Apr 2004 12:29:05 -0800 (PST) Date: Fri, 2 Apr 2004 12:29:05 -0800 (PST) Message-Id: <200404022029.MAA28544@gra.isi.edu> To: rfc-editor@rfc-editor.org, cbm@rose.hp.com X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@ISI.EDU Subject: [rfc-i] Re: authors 48 hours: RFC 3720 NOW AVAILABLE X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2004 20:29:53 -0000 *> *> As I mentioned in an offline note, I'd also *> suggest that the email addresses of the *> authors be documented in a way that makes *> it harder for email harvesting programs. One *> simple change could be to replace "@" with "[at]" *> (as in my signature below). *> Hi, Suppose all future RFCs used [at] instead of @. Wouldn't the email harvesters just change their code to check for either string? It does not seem like a big win in the long run. Bob Braden for the RFC Editor *> Thank you. *> -- *> Mallikarjun *> *> Mallikarjun Chadalapaka *> Networked Storage Architecture *> Network Storage Solutions *> Hewlett-Packard MS 5668 *> Roseville CA 95747 *> cbm [at] rose.hp.com *> From falk@ISI.EDU Sat Apr 3 07:51:46 2004 Received: from [192.168.1.3] (dsl081-036-151.lax1.dsl.speakeasy.net [64.81.36.151]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i33FosN01403 for ; Sat, 3 Apr 2004 07:50:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-38--378968161" Message-Id: Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! Date: Sat, 3 Apr 2004 07:50:46 -0800 To: rfc-interest@rfc-editor.org X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 15:51:47 -0000 --Apple-Mail-38--378968161 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed FYI, this is from about a week of the the current rfc-info log showing the system gets used a small amount largely by folks from the more remote edges of the net, IMO. (.cu is cuba, .es is spain, .ru is russia) I've anonymized it a bit but left the domains of the requesters. --aaron 03/26/104 03:06:00 [RETRIEVE] xxxxxxx@tsm.es File 'RFC2557.ASCII' sent in segments via email. 03/26/104 03:37:52 [RETRIEVE] xxxxxxx@tsm.es File 'RFC2045.ASCII' sent in segments via email. 03/26/104 04:59:09 [RETRIEVE] xxxxxxx@tsm.es File 'RFC2231.ASCII' sent via email. 03/26/104 20:08:06 [RETRIEVE] "xxxx@xxxxxx.com.cn" 3721 matching records sent as LIST. 03/28/104 21:11:47 [RETRIEVE] "xxxxxxx" 38 matching records sent as LIST. 03/29/104 00:17:05 [RETRIEVE] xxxxxxx@tsm.es File 'RFC2046.ASCII' sent in segments via email. 03/29/104 00:17:17 [RETRIEVE] xxxxxxx@tsm.es File 'RFC2047.ASCII' sent via email. 03/29/104 00:29:51 [RETRIEVE] xxxxxxx@tsm.es File 'RFC0822.ASCII' sent in segments via email. 03/29/104 02:01:59 [RETRIEVE] xxxxxxxxx File 'RFC0793.ASCII' sent in segments via email. 03/29/104 07:30:17 [RETRIEVE] xxxxxxxxxxx File 'RFC1060.ASCII' sent in segments via email. 03/29/104 07:46:13 [RETRIEVE] xxxxxxxxxxx File 'RFC1060.ASCII' sent in segments via email. 03/29/104 08:38:55 [RETRIEVE] xxxxxxxxxxxxxxxxxxxxxxxx File 'RFC1500.ASCII' sent in segments via email. 03/30/104 00:59:52 [RETRIEVE] xxxxxxxxxxxx File 'RFC2617.ASCII' sent in segments via email. 03/31/104 22:32:40 [RETRIEVE] "?????? ?. ?????????" File 'RFC2049.ASCII' sent in segments via email. 03/31/104 23:34:33 [RETRIEVE] "?????? ?. ?????????" File 'RFC2047.ASCII' sent via email. 03/31/104 23:34:44 [RETRIEVE] "?????? ?. ?????????" File 'RFC2045.ASCII' sent in segments via email. 03/31/104 23:34:55 [RETRIEVE] "?????? ?. ?????????" File 'RFC2046.ASCII' sent in segments via email. 04/01/104 05:56:41 [RETRIEVE] "xxxxx" File 'RFC1115.ASCII' sent via email. 04/01/104 05:56:59 [RETRIEVE] "xxxxx" File 'RFC1319.ASCII' sent via email. 04/01/104 05:57:17 [RETRIEVE] "xxxxx" File 'RFC1423.ASCII' sent via email. 04/01/104 05:57:37 [RETRIEVE] "xxxxx" File 'RFC1507.ASCII' sent in segments via email. 04/01/104 05:57:54 [RETRIEVE] "xxxxx" File 'RFC2313.ASCII' sent via email. 04/01/104 05:58:10 [RETRIEVE] "xxxxx" File 'RFC2313.ASCII' sent via email. 04/01/104 05:58:27 [RETRIEVE] "xxxxx" File 'RFC2440.ASCII' sent in segments via email. 04/01/104 05:58:43 [RETRIEVE] "xxxxx" File 'RFC2459.ASCII' sent in segments via email. 04/01/104 05:59:00 [RETRIEVE] "xxxxx" File 'RFC2660.ASCII' sent in segments via email. 04/01/104 05:59:17 [RETRIEVE] "xxxxx" File 'RFC1186.ASCII' sent via email. 04/01/104 05:59:34 [RETRIEVE] "xxxxx" File 'RFC1828.ASCII' sent via email. 04/01/104 05:59:52 [RETRIEVE] "xxxxx" File 'RFC1864.ASCII' sent via email. 04/01/104 06:00:11 [RETRIEVE] "xxxxx" File 'RFC2082.ASCII' sent via email. 04/01/104 06:00:31 [RETRIEVE] "xxxxx" File 'RFC2085.ASCII' sent via email. 04/01/104 06:00:50 [RETRIEVE] "xxxxx" File 'RFC2385.ASCII' sent via email. 04/01/104 06:01:08 [RETRIEVE] "xxxxx" File 'RFC2537.ASCII' sent via email. 04/01/104 07:00:25 [RETRIEVE] "xxxxx" File 'RFC1320.ASCII' sent via email. 04/01/104 07:00:35 [RETRIEVE] "xxxxx" File 'RFC1991.ASCII' sent via email. 04/01/104 07:00:47 [RETRIEVE] "xxxxx" File 'RFC2437.ASCII' sent in segments via email. 04/01/104 07:00:57 [RETRIEVE] "xxxxx" File 'RFC3110.ASCII' sent via email. 04/01/104 07:01:08 [RETRIEVE] "xxxxx" File 'RFC3280.ASCII' sent in segments via email. 04/01/104 10:33:02 [RETRIEVE] xxxxxxxxxxxxxxxxxx File 'RFC2229.ASCII' sent in segments via email. 04/01/104 21:39:34 [RETRIEVE] "xxxxxx" File 'RFC0822.ASCII' sent in segments via email. 04/01/104 22:08:03 [RETRIEVE] "xxxxxxxxxxxxxxxxxxxxxx" File 'RFC0821.ASCII' sent in segments via email. 04/01/104 23:28:19 [RETRIEVE] xxxxxxxxxxxxxxxxxx File 'RFC2229.ASCII' sent in segments via email. 04/02/104 07:52:25 [RETRIEVE] "xxxxx" File 'RFC3125.ASCII' sent in segments via email. 04/02/104 12:32:33 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1245.ASCII' sent via email. 04/02/104 12:32:47 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1247.PS' sent in segments via email. 04/02/104 12:50:14 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1010.ASCII' sent in segments via email. 04/02/104 13:20:36 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1010.ASCII' sent in segments via email. 04/02/104 13:36:34 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1010.ASCII' sent in segments via email. 04/02/104 13:37:47 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1245.ASCII' sent via email. 04/02/104 13:38:08 [RETRIEVE] xxxxxxxxxx@belcorp.biz File 'RFC1247.PS' sent in segments via email. --Apple-Mail-38--378968161 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAbt1X/i95hBY97NERAm3UAJ9Fm1cUC4EPyGI8A/OTVFdry14pOgCdEAVc v9DlG7aWfh7O+9PuVjnvhVQ= =eiDY -----END PGP SIGNATURE----- --Apple-Mail-38--378968161-- From harald@alvestrand.no Sat Apr 3 12:49:08 2004 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i33KmuN11286 for ; Sat, 3 Apr 2004 12:48:57 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6123C61BDE; Sat, 3 Apr 2004 22:48:55 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30942-03; Sat, 3 Apr 2004 22:48:54 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 245F561B7E; Sat, 3 Apr 2004 22:48:53 +0200 (CEST) Date: Sat, 03 Apr 2004 12:45:48 -0800 From: Harald Tveit Alvestrand To: Aaron Falk , rfc-interest@rfc-editor.org Subject: Re: [rfc-i] rfc-info needs your help! Message-ID: <68997423.1080996348@localhost> In-Reply-To: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2004 20:49:08 -0000 after watching the discussion for a while..... one suggestion: add to the beginning of the mail that gets sent out in reply to requests: -------------------------------------------------------------- The RFC Editor is currently evaluating this service. If you want to speak out in favour of the service being continued, please send a message to rfc-interest@rfc-editor.org. If no users speak in its favour, it will be turned off on June 1, 2004. ----------------------------------------------------------- Either someone reacts, and we can discuss it with the real users, or nobody cares.... Harald From john+rfc@jck.com Sun Apr 4 10:26:29 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i34HPwN23242 for ; Sun, 4 Apr 2004 10:25:58 -0700 (PDT) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 1BABNc-000AES-00 for rfc-interest@rfc-editor.org; Sun, 04 Apr 2004 12:25:57 -0500 Date: Sun, 04 Apr 2004 13:25:53 -0400 From: John C Klensin To: rfc-interest@rfc-editor.org Subject: Re: [rfc-i] rfc-info needs your help! Message-ID: <3111967.1081085153@[10.1.1.14]> In-Reply-To: <200403311940.i2VJeKq15931@boreas.isi.edu> References: <200403311940.i2VJeKq15931@boreas.isi.edu> X-Mailer: Mulberry/3.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 17:26:29 -0000 --On Wednesday, March 31, 2004 Alex Rousskov wrote: >... > IMO, RFC Editor should not be in business of providing > backdoor to those who try to circumvent local policies (even > if those policies are considered evil by IETF majority). > Others like friends and colleagues abroad can provide such > backdoors. Alex, Sorry, but the above would be reasonable if there were strong evidence that the blockage was an intentional and accurate implementation of local policy. But the vast majority of these blockages which email can get around fall into one of two categories... (1) A policy is implemented in a way that blocks facilities and information to which the policy doesn't actually apply, at least intentionally. This case is pretty common and we are not helping someone "circumvent local policies" but to work around an intended bit of wrong-coding over which they have no control. (2) A policy, possibly by the individual trying to obtain the information, that recognizes the existence of time-of-day pricing, or high prices for "online internationally" time on Internet access and/or mail gateways that are set up to let large files through only when critical links are not seriously congested. "Send this to me by mail" automatically handles the latter and may help considerably with the first. john From henrik@levkowetz.com Wed Apr 7 12:31:27 2004 Received: from mailgw.local.ipunplugged.com (213.80.52.78.dataphone.se [213.80.52.78] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i37JUkN04629 for ; Wed, 7 Apr 2004 12:30:46 -0700 (PDT) Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i37JUaYK005628; Wed, 7 Apr 2004 21:30:36 +0200 Date: Wed, 7 Apr 2004 21:30:38 +0200 From: Henrik Levkowetz To: rfc-interest@rfc-editor.org Message-Id: <20040407213038.7820d0aa.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.70rc, clamav-milter version 0.70 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: henrik@levkowetz.com Subject: [rfc-i] Discrepancy between 3667 specified Copyright text and current practice X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2004 19:31:27 -0000 Hi, I'm currently working on adding rfc 3667 compliance checks to the idnits tool (http://mip4.org/tools/idnits/), and came across a discrepancy between the full copyright text as given in 3667 Section 5.4, and the one used in recently published RFCs. RFC 3667, Section 5.4 specifies this text: "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." while recently published RFCs say: "Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights." Notice the omitted comma after "78" in the latter version. Is this a mistake or an intentional deviation? What should I have the idnits tool check compliance with? Regards, Henrik From braden@ISI.EDU Thu Apr 8 11:27:46 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i38IRZN05245 for ; Thu, 8 Apr 2004 11:27:35 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA01192 for rfc-interest; Thu, 8 Apr 2004 11:27:35 -0700 (PDT) Date: Thu, 8 Apr 2004 11:27:35 -0700 (PDT) Message-Id: <200404081827.LAA01192@gra.isi.edu> To: rfc-interest@ISI.EDU X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: Subject: [rfc-i] The hazards of being an editor... X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2004 18:27:47 -0000 An RFC author sent us the following during the authors' 48 hour review: *> *> *> Page 15 (This one I am not sure, but believe the ',' must be outside *> the quotes): *> OLD: *> In order to apply the the template to all interfaces that have a role *> match of "Administrator," *> *> NEW: *> In order to apply the the template to all interfaces that have a role *> match of "Administrator", *> ^^^^^^^^^^^^^^^^ *> We replied: Ah, that problem! Strunk & White, "The Elements of Style," say: Typographical usage dictates that the comma be inside the marks, though logically it often seems not to belong there. The RFC Editor prides itself on being logical, so we are willing to accept either form. However, the Gods of Syntax do seem to favor ," RFC Editor From john+rfc@jck.com Fri Apr 9 11:59:51 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i39Iw7N10543 for ; Fri, 9 Apr 2004 11:58:07 -0700 (PDT) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1BC1CZ-000IqD-00 for rfc-interest@rfc-editor.org; Fri, 09 Apr 2004 13:58:07 -0500 Date: Fri, 09 Apr 2004 14:58:06 -0400 From: John C Klensin To: rfc-interest@rfc-editor.org Subject: Re: [rfc-i] rfc-info needs your help! Message-ID: <247963773.1081522686@scan.jck.com> In-Reply-To: <200404091809.i39I9aN19562@boreas.isi.edu> References: <200404091809.i39I9aN19562@boreas.isi.edu> X-Mailer: Mulberry/3.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2004 18:59:51 -0000 --On Thu, 01 Apr 2004 09:06:34 -0500, Mark Allman wrote, >> 3. Drop the service all together. Let people use the RFC >> Editor web and ftp services to retrieve documents. This >> seems undesirable as the service does get used and there are >> places where web access is limited. We'd strongly like to >> preserve email as a method of retrieving RFCs. > > Note the part where the rfc-ed says "this service does get > used". I think your opinion has been noted at this point. > Why does everything have to be a long and drawn out discussion > in the IETF? We don't know what is important and what is not. > I thought it was pretty clear from the original message that > they wanted to preserve the service and not incur great cost > in doing so (e.g., they didn't even sound like they were > willing to upgrade the hardware - which would be a pretty cheap > undertaking). Why do folks feel like they need to micro-manage > everything the rfc-ed does? If the rfc-ed does not tackle > this little problem do you think there will be a noticeable > increase in their output rate? Why are we engaged in this > hairsplitting? Go review a document in last call. It will > help much more than continuing this thresd. Sheesh! I have to agree with Mark, especially about the last couple of sentences above. And, without getting deep into political correctness, there really are folks who are seriously bandwidth and connectively challenged at various times for whom "mail it to me" is the only practical option for getting to materials that they actually need. Our cutting them off because they lack sufficient technology or connectivity is just not what we are supposed to be about. That said, if the RFC Editor doesn't have sufficient tools to tackle this directly, easily, and well (it certainly is not what I would consider a mainstream, critical-path task for them), I think I can identify several sites that might be willing to maintain a mirror of the RFC directory for this purpose and hook it up to an email responder. If a discussion on that topic would be useful, someone appropriate on the RFC Editor staff should contact me directly -- I can't imagine that the discussion would be a useful list topic. john From braden@ISI.EDU Fri Apr 9 14:08:21 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i39L7HN12544; Fri, 9 Apr 2004 14:07:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id OAA01712; Fri, 9 Apr 2004 14:07:17 -0700 (PDT) Date: Fri, 9 Apr 2004 14:07:17 -0700 (PDT) Message-Id: <200404092107.OAA01712@gra.isi.edu> To: rfc-interest@ISI.EDU X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org Subject: [rfc-i] 35th anniversary noted X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2004 21:08:23 -0000 We are two days late in noting this, but Wednesday was the 35th anniversary of the RFC series: Steve Crocker, "Host Software," RFC 1, 7 April 1969. It's online on the RFC Editor web site. RFC Editor From rousskov@measurement-factory.com Fri Apr 9 19:49:05 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3A2m2N16089 for ; Fri, 9 Apr 2004 19:48:02 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3A2luuH093237; Fri, 9 Apr 2004 20:47:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3A2ltwV093236; Fri, 9 Apr 2004 20:47:55 -0600 (MDT) (envelope-from rousskov) Date: Fri, 9 Apr 2004 20:47:55 -0600 (MDT) From: Alex Rousskov To: John C Klensin Subject: Re: [rfc-i] rfc-info needs your help! In-Reply-To: <3111967.1081085153@[10.1.1.14]> Message-ID: References: <200403311940.i2VJeKq15931@boreas.isi.edu> <3111967.1081085153@[10.1.1.14]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2004 02:49:06 -0000 John, We should probably close this thread until real users with real needs show up so that RFC Editor can evaluate their needs in relation to RFC Editor resources and priorities. There seems to be little information trickling in after the initial exchange. I suspect we are annoying RFC Editor folks more than helping them at this point... If you feel strongly about your points, please find a different opinion below... On Sun, 4 Apr 2004, John C Klensin wrote: > --On Wednesday, March 31, 2004 Alex Rousskov > wrote: > > > IMO, RFC Editor should not be in business of providing backdoor to > > those who try to circumvent local policies (even if those policies > > are considered evil by IETF majority). Others like friends and > > colleagues abroad can provide such backdoors. > > Sorry, but the above would be reasonable if there were strong > evidence that the blockage was an intentional and accurate > implementation of local policy. The above assertion was not meant to cover all cases. > But the vast majority of these blockages which email can get around > fall into one of two categories... > > (1) A policy is implemented in a way that blocks facilities and > information to which the policy doesn't actually apply, at least > intentionally. This case is pretty common and we are not helping > someone "circumvent local policies" but to work around an intended > bit of wrong-coding over which they have no control. IMO, RFC Editor should not be in business of providing backdoor to those who try to work around unintentional blocks and misconfigurations. > (2) A policy, possibly by the individual trying to obtain the > information, that recognizes the existence of time-of-day pricing, > or high prices for "online internationally" time on Internet access > and/or mail gateways that are set up to let large files through only > when critical links are not seriously congested. HTTP downloads are easily scheduled for times when the price is low and large downloads are easily split into small ones to be auto-assembled at the client side. The problems you are referring to are old and real. They have old and real solutions that do not have to involve RFC Editor as long as RFC Editor is providing a well functioning HTTP access to RFCs. > "Send this to me by mail" automatically handles the latter and may > help considerably with the first. ... but does not have to be the service offered by overloaded and resource-lacking RFC Editor, IMO. Alex. From harald@alvestrand.no Fri Apr 9 22:09:26 2004 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3A59CN05508 for ; Fri, 9 Apr 2004 22:09:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5287D61B9D; Sat, 10 Apr 2004 07:09:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05621-08; Sat, 10 Apr 2004 07:09:10 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4624A61A93; Sat, 10 Apr 2004 07:09:09 +0200 (CEST) Date: Fri, 09 Apr 2004 21:34:46 -0700 From: Harald Tveit Alvestrand To: Aaron Falk , rfc-interest@rfc-editor.org Subject: Re: [rfc-i] rfc-info needs your help! Message-ID: <197578392.1081546486@localhost> In-Reply-To: References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2004 05:09:27 -0000 Aaron, do I read this correctly as approximately 40 requests this week, from approximately 12 people? From braden@ISI.EDU Sat Apr 10 08:23:31 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3AFMYN26998; Sat, 10 Apr 2004 08:22:34 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id IAA02012; Sat, 10 Apr 2004 08:22:33 -0700 (PDT) Date: Sat, 10 Apr 2004 08:22:33 -0700 (PDT) Message-Id: <200404101522.IAA02012@gra.isi.edu> To: braden@ISI.EDU, rfc-interest@ISI.EDU, harald@alvestrand.no Subject: Re: [rfc-i] 35th anniversary noted X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2004 15:23:36 -0000 *> Bob, *> *> in an attack of totally irrelevant interest: *> do you know the story behind the fact that RFC 4 is dated *before* RFC 1? *> Harald, ;-) I don't have the foggiest. Maybe Steve Crocker knows, but more likely this little tidbit is lost in the sands of time... Bob *> Thanks for celebrating the birthday with us! *> *> Harald *> *> --On 9. april 2004 14:07 -0700 Bob Braden wrote: *> *> > *> > We are two days late in noting this, but Wednesday was the 35th *> > anniversary of the RFC series: Steve Crocker, "Host Software," RFC 1, 7 *> > April 1969. It's online on the RFC Editor web site. *> > *> > RFC Editor *> > _______________________________________________ *> > rfc-interest mailing list *> > rfc-interest@rfc-editor.org *> > http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> > *> > *> *> *> *> From braden@ISI.EDU Sat Apr 10 08:31:27 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3AFV3N28416 for ; Sat, 10 Apr 2004 08:31:03 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id IAA02022 for rfc-interest; Sat, 10 Apr 2004 08:31:03 -0700 (PDT) Date: Sat, 10 Apr 2004 08:31:03 -0700 (PDT) Message-Id: <200404101531.IAA02022@gra.isi.edu> To: rfc-interest@ISI.EDU X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: Subject: [rfc-i] Test -- please ignore X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2004 15:31:27 -0000 This is only a test. Had this been a real emergency... From harald@alvestrand.no Mon Apr 12 13:19:15 2004 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3CKHfN08009; Mon, 12 Apr 2004 13:17:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C41AD61BB3; Mon, 12 Apr 2004 22:17:39 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01016-04; Mon, 12 Apr 2004 22:17:39 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A0D261B9D; Mon, 12 Apr 2004 22:17:37 +0200 (CEST) Date: Mon, 12 Apr 2004 12:57:23 -0700 From: Harald Tveit Alvestrand To: Bob Braden , rfc-interest@rfc-editor.org Subject: Re: [rfc-i] 35th anniversary noted Message-ID: <425726372.1081774643@localhost> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: rfc-editor@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 20:19:18 -0000 (this is a resend) Bob, in an attack of totally irrelevant interest: do you know the story behind the fact that RFC 4 is dated *before* RFC 1? Thanks for celebrating the birthday with us! Harald --On 9. april 2004 14:07 -0700 Bob Braden wrote: > > We are two days late in noting this, but Wednesday was the 35th > anniversary of the RFC series: Steve Crocker, "Host Software," RFC 1, 7 > April 1969. It's online on the RFC Editor web site. > > RFC Editor > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest > > From rousskov@measurement-factory.com Mon Apr 12 13:36:26 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3CKZmN11587 for ; Mon, 12 Apr 2004 13:35:48 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3CKZguH027126 for ; Mon, 12 Apr 2004 14:35:42 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3CKZgfi027125; Mon, 12 Apr 2004 14:35:42 -0600 (MDT) (envelope-from rousskov) Date: Mon, 12 Apr 2004 14:35:42 -0600 (MDT) From: Alex Rousskov To: rfc-interest@rfc-editor.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Subject: [rfc-i] errata maintenance X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 20:36:26 -0000 Hi, With errata links now provided in RFC search results, are there any plans to improve errata maintenance itself (i.e., review, classification, and search of submitted errata) and subsequently "advertise" future errata availability in new RFCs? Do you want help in that direction? Or is RFC Editor more-or-less satisfied with how RFC errata is handled and advertised today? Thank you, Alex. From falk@ISI.EDU Mon Apr 12 14:18:27 2004 Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3CLHrN22088; Mon, 12 Apr 2004 14:17:53 -0700 (PDT) In-Reply-To: <197578392.1081546486@localhost> References: <51F05056-8334-11D8-8DCB-000A95DBDB84@ISI.EDU> <197578392.1081546486@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22-418257677" Message-Id: Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] rfc-info needs your help! Date: Mon, 12 Apr 2004 14:17:52 -0700 To: Harald Tveit Alvestrand X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2004 21:18:27 -0000 --Apple-Mail-22-418257677 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed (digging out post-vacation...) On Apr 9, 2004, at 9:34 PM, Harald Tveit Alvestrand wrote: > Aaron, > > do I read this correctly as approximately 40 requests this week, from > approximately 12 people? > Yes. I purged the log of non-valid requests (of which there were about 1200, IIRC). --aaron --Apple-Mail-22-418257677 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAeweA/i95hBY97NERAmYLAJ0bbt5EGBuvl4aCizfVVWn6gKp71wCfX3xp TJM7a/FFISS6TVLWpnqAqM4= =Vo+i -----END PGP SIGNATURE----- --Apple-Mail-22-418257677-- From mcr@sandelman.ottawa.on.ca Mon Apr 12 18:57:30 2004 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3D1v5N19157 for ; Mon, 12 Apr 2004 18:57:06 -0700 (PDT) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3D1v0g27836 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 12 Apr 2004 21:57:03 -0400 (EDT) Received: from sandelman.ottawa.on.ca (dhcp-61.toronto.xelerance.com [209.112.44.61]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i3D219e19034 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 12 Apr 2004 22:01:12 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3D1tZ7F010697 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 12 Apr 2004 21:55:35 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3D1tYoX010693 for ; Mon, 12 Apr 2004 21:55:34 -0400 To: rfc-interest X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Mon, 12 Apr 2004 21:55:34 -0400 Message-ID: <10692.1081821334@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: mcr@sandelman.ottawa.on.ca Subject: [rfc-i] whimsical X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 01:57:31 -0000 while discussing the RFC-editor queue with a colleague, an additional participant joined us. Please see: http://www.sandelman.ca/tmp/shikaku-rfc-editor.org.1.jpg The cat is named Shikaku. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From paul.hoffman@vpnc.org Tue Apr 13 09:10:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DGAiN25443 for ; Tue, 13 Apr 2004 09:10:44 -0700 (PDT) Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DGAXKS052885; Tue, 13 Apr 2004 09:10:34 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 13 Apr 2004 08:06:23 -0700 To: Alex Rousskov , rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] errata maintenance Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 16:10:53 -0000 At 2:35 PM -0600 4/12/04, Alex Rousskov wrote: > With errata links now provided in RFC search results, are >there any plans to improve errata maintenance itself (i.e., review, >classification, and search of submitted errata) and subsequently >"advertise" future errata availability in new RFCs? Do you want help >in that direction? Or is RFC Editor more-or-less satisfied with how >RFC errata is handled and advertised today? Most IETF folks still don't know (or don't remember) the RFC errata. Maybe the RFC Editor can put together a nice announcement about it for WG chairs to distribute to their mailing lists. There will probably be a flood of editorial nits immediately afterward, but there will also be greater awareness of the service. --Paul Hoffman, Director --VPN Consortium From jkrey@ISI.EDU Tue Apr 13 09:11:09 2004 Received: from akamai.isi.edu (akamai.isi.edu [128.9.160.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i3DG9HN25022; Tue, 13 Apr 2004 09:09:17 -0700 (PDT) Message-Id: <200404131609.i3DG9HN25022@boreas.isi.edu> Date: Tue, 13 Apr 2004 09:09:17 -0700 (PDT) From: Joyce Reynolds Subject: Re: [rfc-i] whimsical To: mcr@sandelman.ottawa.on.ca MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mUR0rYkgJbg4S1LVXlg7sQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: jkrey@boreas.isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Joyce Reynolds List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 16:11:11 -0000 Michael, Wonderful! It truly proves that on the Internet, nobody knows you're a dog, OR a cat, for that matter! Actually, I think I see TWO participants in the picture. I am glad they like purusing the RFC Editor web pages. Made my day. Thanks, Joyce ("owned" by three cats - Beau, Clementine, and Chatty) From rousskov@measurement-factory.com Tue Apr 13 09:51:54 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DGpCN06841 for ; Tue, 13 Apr 2004 09:51:12 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3DGpBuH069439; Tue, 13 Apr 2004 10:51:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3DGpBBU069438; Tue, 13 Apr 2004 10:51:11 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Apr 2004 10:51:11 -0600 (MDT) From: Alex Rousskov To: Paul Hoffman / VPNC Subject: Re: [rfc-i] errata maintenance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 16:51:54 -0000 On Tue, 13 Apr 2004, Paul Hoffman / VPNC wrote: > Most IETF folks still don't know (or don't remember) the RFC errata. Not to mention the _users_ of IETF specs, a far larger and arguably more important group than IETF folks. > Maybe the RFC Editor can put together a nice announcement about it > for WG chairs to distribute to their mailing lists. There will > probably be a flood of editorial nits immediately afterward, but > there will also be greater awareness of the service. I would only do the above if RFC Editor considers the current errata maintenance mechanisms satisfactory. Otherwise, it is a bad idea to solicit more errata until the maintenance is fixed. In fact, that's one of the reasons I asked the question. I am trying to decide whether it is worth the effort or even possible to submit my errata now, given the submission rules and [lack of] maintenance mechanisms. Good errata maintenance is difficult and I want to know whether RFC Editor cares about errata and has the desire/resources to maintain it. Alex. From pekkas@netcore.fi Tue Apr 13 10:11:48 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DHBUN11259 for ; Tue, 13 Apr 2004 10:11:30 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3DHBAv03926; Tue, 13 Apr 2004 20:11:10 +0300 Date: Tue, 13 Apr 2004 20:11:10 +0300 (EEST) From: Pekka Savola To: Alex Rousskov Subject: Re: [rfc-i] errata maintenance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: pekkas@netcore.fi Cc: rfc-interest@rfc-editor.org, Paul Hoffman / VPNC X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 17:11:49 -0000 On Tue, 13 Apr 2004, Alex Rousskov wrote: > On Tue, 13 Apr 2004, Paul Hoffman / VPNC wrote: > > > Most IETF folks still don't know (or don't remember) the RFC errata. > > Not to mention the _users_ of IETF specs, a far larger and arguably > more important group than IETF folks. Speaking of which, the IETF should add a pointer/heads-up at http://www.ietf.org/rfc.html. (Not sure that folks are using that either, but it's the only place to put it at on IETF pages unless you would consider some kind of standard boilerplate in the future documents themselves.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From braden@ISI.EDU Tue Apr 13 10:17:51 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DHHKN12608; Tue, 13 Apr 2004 10:17:20 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA02845; Tue, 13 Apr 2004 10:17:20 -0700 (PDT) Date: Tue, 13 Apr 2004 10:17:20 -0700 (PDT) Message-Id: <200404131717.KAA02845@gra.isi.edu> To: rfc-interest@rfc-editor.org, rousskov@measurement-factory.com Subject: Re: [rfc-i] errata maintenance X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 17:17:53 -0000 *> *> Hi, *> *> With errata links now provided in RFC search results, are *> there any plans to improve errata maintenance itself (i.e., review, *> classification, and search of submitted errata) and subsequently *> "advertise" future errata availability in new RFCs? Do you want help *> in that direction? Or is RFC Editor more-or-less satisfied with how *> RFC errata is handled and advertised today? *> *> Thank you, *> *> Alex. *> _______________________________________________ Alex, We are puzzled about what you are concerned about here. What do you mean by "maintenance"? Entries are reviewed by the authors, which seems to work satisfactorily. We don't classify them, although this might be a good idea. We don't currently advertise new errata entries, so we cannot claim to be satisfied with how we do advertise them. It is not obvious that advertisement is useful/necessary. Their existence is now shown on the search engine for new readers. If you had previously used some document for implementation, you would presumably have noticed any substantive typographic error yourself, and telling you later that someone else has noticed it and taken the trouble to report it seems gratuitous. RFC Editor From bob.hinden@nokia.com Tue Apr 13 10:25:49 2004 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DHOvN14428 for ; Tue, 13 Apr 2004 10:24:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i3DHOiU18356; Tue, 13 Apr 2004 10:24:44 -0700 X-mProtect: <200404131724> Nokia Silicon Valley Messaging Protection Received: from h164.hinden.meer.net (209.157.142.164, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdrCzPtb; Tue, 13 Apr 2004 10:24:42 PDT Message-Id: <4.3.2.7.2.20040413102137.030ba528@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Apr 2004 10:23:18 -0700 To: Pekka Savola From: Bob Hinden Subject: Re: [rfc-i] errata maintenance In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: bob.hinden@nokia.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 17:25:49 -0000 >Speaking of which, the IETF should add a pointer/heads-up at >http://www.ietf.org/rfc.html. (Not sure that folks are using that >either, but it's the only place to put it at on IETF pages unless you >would consider some kind of standard boilerplate in the future >documents themselves.) Not sure anyone suggested this yet but another approach might be to add some boiler plate to each new RFC pointing to the errata page. Bob From rousskov@measurement-factory.com Tue Apr 13 10:59:57 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DHxSN22810 for ; Tue, 13 Apr 2004 10:59:28 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3DHxPuH071569; Tue, 13 Apr 2004 11:59:26 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3DHxPpd071568; Tue, 13 Apr 2004 11:59:25 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Apr 2004 11:59:25 -0600 (MDT) From: Alex Rousskov To: Bob Braden Subject: Re: [rfc-i] errata maintenance In-Reply-To: <200404131717.KAA02845@gra.isi.edu> Message-ID: References: <200404131717.KAA02845@gra.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 17:59:58 -0000 On Tue, 13 Apr 2004, Bob Braden wrote: > We are puzzled about what you are concerned about here. What do you > mean by "maintenance"? Pretty much everything including errata solicitations, submissions, review, publication, and search. As usual, there is hardly a single problem that can be easily described (not to mention fixed) in isolation: 0) publication/marketing In my experience, only a negligible number of folks who read and implement RFCs know that there might be an errata for those RFCs. In other words, errata does not exist for any practical purpose. Side effect: folks do not submit new errors. 1) solicitation There is no meaningful solicitation of errata from RFC readers. While the "Status of this Memo" section says that the document "requests discussion and suggestions for improvements", there is no obvious way to discuss and suggest short to spamming authors which most readers will not do for many reasons. 2) submission If a user is lucky to find submission instructions[1], submission itself is easy but informal: just send an e-mail to rfc-editor. Side effect: RFC Editor is unlikely to be able to cope with significant errata volumes, even if we are lucky enough to get them. 3) review > Entries are reviewed by the authors, which seems to work > satisfactorily. According to submission instructions[1], author or IESG review is required _before_ technical errata is submitted (i.e., before there is an errata entry). Thus, at least from a procedural point of view, the RFC Editor does not see entries rejected or ignored by authors and, hence, I am not sure you can claim satisfactorily performance of such reviews unless you know that most folks ignore your instructions and submit unreviewed errors that RFC Editor then forwards to authors for a review. Contacting authors (not to mention IESG!) directly creates an entry barrier that most (IMO) folks who spot an error will not overcome, for time, cultural, and technical reasons. I can create a more detailed list, but I am sure you know what those reasons are. AFAIK, there is no good documented mechanism to review/appeal an errata entry once it is published (not to mention rejected). 4) publication and search AFAIK, there is no good mechanism to track the status of an errata. My guess is that most submitted entries eventually show up on the page and some might be removed later. I do not know if RFC authors and WG are informed that there is new errata, and I am not sure there is a way to track what errors were addressed in later RFCs. The above is not an exhaustive list, of course. For example, I have not mentioned errata pages maintained by folks other than RFC Editor but linked from RFC Editor errata page. Those pages are governed by their own set of rules. > It is not obvious that advertisement is useful/necessary. Their > existence is now shown on the search engine for new readers. Which, I bet, the vast majority of RFC readers do not use. > If you had previously used some document for implementation, you > would presumably have noticed any substantive typographic error > yourself, and telling you later that someone else has noticed it and > taken the trouble to report it seems gratuitous. Typographical errors do not bother my much. There are more than enough technical errors in core protocols such as HTTP that create real problems. I bet that thousands of hours are wasted globally on [not] fixing problems already known as errata to some. I thought it would be obvious, but apparently I was wrong! Alex. [1] http://www.rfc-editor.org/errata.html From pekkas@netcore.fi Tue Apr 13 11:09:50 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DI95N25258 for ; Tue, 13 Apr 2004 11:09:05 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3DI8rn04709; Tue, 13 Apr 2004 21:08:53 +0300 Date: Tue, 13 Apr 2004 21:08:53 +0300 (EEST) From: Pekka Savola To: Bob Hinden Subject: Re: [rfc-i] errata maintenance In-Reply-To: <4.3.2.7.2.20040413102137.030ba528@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: pekkas@netcore.fi Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 18:09:50 -0000 On Tue, 13 Apr 2004, Bob Hinden wrote: > >Speaking of which, the IETF should add a pointer/heads-up at > >http://www.ietf.org/rfc.html. (Not sure that folks are using that > >either, but it's the only place to put it at on IETF pages unless you > >would consider some kind of standard boilerplate in the future > >documents themselves.) > > Not sure anyone suggested this yet but another approach might be to add > some boiler plate to each new RFC pointing to the errata page. Yep, that's a possibility. If so, maybe along the lines of: RFCs are forever; an RFC is never modified after publication. However, RFCs can be reclassified: made historic, obsoleted completely, or updated by subsequent RFCs. The current status of an RFC must be checked in the RFC index [URL], not in the document itself. Editorial errata for RFCs is also available at [URL2]. If we'd go down that route, I'd consider coining up very simple URLs to be used, like: www.rfc-editor.org/status/ www.rfc-editor.org/status/1234 [shows the status of RFC1234] www.rfc-editor.org/errata/ www.rfc-editor.org/errata/1234 [shows the errata for RFC1234] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From braden@ISI.EDU Tue Apr 13 11:29:56 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DITeN29939; Tue, 13 Apr 2004 11:29:40 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA02972; Tue, 13 Apr 2004 11:29:40 -0700 (PDT) Date: Tue, 13 Apr 2004 11:29:40 -0700 (PDT) Message-Id: <200404131829.LAA02972@gra.isi.edu> To: bob.hinden@nokia.com, pekkas@netcore.fi Subject: Re: [rfc-i] errata maintenance X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 18:29:56 -0000 *> *> If we'd go down that route, I'd consider coining up very simple URLs *> to be used, like: *> *> www.rfc-editor.org/status/ *> www.rfc-editor.org/status/1234 [shows the status of RFC1234] *> www.rfc-editor.org/errata/ *> www.rfc-editor.org/errata/1234 [shows the errata for RFC1234] *> How about one simple URL: www.rfc-editor.org/rfcsearch.html? It's already there. Bob Braden *> *> -- *> Pekka Savola "You each name yourselves king, yet the *> Netcore Oy kingdom bleeds." *> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings *> From harald@alvestrand.no Tue Apr 13 11:36:35 2004 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DIZjN01448 for ; Tue, 13 Apr 2004 11:35:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C06A61BE6; Tue, 13 Apr 2004 20:35:44 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02541-10; Tue, 13 Apr 2004 20:35:43 +0200 (CEST) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCE3361A93; Tue, 13 Apr 2004 20:35:41 +0200 (CEST) Date: Tue, 13 Apr 2004 11:17:27 -0700 From: Harald Tveit Alvestrand To: Bob Braden , rfc-interest@rfc-editor.org Subject: Re: [rfc-i] The hazards of being an editor... Message-ID: <506129756.1081855047@localhost> In-Reply-To: <200404081827.LAA01192@gra.isi.edu> References: <200404081827.LAA01192@gra.isi.edu> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 18:36:35 -0000 In this particular case, the gods of syntax are not only wrong, but actively malicious, and should be exorcised, not worshipped. The purpose of the quote is to isolate the token "Administrator", not to quote a sentence from another source; this is the most common use of quotes in RFCs, I believe. My opinion. Harald --On 8. april 2004 11:27 -0700 Bob Braden wrote: > > > An RFC author sent us the following during the authors' 48 hour review: > > *> > *> > *> Page 15 (This one I am not sure, but believe the ',' must be outside > *> the quotes): > *> OLD: > *> In order to apply the the template to all interfaces that have a > role *> match of "Administrator," > *> > *> NEW: > *> In order to apply the the template to all interfaces that have a > role *> match of "Administrator", > *> ^^^^^^^^^^^^^^^^ > *> > > We replied: > > Ah, that problem! Strunk & White, "The Elements of Style," say: > > Typographical usage dictates that the comma be inside the marks, > though logically it often seems not to belong there. > > The RFC Editor prides itself on being logical, so we are willing to accept > either form. However, the Gods of Syntax do seem to favor ," > > RFC Editor > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest > > From braden@ISI.EDU Tue Apr 13 11:41:53 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DIfYN02859; Tue, 13 Apr 2004 11:41:34 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA02999; Tue, 13 Apr 2004 11:41:34 -0700 (PDT) Date: Tue, 13 Apr 2004 11:41:34 -0700 (PDT) Message-Id: <200404131841.LAA02999@gra.isi.edu> To: braden@ISI.EDU, rfc-interest@rfc-editor.org, harald@alvestrand.no Subject: Re: [rfc-i] The hazards of being an editor... X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 18:41:55 -0000 *> From harald@alvestrand.no Tue Apr 13 11:36:52 2004 *> Date: Tue, 13 Apr 2004 11:17:27 -0700 *> From: Harald Tveit Alvestrand *> To: Bob Braden , rfc-interest@rfc-editor.org *> Subject: Re: [rfc-i] The hazards of being an editor... *> MIME-Version: 1.0 *> Content-Transfer-Encoding: 7bit *> Content-Disposition: inline *> X-Virus-Scanned: by amavisd-new at alvestrand.no *> X-ISI-4-28-6-MailScanner: Found to be clean, Found to be clean *> X-MailScanner-From: harald@alvestrand.no *> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on boreas.isi.edu *> X-Spam-Level: *> X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham *> version=2.63 *> *> In this particular case, the gods of syntax are not only wrong, but *> actively malicious, and should be exorcised, not worshipped. The purpose of *> the quote is to isolate the token "Administrator", not to quote a sentence *> from another source; this is the most common use of quotes in RFCs, I *> believe. *> *> My opinion. Harald, You are completely correct. I overlooked the fact that "Adminstrator" is a token in this case. thanks, Bob *> *> Harald *> *> --On 8. april 2004 11:27 -0700 Bob Braden wrote: *> *> > *> > *> > An RFC author sent us the following during the authors' 48 hour review: *> > *> > *> *> > *> *> > *> Page 15 (This one I am not sure, but believe the ',' must be outside *> > *> the quotes): *> > *> OLD: *> > *> In order to apply the the template to all interfaces that have a *> > role *> match of "Administrator," *> > *> *> > *> NEW: *> > *> In order to apply the the template to all interfaces that have a *> > role *> match of "Administrator", *> > *> ^^^^^^^^^^^^^^^^ *> > *> *> > *> > We replied: *> > *> > Ah, that problem! Strunk & White, "The Elements of Style," say: *> > *> > Typographical usage dictates that the comma be inside the marks, *> > though logically it often seems not to belong there. *> > *> > The RFC Editor prides itself on being logical, so we are willing to accept *> > either form. However, the Gods of Syntax do seem to favor ," *> > *> > RFC Editor *> > *> > _______________________________________________ *> > rfc-interest mailing list *> > rfc-interest@rfc-editor.org *> > http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> > *> > *> *> *> *> From gih@telstra.net Tue Apr 13 12:48:52 2004 Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DJm1N18724 for ; Tue, 13 Apr 2004 12:48:01 -0700 (PDT) Received: from gihz1.telstra.net (dhcp16.potaroo.net [203.10.60.16]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i3DJlNuW099997; Wed, 14 Apr 2004 05:47:24 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040414054508.01c15a38@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 14 Apr 2004 05:47:05 +1000 To: Bob Braden , bob.hinden@nokia.com, pekkas@netcore.fi From: Geoff Huston Subject: Re: [rfc-i] errata maintenance In-Reply-To: <200404131829.LAA02972@gra.isi.edu> References: <200404131829.LAA02972@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: gih@telstra.net Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 19:48:52 -0000 At 04:29 AM 14/04/2004, Bob Braden wrote: > *> > *> If we'd go down that route, I'd consider coining up very simple URLs > *> to be used, like: > *> > *> www.rfc-editor.org/status/ > *> www.rfc-editor.org/status/1234 [shows the status of RFC1234] > *> www.rfc-editor.org/errata/ > *> www.rfc-editor.org/errata/1234 [shows the errata for RFC1234] > *> > >How about one simple URL: > > www.rfc-editor.org/rfcsearch.html? > >It's already there. I would disagree with this assertion - Pekka is asking for a means to reference a document and associated errata. This is not the same as a reference to a search engine. Geoff From john+rfc@jck.com Tue Apr 13 15:02:20 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DM1gN20533 for ; Tue, 13 Apr 2004 15:01:42 -0700 (PDT) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1BDVyP-0005Su-00 for rfc-interest@rfc-editor.org; Tue, 13 Apr 2004 17:01:41 -0500 Date: Tue, 13 Apr 2004 18:01:41 -0400 From: John C Klensin To: rfc-interest@rfc-editor.org Message-ID: <158438973.1081879301@scan.jck.com> In-Reply-To: <200404131809.i3DI9rN25337@boreas.isi.edu> References: <200404131809.i3DI9rN25337@boreas.isi.edu> X-Mailer: Mulberry/3.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com Subject: [rfc-i] Committee for opposing more tedious boilerplate (was: errata maintenance) X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 22:02:20 -0000 >> Not sure anyone suggested this yet but another approach might >> be to add some boiler plate to each new RFC pointing to the >> errata page. > > Yep, that's a possibility. If so, maybe along the lines of: > > RFCs are forever; an RFC is never modified after publication. > However, RFCs can be reclassified: made historic, obsoleted > completely, or updated by subsequent RFCs. The current > status of an RFC must be checked in the RFC index [URL], not > in the document itself. Editorial errata for RFCs is also > available at [URL2]. _Please_ let's not go down this path. RFCs have already ended up with an unpleasant ratio of boilerplate to informational content (unless they are already _very_ long). There is ample evidence that, when boilerplate gets long enough --and we are almost certainly past that limit already-- people don't read the stuff. It registers as boilerplate, and then they start searching for whatever they are really looking for. That, in turn, can be bad news, since they may skip something that really is important. Suggestion: A case can be made that all sorts of information that is not now present in RFCs would be useful -- pointers to the index for status material and to errata, information about contacting the IETF about Standards Track material, suggestions about how to locate authors if the address information goes bad, etc. I suggest that anyone proposing more boilerplate material also should propose a stopping rule for determining which suggestions of that variety are not appropriate. john From rousskov@measurement-factory.com Tue Apr 13 15:35:18 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DMYnN28303 for ; Tue, 13 Apr 2004 15:34:49 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3DMYluH082860; Tue, 13 Apr 2004 16:34:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3DMYlJo082859; Tue, 13 Apr 2004 16:34:47 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Apr 2004 16:34:47 -0600 (MDT) From: Alex Rousskov To: John C Klensin Subject: Re: [rfc-i] Committee for opposing more tedious boilerplate (was: errata maintenance) In-Reply-To: <158438973.1081879301@scan.jck.com> Message-ID: References: <200404131809.i3DI9rN25337@boreas.isi.edu> <158438973.1081879301@scan.jck.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 22:35:18 -0000 John, IMO, the logically correct action here is to limit the size of the boilerplate, NOT the amount of information! For example, here is a 6-line boilerplate that can be used to express everything in the current RFC boilerplate and everything you mentioned in your plea below: This document specifies an IETF _____ Standard. The following resources are incorporated here by reference: Legal: http://rfc-editor.org/foo/bar/legal?v1.1 Status: http://rfc-editor.org/foo/bar/st?rfc1234 Errata: http://rfc-editor.org/foo/bar/err?rfc1234 Help: http://rfc-editor.org/foo/bar/help The text, labels, and URLs should be polished, but you get the idea... Alex. On Tue, 13 Apr 2004, John C Klensin wrote: > >> Not sure anyone suggested this yet but another approach might > >> be to add some boiler plate to each new RFC pointing to the > >> errata page. > > > > Yep, that's a possibility. If so, maybe along the lines of: > > > > RFCs are forever; an RFC is never modified after publication. > > However, RFCs can be reclassified: made historic, obsoleted > > completely, or updated by subsequent RFCs. The current > > status of an RFC must be checked in the RFC index [URL], not > > in the document itself. Editorial errata for RFCs is also > > available at [URL2]. > > _Please_ let's not go down this path. RFCs have already ended > up with an unpleasant ratio of boilerplate to informational > content (unless they are already _very_ long). There is ample > evidence that, when boilerplate gets long enough --and we are > almost certainly past that limit already-- people don't read the > stuff. It registers as boilerplate, and then they start > searching for whatever they are really looking for. That, in > turn, can be bad news, since they may skip something that really > is important. > > Suggestion: A case can be made that all sorts of information > that is not now present in RFCs would be useful -- pointers to > the index for status material and to errata, information about > contacting the IETF about Standards Track material, suggestions > about how to locate authors if the address information goes bad, > etc. I suggest that anyone proposing more boilerplate material > also should propose a stopping rule for determining which > suggestions of that variety are not appropriate. > > john > > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest > From john+rfc@jck.com Tue Apr 13 15:49:56 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DMnoN01204 for ; Tue, 13 Apr 2004 15:49:50 -0700 (PDT) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1BDWj0-00069X-00; Tue, 13 Apr 2004 17:49:50 -0500 Date: Tue, 13 Apr 2004 18:49:50 -0400 From: John C Klensin To: Alex Rousskov Subject: Re: [rfc-i] Committee for opposing more tedious boilerplate (was: errata maintenance) Message-ID: <161327747.1081882190@scan.jck.com> In-Reply-To: References: <200404131809.i3DI9rN25337@boreas.isi.edu> <158438973.1081879301@scan.jck.com> X-Mailer: Mulberry/3.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 22:49:56 -0000 It is my understanding that the lawyers don't like this sort of idea, precisely because of the ease with which a web page can be changed out from under a document, resulting in conditions different from those under which the document was published. While the other three lines you list might work, the bulk of the boilerplate today is lawyer-associated or lawyer-induced, so the savings might not be great. john --On Tuesday, 13 April, 2004 16:34 -0600 Alex Rousskov wrote: > John, > > IMO, the logically correct action here is to limit the size of > the boilerplate, NOT the amount of information! For example, > here is a 6-line boilerplate that can be used to express > everything in the current RFC boilerplate and everything you > mentioned in your plea below: > > This document specifies an IETF _____ Standard. The > following resources are incorporated here by reference: > > Legal: http://rfc-editor.org/foo/bar/legal?v1.1 > Status: http://rfc-editor.org/foo/bar/st?rfc1234 > Errata: http://rfc-editor.org/foo/bar/err?rfc1234 > Help: http://rfc-editor.org/foo/bar/help > > The text, labels, and URLs should be polished, but you get the > idea... > > Alex. From rousskov@measurement-factory.com Tue Apr 13 16:09:40 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3DN8eN04990 for ; Tue, 13 Apr 2004 16:08:40 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3DN8cuH084267; Tue, 13 Apr 2004 17:08:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3DN8cRB084266; Tue, 13 Apr 2004 17:08:38 -0600 (MDT) (envelope-from rousskov) Date: Tue, 13 Apr 2004 17:08:38 -0600 (MDT) From: Alex Rousskov To: John C Klensin Subject: Re: [rfc-i] Committee for opposing more tedious boilerplate (was: errata maintenance) In-Reply-To: <161327747.1081882190@scan.jck.com> Message-ID: References: <200404131809.i3DI9rN25337@boreas.isi.edu> <158438973.1081879301@scan.jck.com> <161327747.1081882190@scan.jck.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 23:09:41 -0000 On Tue, 13 Apr 2004, John C Klensin wrote: > It is my understanding that the lawyers don't like this sort of > idea, precisely because of the ease with which a web page can be > changed out from under a document, resulting in conditions > different from those under which the document was published. The text and/or links can be polished to accommodate any lawyer demands IETF would like to accommodate. I suspect all such accommodations can continue to occur at the end of the document, so they seem to be irrelevant to this "boilerplate is tedious" discussion. > While the other three lines you list might work, the bulk of the > boilerplate today is lawyer-associated or lawyer-induced, so the > savings might not be great. Great! Since the legal stuff is all at the bottom of the document (except for a single Copyright line which can be moved as well), it seems to be irrelevant to your complaint that adding more non-legal information to the boilerplate [at the beginning of the document] hurts. Alex. > --On Tuesday, 13 April, 2004 16:34 -0600 Alex Rousskov > wrote: > > > John, > > > > IMO, the logically correct action here is to limit the size of > > the boilerplate, NOT the amount of information! For example, > > here is a 6-line boilerplate that can be used to express > > everything in the current RFC boilerplate and everything you > > mentioned in your plea below: > > > > This document specifies an IETF _____ Standard. The > > following resources are incorporated here by reference: > > > > Legal: http://rfc-editor.org/foo/bar/legal?v1.1 > > Status: http://rfc-editor.org/foo/bar/st?rfc1234 > > Errata: http://rfc-editor.org/foo/bar/err?rfc1234 > > Help: http://rfc-editor.org/foo/bar/help > > > > The text, labels, and URLs should be polished, but you get the > > idea... > > > > Alex. From henrik@levkowetz.com Tue Apr 13 19:53:59 2004 Received: from av3-1-sn1.fre.skanova.net (av3-1-sn1.fre.skanova.net [81.228.11.109]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3E2roN05984 for ; Tue, 13 Apr 2004 19:53:50 -0700 (PDT) Received: by av3-1-sn1.fre.skanova.net (Postfix, from userid 502) id E4C3637E49; Wed, 14 Apr 2004 04:53:43 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av3-1-sn1.fre.skanova.net (Postfix) with ESMTP id D7EDA37E47; Wed, 14 Apr 2004 04:53:43 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id BF9F637E4E; Wed, 14 Apr 2004 04:53:43 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BDaX1-0000Yp-00; Wed, 14 Apr 2004 04:53:43 +0200 Date: Wed, 14 Apr 2004 04:53:42 +0200 From: Henrik Levkowetz To: Bob Braden Subject: Re: [rfc-i] errata maintenance Message-Id: <20040414045342.2acee55a.henrik@levkowetz.com> In-Reply-To: <200404131829.LAA02972@gra.isi.edu> References: <200404131829.LAA02972@gra.isi.edu> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: henrik@levkowetz.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 02:54:00 -0000 Hi Bob, Tuesday 13 April 2004, Bob Braden wrote: > How about one simple URL: > > www.rfc-editor.org/rfcsearch.html? > > It's already there. Or you could do something similar to what I've set up on the Mip4 WG website: http://mip4.org/show/rfc/2060 which if you follow it gives you everything on one plate, and although not official is also there today... Henrik From rousskov@measurement-factory.com Wed Apr 14 08:36:15 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3EFZvN27945 for ; Wed, 14 Apr 2004 08:35:57 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i3EFZguH019032; Wed, 14 Apr 2004 09:35:44 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i3EFZfsY019031; Wed, 14 Apr 2004 09:35:41 -0600 (MDT) (envelope-from rousskov) Date: Wed, 14 Apr 2004 09:35:41 -0600 (MDT) From: Alex Rousskov To: Henrik Levkowetz Subject: Re: [rfc-i] errata maintenance In-Reply-To: <20040414045342.2acee55a.henrik@levkowetz.com> Message-ID: References: <200404131829.LAA02972@gra.isi.edu> <20040414045342.2acee55a.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 15:36:15 -0000 On Wed, 14 Apr 2004, Henrik Levkowetz wrote: Tuesday 13 April 2004, Bob Braden wrote: > How about one simple URL: > www.rfc-editor.org/rfcsearch.html? > It's already there. RFC-specific links are much better than a general rfcsearch.html link because they give humans and machines what they are looking for. A general link gives them nothing but the next hop on the path to the information. On Wed, 14 Apr 2004, Henrik Levkowetz wrote: > Or you could do something similar to what I've set up on the Mip4 WG > website: > http://mip4.org/show/rfc/2060 > which if you follow it gives you everything on one plate, and > although not official is also there today... I like the "one plate" approach. If RFC Editor adopts something like that, it may be worth discussing whether it is a good idea to mix metadata (obsoleted, errata, etc. links) with data (the RFC text) at the _top_ level. That is, should the top-level "plate" contain just metadata, suitable for both human and machine processing? Separating metadata maybe the Right Thing to do in the ideal world (IMO), but on this planet it may lead to folks just using the "actual text" links, bypassing metadata. $0.02, Alex. From henrik@levkowetz.com Wed Apr 14 09:25:13 2004 Received: from mailgw.local.ipunplugged.com (213.80.52.78.dataphone.se [213.80.52.78] (may be forged)) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3EGP7N11385 for ; Wed, 14 Apr 2004 09:25:07 -0700 (PDT) Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i3EGOrKa002453; Wed, 14 Apr 2004 18:24:53 +0200 Date: Wed, 14 Apr 2004 18:24:52 +0200 From: Henrik Levkowetz To: Alex Rousskov Subject: Re: [rfc-i] errata maintenance Message-Id: <20040414182452.138269a2.henrik@levkowetz.com> In-Reply-To: References: <200404131829.LAA02972@gra.isi.edu> <20040414045342.2acee55a.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.70rc, clamav-milter version 0.70 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: henrik@levkowetz.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 16:25:14 -0000 Hi Alex, On Wednesday, 14 Apr 2004, Alex Rousskov wrote: > I like the "one plate" approach. Cool. > If RFC Editor adopts something like that, it may be worth discussing > whether it is a good idea to mix metadata (obsoleted, errata, etc. > links) with data (the RFC text) at the _top_ level. That is, should > the top-level "plate" contain just metadata, suitable for both human > and machine processing? Separating metadata maybe the Right Thing to > do in the ideal world (IMO), but on this planet it may lead to folks > just using the "actual text" links, bypassing metadata. I wrote it this way because as a human, when I'm looking up the text of an RFC, it's nice to be able to see at a glance whether the RFC I went to look at is actually obsoleted, or has errata. So I guess that means I agree with your reasoning :-) Henrik From hgs@cs.columbia.edu Mon May 3 10:53:06 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i43HqQU11916 for ; Mon, 3 May 2004 10:52:26 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i43HqNZ2026258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 May 2004 13:52:24 -0400 (EDT) Message-ID: <409686D7.7030005@cs.columbia.edu> Date: Mon, 03 May 2004 13:52:23 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rfc-interest@rfc-editor.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.2.99578 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, __MIME_TEXT_ONLY 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Subject: [rfc-i] UTF-8 and Unicode examples X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 17:53:06 -0000 Increasingly, protocols use UTF-8 as their 'native' format. If a document wants to present an example, it can, due to the US-ASCII rule, not use the character itself. A possible solution is to use the common U+1234 notation for Unicode instead, or some specific notation for UTF-8 in ASCII. The same problem exists for names, e.g., in acknowledgements, albeit less urgently. It would be nice to find a general solution rather than each author winging it. (The inability to specify non-ASCII examples might well contribute to implementor laziness as well, as implementors code from examples and thus simply consider the UTF-8 thing some political correctness item that they can safely ignore :-)) Henning From braden@ISI.EDU Mon May 3 11:05:07 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i43I4PU16150; Mon, 3 May 2004 11:04:25 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA09762; Mon, 3 May 2004 11:04:25 -0700 (PDT) Date: Mon, 3 May 2004 11:04:25 -0700 (PDT) Message-Id: <200405031804.LAA09762@gra.isi.edu> To: rfc-interest@rfc-editor.org, hgs@cs.columbia.edu Subject: Re: [rfc-i] UTF-8 and Unicode examples X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:05:19 -0000 *> *> Increasingly, protocols use UTF-8 as their 'native' format. If a *> document wants to present an example, it can, due to the US-ASCII rule, *> not use the character itself. A possible solution is to use the common *> U+1234 notation for Unicode instead, or some specific notation for UTF-8 *> in ASCII. *> *> The same problem exists for names, e.g., in acknowledgements, albeit *> less urgently. *> *> It would be nice to find a general solution rather than each author *> winging it. (The inability to specify non-ASCII examples might well *> contribute to implementor laziness as well, as implementors code from *> examples and thus simply consider the UTF-8 thing some political *> correctness item that they can safely ignore :-)) *> *> Henning Henning, The issue of extended character sets has been on the back-burner at the RFC Editor for the past several years. Yes, it "would be nice". Unfortunately, it appears to us that this path is full of deep, deep pits of non-interoperability! There are no widely-available tools for reading, searching, comparing, editing, or printing documents containing UTF-8 and friends, as far as we know. (We would be happy to be proven wrong.) Bob Braden From julian.reschke@gmx.de Mon May 3 11:56:07 2004 Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i43Iu2U02014 for ; Mon, 3 May 2004 11:56:02 -0700 (PDT) Received: (qmail 5436 invoked by uid 65534); 3 May 2004 18:55:51 -0000 Received: from p3EE24809.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.72.9) by mail.gmx.net (mp014) with SMTP; 03 May 2004 20:55:51 +0200 X-Authenticated: #1915285 Message-ID: <4096959D.8090701@gmx.de> Date: Mon, 03 May 2004 20:55:25 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405031804.LAA09762@gra.isi.edu> In-Reply-To: <200405031804.LAA09762@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:56:07 -0000 Bob Braden wrote: > The issue of extended character sets has been on the back-burner at the > RFC Editor for the past several years. Yes, it "would be nice". > Unfortunately, it appears to us that this path is full of deep, deep > pits of non-interoperability! There are no widely-available tools for > reading, searching, comparing, editing, or printing documents > containing UTF-8 and friends, as far as we know. (We would be happy to > be proven wrong.) Does Notepad (Windows) count as "widely available"? I guess so. True, it's platform-specific, but I'd be surprised if there wasn't a open source counterpart on Unix (how about and ?). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From hgs@cs.columbia.edu Mon May 3 13:51:15 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i43KofU03071 for ; Mon, 3 May 2004 13:50:41 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i43KoZZ2007438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 May 2004 16:50:35 -0400 (EDT) Message-ID: <4096B09A.9080309@cs.columbia.edu> Date: Mon, 03 May 2004 16:50:34 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405031804.LAA09762@gra.isi.edu> In-Reply-To: <200405031804.LAA09762@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.3.99633 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 20:51:15 -0000 I suspect we're talking about (at least) two different things. I'm specifically *not* suggesting that RFCs contain actual UTF-8 (or other non-ASCII) symbols, for the reasons you allude to. On the contrary, I'm hoping for a common "escape" notation that will allow writers to indicate the presence of a non-ASCII character (e.g., encoded as UTF-8, as that's the most common case) while sticking to ASCII characters. As noted, Unicode itself provides a way of expressing characters in such a notation, using a hexadecimal notation. For example, U+00B0 would be the degree sign (http://www.unicode.org/charts/PDF/U0080.pdf). There are several plausible solutions: (1) Simply state that the U+ notation is to be used, even though the actual (UTF-8) encoding will not consist of two octets. For example, one might write M+00FCnchen to indicate the German city Muenchen (Munich). (2) Designate another escape convention that indicates that a non-ASCII UTF-8 sequence should be at that point in the document. Henning Bob Braden wrote: > The issue of extended character sets has been on the back-burner at the > RFC Editor for the past several years. Yes, it "would be nice". > Unfortunately, it appears to us that this path is full of deep, deep > pits of non-interoperability! There are no widely-available tools for > reading, searching, comparing, editing, or printing documents > containing UTF-8 and friends, as far as we know. (We would be happy to > be proven wrong.) > > Bob Braden From braden@ISI.EDU Mon May 3 13:57:23 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i43KufU05260; Mon, 3 May 2004 13:56:41 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA09892; Mon, 3 May 2004 13:56:40 -0700 (PDT) Date: Mon, 3 May 2004 13:56:40 -0700 (PDT) Message-Id: <200405032056.NAA09892@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu Subject: Re: [rfc-i] UTF-8 and Unicode examples X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 20:57:24 -0000 Henning, I am happy to know that I misunderstood your question. I hope your question will generate further discussion/enlightenment. Bob From braden@ISI.EDU Mon May 3 16:30:17 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i43NUAU17817; Mon, 3 May 2004 16:30:10 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id QAA10043; Mon, 3 May 2004 16:30:10 -0700 (PDT) Date: Mon, 3 May 2004 16:30:10 -0700 (PDT) Message-Id: <200405032330.QAA10043@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu Subject: Re: [rfc-i] UTF-8 and Unicode examples X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 23:30:18 -0000 *> *> There are several plausible solutions: *> *> (1) Simply state that the U+ notation is to be used, even though the *> actual (UTF-8) encoding will not consist of two octets. For example, one *> might write *> *> M+00FCnchen That is unpleasantly ambiguous looking. A computer knows to look for 4 hex characters, but to a human it is harder to parse. Maybe: M+00FC'nchen? or M'00FC'nchen? and of course you have to be able to escape the +. Bob From Kurt@OpenLDAP.org Mon May 3 21:24:23 2004 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i444O6U17490 for ; Mon, 3 May 2004 21:24:06 -0700 (PDT) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i444Np0Y011129; Tue, 4 May 2004 04:23:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Mon, 03 May 2004 21:23:54 -0700 To: Bob Braden From: "Kurt D. Zeilenga" Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <200405032330.QAA10043@gra.isi.edu> References: <200405032330.QAA10043@gra.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: kurt@openldap.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 04:24:23 -0000 Why not just use conventions established for use in the Unicode standard itself? For instance, M\u00FFnchen. http://www.unicode.org/versions/Unicode4.0.0/Preface.pdf#G1771 Note at times, these conventions may infer with the syntax of the protocol. In such cases, other conventions will have to be designed which do not inter with the syntax of the protocol. For instance, if the protocol itself supports such escaping, then the specification has to something like: The Unicode string "Mnchen", where is the LATIN SMALL LETTER Y WITH DIAERESIS character, is transferred as the ASCII string "M\u00FFnchen". And sometimes, it's good to use base16 or base64 to show proper UTF-8 encoding. For instance, in a protocol which supports transfer of UTF-8 encoded Unicode: The Unicode string "M\u00FFnchen", where \u00FF is the LATIN SMALL LETTER Y WITH DIAERESIS character, is transferred as the UTF-8 encoded Unicode represented in the following octet sequence (base 16): 4d c3 bf 6e 63 68 65 6e Kurt At 04:30 PM 5/3/2004, Bob Braden wrote: > *> > *> There are several plausible solutions: > *> > *> (1) Simply state that the U+ notation is to be used, even though the > *> actual (UTF-8) encoding will not consist of two octets. For example, one > *> might write > *> > *> M+00FCnchen > >That is unpleasantly ambiguous looking. A computer knows to look for >4 hex characters, but to a human it is harder to parse. Maybe: > > M+00FC'nchen? or M'00FC'nchen? > >and of course you have to be able to escape the +. > >Bob >_______________________________________________ >rfc-interest mailing list >rfc-interest@rfc-editor.org >http://www.rfc-editor.org/mailman/listinfo/rfc-interest From hgs@cs.columbia.edu Tue May 4 07:19:37 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44EJWU14441 for ; Tue, 4 May 2004 07:19:32 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i44EJCZ2015692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2004 10:19:13 -0400 (EDT) Message-ID: <4097A660.4030509@cs.columbia.edu> Date: Tue, 04 May 2004 10:19:12 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.3.99658 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 14:19:37 -0000 Thanks for the pointer. I would suggest that the following convention be adopted: - Unicode strings use the notation, as in "Mnchen" - UTF-8 strings use the notation, where xx are hexadecimal digits. - The literal < just uses the Unicode rendition in those cases where this can be misinterpreted, i.e., where it is followed by U+ or a hex digit. Does this work? Kurt D. Zeilenga wrote: > Why not just use conventions established for use in the Unicode > standard itself? For instance, M\u00FFnchen. > > http://www.unicode.org/versions/Unicode4.0.0/Preface.pdf#G1771 > > Note at times, these conventions may infer with the > syntax of the protocol. In such cases, other conventions > will have to be designed which do not inter with the syntax > of the protocol. For instance, if the protocol itself supports > such escaping, then the specification has to something like: > > The Unicode string "Mnchen", where is > the LATIN SMALL LETTER Y WITH DIAERESIS character, > is transferred as the ASCII string "M\u00FFnchen". > > And sometimes, it's good to use base16 or base64 to > show proper UTF-8 encoding. For instance, in a protocol > which supports transfer of UTF-8 encoded Unicode: > > The Unicode string "M\u00FFnchen", where \u00FF is > the LATIN SMALL LETTER Y WITH DIAERESIS character, is > transferred as the UTF-8 encoded Unicode represented > in the following octet sequence (base 16): > 4d c3 bf 6e 63 68 65 6e > > Kurt > > > At 04:30 PM 5/3/2004, Bob Braden wrote: > > >> *> >> *> There are several plausible solutions: >> *> >> *> (1) Simply state that the U+ notation is to be used, even though the >> *> actual (UTF-8) encoding will not consist of two octets. For example, one >> *> might write >> *> >> *> M+00FCnchen >> >>That is unpleasantly ambiguous looking. A computer knows to look for >>4 hex characters, but to a human it is harder to parse. Maybe: >> >> M+00FC'nchen? or M'00FC'nchen? >> >>and of course you have to be able to escape the +. >> >>Bob >>_______________________________________________ >>rfc-interest mailing list >>rfc-interest@rfc-editor.org >>http://www.rfc-editor.org/mailman/listinfo/rfc-interest From rousskov@measurement-factory.com Tue May 4 10:52:43 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44HqFU11701 for ; Tue, 4 May 2004 10:52:15 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i44HpquH037923; Tue, 4 May 2004 11:51:52 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i44HpqFD037922; Tue, 4 May 2004 11:51:52 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 11:51:52 -0600 (MDT) From: Alex Rousskov To: Henning Schulzrinne Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4097A660.4030509@cs.columbia.edu> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org, "Kurt D. Zeilenga" X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 17:52:43 -0000 On Tue, 4 May 2004, Henning Schulzrinne wrote: > Thanks for the pointer. I would suggest that the following convention be > adopted: > > - Unicode strings use the notation, as in "Mnchen" > > - UTF-8 strings use the notation, where xx are hexadecimal digits. > > - The literal < just uses the Unicode rendition in those cases where > this can be misinterpreted, i.e., where it is followed by U+ or a hex digit. > > Does this work? Using [] instead of <> might be a good idea to reduce the number of confused applications that would try to XML-ify the escape sequence. Should tools like xml2rfc accept/interpret raw UTF-8, the escape sequence above, or both? This matters because these tools produce both ASCII text and HTML versions of specs. Alex. From julian.reschke@gmx.de Tue May 4 11:13:44 2004 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i44IDUU17880 for ; Tue, 4 May 2004 11:13:30 -0700 (PDT) Received: (qmail 3117 invoked by uid 65534); 4 May 2004 18:13:23 -0000 Received: from p3EE24811.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.72.17) by mail.gmx.net (mp008) with SMTP; 04 May 2004 20:13:23 +0200 X-Authenticated: #1915285 Message-ID: <4097DD38.2090401@gmx.de> Date: Tue, 04 May 2004 20:13:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org, "Kurt D. Zeilenga" X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 18:13:44 -0000 Alex Rousskov wrote: > On Tue, 4 May 2004, Henning Schulzrinne wrote: > > >>Thanks for the pointer. I would suggest that the following convention be >>adopted: >> >>- Unicode strings use the notation, as in "Mnchen" >> >>- UTF-8 strings use the notation, where xx are hexadecimal digits. >> >>- The literal < just uses the Unicode rendition in those cases where >>this can be misinterpreted, i.e., where it is followed by U+ or a hex digit. >> >>Does this work? > > > Using [] instead of <> might be a good idea to reduce the number > of confused applications that would try to XML-ify the escape > sequence. > > Should tools like xml2rfc accept/interpret raw UTF-8, the escape > sequence above, or both? This matters because these tools produce both > ASCII text and HTML versions of specs. I'd find it very dangerous if tools like xml2rfc would keep the non-ASCII characters in HTML output, but escape them in TXT output. People frequently only check the HTML output, but in the end what matters is readable TXT output. On the other hand, I think it would make a *lot* of sense to discuss allowing at least certain non-ASCII characters inside TXT versions (encoded as UTF-8). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From hgs@cs.columbia.edu Tue May 4 11:31:45 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44IV7U23032 for ; Tue, 4 May 2004 11:31:08 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i44IUWZ2001872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2004 14:30:37 -0400 (EDT) Message-ID: <4097E147.6070309@cs.columbia.edu> Date: Tue, 04 May 2004 14:30:31 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.4.99721 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org, "Kurt D. Zeilenga" X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 18:31:46 -0000 > > Using [] instead of <> might be a good idea to reduce the number > of confused applications that would try to XML-ify the escape > sequence. The symbols < and > appear all the time today in, e.g., ASCII art drawings as arrow heads, already. Examples are typically CDATA and part of , so I don't see this as a big issue. In the XML input text, you may indeed have to escape the < as <, but we have to do this all the time today when we code literal XML tags. There is no hope in designing text output that will not trip up an XML processor - it is not XML, after all. Given that the Unicode spec suggests the <> format, it would need a stronger case, in my view, to choose another rendering. > > Should tools like xml2rfc accept/interpret raw UTF-8, the escape > sequence above, or both? This matters because these tools produce both > ASCII text and HTML versions of specs. I would not want to derail the short-term need to be able to express Unicode and UTF-8 examples by commingling it with the much bigger long-term problem as to whether non-ASCII characters should be first-class RFC citizens. There are many reasons that this may not be a good idea, none of which affect the issue of expressing protocol examples I'm concerned about here. > > Alex. From Kurt@OpenLDAP.org Tue May 4 12:27:50 2004 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44JPgU07848 for ; Tue, 4 May 2004 12:25:42 -0700 (PDT) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i44JOp0Y015498; Tue, 4 May 2004 19:24:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040504120820.02c99828@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 04 May 2004 12:24:53 -0700 To: Henning Schulzrinne From: "Kurt D. Zeilenga" Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4097A660.4030509@cs.columbia.edu> References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: kurt@openldap.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 19:27:50 -0000 At 07:19 AM 5/4/2004, Henning Schulzrinne wrote: >Thanks for the pointer. I would suggest that the following convention be adopted: Before we attempt to discuss the merits of any particular convention, I think we should discuss whether it appropriate or not to adopt a particular convention. I doubt that one could devise a convention that would work for all RFCs. As I demonstrated in the examples I posted, often documents need to use multiple conventions. We never defined conventions for ASCII examples (whose representations are ambiguous or otherwise unclear). We got along there without adopting a convention for all RFCs to follow. Sure, Unicode contains a lot more characters which are problematic when used in examples... but I don't see why the approaches we've used with problematic ASCII characters wouldn't work with Unicode characters. But, more to the point, I think our operational experience with ASCII shows that one convention is insufficient and the current practice of allowing documents to define appropriate conventions for their needs works just fine. Just as we do with ASCII escaping, we should encourage reuse of established conventions (such as Unicode conventions). But I don't think we need to be BCP'ing anything here. Kurt From rousskov@measurement-factory.com Tue May 4 12:30:46 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44JThU08772 for ; Tue, 4 May 2004 12:29:43 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i44JTUuH043211; Tue, 4 May 2004 13:29:30 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i44JTU0J043210; Tue, 4 May 2004 13:29:30 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 13:29:30 -0600 (MDT) From: Alex Rousskov To: Julian Reschke Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4097DD38.2090401@gmx.de> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 19:30:46 -0000 On Tue, 4 May 2004, Julian Reschke wrote: > > Should tools like xml2rfc accept/interpret raw UTF-8, the escape > > sequence above, or both? This matters because these tools produce > > both ASCII text and HTML versions of specs. > > I'd find it very dangerous if tools like xml2rfc would keep the > non-ASCII characters in HTML output, but escape them in TXT output. I would find that natural. > People frequently only check the HTML output, but in the end what > matters is readable TXT output. In my experience, we have already crossed the line where readable HTML output implies readable TXT output with xml2rfc. YMMV. > On the other hand, I think it would make a *lot* of sense to discuss > allowing at least certain non-ASCII characters inside TXT versions > (encoded as UTF-8). Based on IETF powers-that-be comments on various IETF lists, such a discussion would probably be a waste of time for now. For good or bad, the inertia is too high, and it is trivial to come up with use cases where anything but ASCII would not be acceptable. Try again in five years or so :-/. Alex. From rousskov@measurement-factory.com Tue May 4 12:41:46 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44JdVU11542 for ; Tue, 4 May 2004 12:39:39 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i44JcMuH043643; Tue, 4 May 2004 13:38:22 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i44JcMq1043642; Tue, 4 May 2004 13:38:22 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 13:38:22 -0600 (MDT) From: Alex Rousskov To: Henning Schulzrinne Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4097E147.6070309@cs.columbia.edu> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097E147.6070309@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 19:41:46 -0000 On Tue, 4 May 2004, Henning Schulzrinne wrote: > Given that the Unicode spec suggests the <> format, it would need a > stronger case, in my view, to choose another rendering. I did not realize Unicode spec suggests the <> format. You have a much stronger point then. > > Should tools like xml2rfc accept/interpret raw UTF-8, the escape > > sequence above, or both? This matters because these tools produce > > both ASCII text and HTML versions of specs. > > I would not want to derail the short-term need to be able to express > Unicode and UTF-8 examples by commingling it with the much bigger > long-term problem as to whether non-ASCII characters should be > first-class RFC citizens. There are many reasons that this may not be a > good idea, none of which affect the issue of expressing protocol > examples I'm concerned about here. I agree. The above questions have little to do with that bigger issue. We simply need to decide what the right behavior for dual-output tools such as xml2rfc is. The short-term choices do not include using UTF-8 characters in TXT output but may include using UTF-8 characters in HTML output and in input. Thanks, Alex. From julian.reschke@gmx.de Tue May 4 12:46:56 2004 Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i44JjjU12829 for ; Tue, 4 May 2004 12:45:45 -0700 (PDT) Received: (qmail 31737 invoked by uid 65534); 4 May 2004 19:45:38 -0000 Received: from p3EE24811.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.72.17) by mail.gmx.net (mp018) with SMTP; 04 May 2004 21:45:38 +0200 X-Authenticated: #1915285 Message-ID: <4097F2DE.3070405@gmx.de> Date: Tue, 04 May 2004 21:45:34 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 19:46:56 -0000 Alex Rousskov wrote: > ... >>People frequently only check the HTML output, but in the end what >>matters is readable TXT output. > > > In my experience, we have already crossed the line where readable HTML > output implies readable TXT output with xml2rfc. YMMV. Yes, it does *now*. But the more features we put into xml2rfc that do not directly translate to TXT, the less you can rely on that. >>On the other hand, I think it would make a *lot* of sense to discuss >>allowing at least certain non-ASCII characters inside TXT versions >>(encoded as UTF-8). > > > Based on IETF powers-that-be comments on various IETF lists, such a > discussion would probably be a waste of time for now. For good or bad, > the inertia is too high, and it is trivial to come up with use cases > where anything but ASCII would not be acceptable. Try again in five > years or so :-/. :-) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From rousskov@measurement-factory.com Tue May 4 12:58:28 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44JvKU16305 for ; Tue, 4 May 2004 12:57:20 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i44JuouH044479; Tue, 4 May 2004 13:56:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i44JuoGX044478; Tue, 4 May 2004 13:56:50 -0600 (MDT) (envelope-from rousskov) Date: Tue, 4 May 2004 13:56:50 -0600 (MDT) From: Alex Rousskov To: Julian Reschke Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4097F2DE.3070405@gmx.de> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 19:58:28 -0000 On Tue, 4 May 2004, Julian Reschke wrote: > Alex Rousskov wrote: > > > ... > >>People frequently only check the HTML output, but in the end what > >>matters is readable TXT output. > > > > > > In my experience, we have already crossed the line where readable HTML > > output implies readable TXT output with xml2rfc. YMMV. > > Yes, it does *now*. But the more features we put into xml2rfc that do > not directly translate to TXT, the less you can rely on that. What I meant is that in my experience, HTML output quality already does NOT imply comparable TXT output quality. Great HTML-looking RFCs already often do not look good in TXT. The genie of output "interface" quality is out of the bottle as far as xml2rfc is concerned. Alex. From braden@ISI.EDU Tue May 4 14:25:35 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44LODU09962; Tue, 4 May 2004 14:24:13 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id OAA10418; Tue, 4 May 2004 14:24:13 -0700 (PDT) Date: Tue, 4 May 2004 14:24:13 -0700 (PDT) Message-Id: <200405042124.OAA10418@gra.isi.edu> To: john.loughney@nokia.com X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@rfc-editor.org Subject: [rfc-i] What standards? X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 21:25:35 -0000 John, I just noticed your Feb 2004 Internet Draft "draft-loughney-what-standards-01.txt", and I like it. It makes an important point: the IETF community has (relatively recently, on the Internet time scale) fallen into the very bad habit of referring to a protocol by an RFC numbers rather than by name. RFC numbers are labels on specification DOCUMENTS, not the names of the protocols these documents specify. When a specifications is modified, a new RFC is issued, but that should not change the protocol name. The email protocol is "SMTP" (or "Simple Mail Transfer Protocol", in a more relaxed world than the one we inhabit), and the protocol is now defined in RFC 2821. Yet I frequently hear people refer to it as "RFC 821", and I see confusion arising as a result. STD numbers were an attempt to provide a distinct name space for protocols. But they were designed in the good old days when we naively assumed that all successful protocols would fairly quickly progress from Proposed Std to Draft Std to Std category, so STDs are applied only to Standard documents. If you look at the Official Internet Protocol Standards tables, which Jon started publishing in 1988 (RFC 1083), each protocol has a name, like Transmission Control Protocol, and a mnemonic, like "TCP". In many cases Jon had to invent mnemonics and the results got a little wierd at times, but it did solve the problem you are concerned with. We have dropped the definition of protocol mnemonics as Jon had them, and perhaps they need to be resurrected. A new take would require some thought to create structure; the protocol world is much more complex than it was in 1988! Bob Braden From hgs@cs.columbia.edu Tue May 4 15:21:03 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i44MJmU25430 for ; Tue, 4 May 2004 15:19:48 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i44MJRZ2016202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 May 2004 18:19:36 -0400 (EDT) Message-ID: <409816EF.7050101@cs.columbia.edu> Date: Tue, 04 May 2004 18:19:27 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <6.0.1.1.0.20040504120820.02c99828@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040504120820.02c99828@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.4.99755 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 22:21:03 -0000 Currently, there is no documentation. We don't need something that has the force of law ("if you don't do this, your RFC won't get published"), but rather provide guidance to people. If somebody has a good reason to choose something else, great. Kurt D. Zeilenga wrote: > At 07:19 AM 5/4/2004, Henning Schulzrinne wrote: > >>Thanks for the pointer. I would suggest that the following convention be adopted: > > > Before we attempt to discuss the merits of any particular convention, > I think we should discuss whether it appropriate or not to adopt > a particular convention. > > I doubt that one could devise a convention that would work > for all RFCs. As I demonstrated in the examples I posted, often > documents need to use multiple conventions. > > We never defined conventions for ASCII examples (whose > representations are ambiguous or otherwise unclear). We got > along there without adopting a convention for all RFCs to > follow. > > Sure, Unicode contains a lot more characters which are > problematic when used in examples... but I don't see why > the approaches we've used with problematic ASCII characters > wouldn't work with Unicode characters. > > But, more to the point, I think our operational experience > with ASCII shows that one convention is insufficient and the > current practice of allowing documents to define appropriate > conventions for their needs works just fine. > > Just as we do with ASCII escaping, we should encourage reuse > of established conventions (such as Unicode conventions). But > I don't think we need to be BCP'ing anything here. > > Kurt From falk@ISI.EDU Wed May 5 17:03:09 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46028U18533 for ; Wed, 5 May 2004 17:02:08 -0700 (PDT) Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4601ek19822; Wed, 5 May 2004 17:01:40 -0700 (PDT) In-Reply-To: <409816EF.7050101@cs.columbia.edu> References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <6.0.1.1.0.20040504120820.02c99828@127.0.0.1> <409816EF.7050101@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-37-267799986" Message-Id: <8C13B2F2-9EF0-11D8-B003-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] UTF-8 and Unicode examples Date: Wed, 5 May 2004 17:01:38 -0700 To: Henning Schulzrinne X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 00:03:09 -0000 --Apple-Mail-37-267799986 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On May 4, 2004, at 3:19 PM, Henning Schulzrinne wrote: > Currently, there is no documentation. We don't need something that has > the force of law ("if you don't do this, your RFC won't get > published"), but rather provide guidance to people. If somebody has a > good reason to choose something else, great. Henning- We'd like to post a recommendation on this on the RFC Editor web site, probably by adding a 'tips' section to http://www.rfc-editor.org/formatting.html. Could someone post a summary paragraph? Thanks, --aaron (for the RFC Editor) --Apple-Mail-37-267799986 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAmYBi/i95hBY97NERAuI3AJ9I9Yl+SfB9tlElv6nIYKi+m4YHmgCgnK5g xjoSKbzpGrHju6985evUYz4= =0YbT -----END PGP SIGNATURE----- --Apple-Mail-37-267799986-- From julian.reschke@gmx.de Wed May 5 23:53:46 2004 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i466rSU08685 for ; Wed, 5 May 2004 23:53:28 -0700 (PDT) Received: (qmail 13477 invoked by uid 65534); 6 May 2004 06:53:21 -0000 Received: from p3EE24802.dip.t-dialin.net (EHLO [192.168.0.3]) (62.226.72.2) by mail.gmx.net (mp015) with SMTP; 06 May 2004 08:53:21 +0200 X-Authenticated: #1915285 Message-ID: <4099E0DC.607@gmx.de> Date: Thu, 06 May 2004 08:53:16 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 06:53:47 -0000 Alex Rousskov wrote: > What I meant is that in my experience, HTML output quality already > does NOT imply comparable TXT output quality. Great HTML-looking RFCs > already often do not look good in TXT. The genie of output "interface" > quality is out of the bottle as far as xml2rfc is concerned. Well, thatnks for saying that clearly; maybe the discussion should be about HTML/XML vs TXT and not about UTF8 in TXT. Anyway, I'm aware of at least two use cases for non-ASCII characters in documents: 1) Contact Info Although the document is written in English, it will contain contact and related information for people in all kinds of countries; and these people will frequently have *names* or *adresses* containing these characters. Forcing them to translate to plain ASCII without giving them a chance to at least *also* supply the correct name seems to be rude. So it would be a good thing if xml2rfc would accept non-ASCII characters inside author information, as long there'd be a mandatory additional field that contains the "best effort" ASCII representation. But of course this is jusr cosmetic. 2) Protocol Information Protocols already have to deal with non-ASCII characters; but not allowing them inside the spec makes it hard to discuss these issues (such as: if I have character "Ä" inside a file name, how would I create a file URL: for that). It's possible to work around these issues, but it would make specs much more readable by explicitly allowing *a few* non-ASCII characters for usage in protocol examples. Actually, one single non-ASCII character (specially selected for these cases) may be enough. Any other use cases? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From hgs@cs.columbia.edu Thu May 6 05:54:55 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46CsoU25824 for ; Thu, 6 May 2004 05:54:51 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i46Cs9Z2015489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 May 2004 08:54:10 -0400 (EDT) Message-ID: <409A3571.1040402@cs.columbia.edu> Date: Thu, 06 May 2004 08:54:09 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> <4099E0DC.607@gmx.de> In-Reply-To: <4099E0DC.607@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.5.99928 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 12:54:56 -0000 The proposal I made earlier can also address these cases. It's not as elegant as having 'real' UTF-8 or Unicode in the document, but a simple translation application can easily convert characters into the real thing without breaking the ASCII-only restrictions in TXT documents. I agree that the xml2rfc folks should think about how to more intelligently capture non-ASCII characters. It is easy to translate them into the ASCII rendition, but it preserves them for some future time where adding non-ASCII representation is reasonable at least for some output formats. Is the XML charset mechanism sufficient here? Julian Reschke wrote: > Alex Rousskov wrote: > >> What I meant is that in my experience, HTML output quality already >> does NOT imply comparable TXT output quality. Great HTML-looking RFCs >> already often do not look good in TXT. The genie of output "interface" >> quality is out of the bottle as far as xml2rfc is concerned. > > > Well, thatnks for saying that clearly; maybe the discussion should be > about HTML/XML vs TXT and not about UTF8 in TXT. > > Anyway, I'm aware of at least two use cases for non-ASCII characters in > documents: > > 1) Contact Info > > Although the document is written in English, it will contain contact and > related information for people in all kinds of countries; and these > people will frequently have *names* or *adresses* containing these > characters. Forcing them to translate to plain ASCII without giving them > a chance to at least *also* supply the correct name seems to be rude. So > it would be a good thing if xml2rfc would accept non-ASCII characters > inside author information, as long there'd be a mandatory additional > field that contains the "best effort" ASCII representation. > > But of course this is jusr cosmetic. > > > 2) Protocol Information > > Protocols already have to deal with non-ASCII characters; but not > allowing them inside the spec makes it hard to discuss these issues > (such as: if I have character "Ä" inside a file name, how would I create > a file URL: for that). It's possible to work around these issues, but it > would make specs much more readable by explicitly allowing *a few* > non-ASCII characters for usage in protocol examples. Actually, one > single non-ASCII character (specially selected for these cases) may be > enough. > > > Any other use cases? > > > Best regards, Julian > > From rousskov@measurement-factory.com Thu May 6 08:31:21 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46FUSJ01376 for ; Thu, 6 May 2004 08:30:29 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i46FEqp6053726; Thu, 6 May 2004 09:14:52 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i46FEqVL053725; Thu, 6 May 2004 09:14:52 -0600 (MDT) (envelope-from rousskov) Date: Thu, 6 May 2004 09:14:52 -0600 (MDT) From: Alex Rousskov To: Julian Reschke Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <4099E0DC.607@gmx.de> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> <4099E0DC.607@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 15:31:21 -0000 On Thu, 6 May 2004, Julian Reschke wrote: > Anyway, I'm aware of at least two use cases for non-ASCII characters in > documents: > > 1) Contact Info > 2) Protocol Information > > Any other use cases? How about references/citations? Alex. From julian.reschke@gmx.de Thu May 6 08:41:21 2004 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i46FeRJ05442 for ; Thu, 6 May 2004 08:40:28 -0700 (PDT) Received: (qmail 17170 invoked by uid 65534); 6 May 2004 15:40:21 -0000 Received: from p50824C1D.dip0.t-ipconnect.de (EHLO [192.168.1.39]) (80.130.76.29) by mail.gmx.net (mp018) with SMTP; 06 May 2004 17:40:21 +0200 X-Authenticated: #1915285 Message-ID: <409A5C64.9050707@gmx.de> Date: Thu, 06 May 2004 17:40:20 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] UTF-8 and Unicode examples References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> <4099E0DC.607@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 15:41:21 -0000 Alex Rousskov wrote: > On Thu, 6 May 2004, Julian Reschke wrote: > > >>Anyway, I'm aware of at least two use cases for non-ASCII characters in >>documents: >> >>1) Contact Info >>2) Protocol Information >> >>Any other use cases? > > > How about references/citations? Correct. But those per definition could only used for informative parts, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From rousskov@measurement-factory.com Thu May 6 08:44:22 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46FiEJ06625 for ; Thu, 6 May 2004 08:44:14 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i46Fhvp6054928; Thu, 6 May 2004 09:43:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i46FhvJG054927; Thu, 6 May 2004 09:43:57 -0600 (MDT) (envelope-from rousskov) Date: Thu, 6 May 2004 09:43:57 -0600 (MDT) From: Alex Rousskov To: Julian Reschke Subject: Re: [rfc-i] UTF-8 and Unicode examples In-Reply-To: <409A5C64.9050707@gmx.de> Message-ID: References: <200405032330.QAA10043@gra.isi.edu> <6.0.1.1.0.20040503205724.02c88580@127.0.0.1> <4097A660.4030509@cs.columbia.edu> <4097DD38.2090401@gmx.de> <4097F2DE.3070405@gmx.de> <4099E0DC.607@gmx.de> <409A5C64.9050707@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 15:44:22 -0000 On Thu, 6 May 2004, Julian Reschke wrote: > Alex Rousskov wrote: > > > On Thu, 6 May 2004, Julian Reschke wrote: > > > > > >>Anyway, I'm aware of at least two use cases for non-ASCII characters in > >>documents: > >> > >>1) Contact Info > >>2) Protocol Information > >> > >>Any other use cases? > > > > > > How about references/citations? > > Correct. But those per definition could only used for informative parts, > right? That would be my guess. Normative references must be in English (although, in theory, they may have non-English author names with UTF-8 characters). Alex. From julian.reschke@gmx.de Fri May 7 07:34:25 2004 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i47EXRJ27683 for ; Fri, 7 May 2004 07:33:27 -0700 (PDT) Received: (qmail 27323 invoked by uid 65534); 7 May 2004 14:33:20 -0000 Received: from p50824550.dip0.t-ipconnect.de (EHLO [192.168.1.39]) (80.130.69.80) by mail.gmx.net (mp016) with SMTP; 07 May 2004 16:33:20 +0200 X-Authenticated: #1915285 Message-ID: <409B9E2F.9030600@gmx.de> Date: Fri, 07 May 2004 16:33:19 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rfc-interest@rfc-editor.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Subject: [rfc-i] RFC Standard Process question X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 14:34:25 -0000 Hi, I have the following question about what kind of changes are allowable when a specification is meant to be advanced from "Proposed" to "Draft". Assuming a specification defines a core protocol, plus a set of features that are clearly marked as "optional" (so a server doesn't need to implement them), and in particular the protocol defines how support for these features can be discovered at runtime. Is it possible to advance the base protocol to "Draft" while removing optional features from the document (possibly moving them into a separate document)? Looking at the history of RFC2396 (currently at "Draft") indicates that this has happened before, and certainly this makes a lot of sense. On the other hand, some people are telling me that in cases like these, the protocol revision would need to go back to "Proposed". Feedback appreciated, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From falk@ISI.EDU Fri May 7 08:57:03 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47FtwJ15345 for ; Fri, 7 May 2004 08:55:58 -0700 (PDT) Received: from [192.168.1.3] (dsl081-036-151.lax1.dsl.speakeasy.net [64.81.36.151]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47Fsmk06117; Fri, 7 May 2004 08:54:48 -0700 (PDT) In-Reply-To: <409B9E2F.9030600@gmx.de> References: <409B9E2F.9030600@gmx.de> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-33-411382928" Message-Id: Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] RFC Standard Process question Date: Fri, 7 May 2004 08:54:41 -0700 To: Julian Reschke X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: Harald Tveit Alvestrand , rfc-interest@rfc-editor.org, Scott Bradner X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 15:57:03 -0000 --Apple-Mail-33-411382928 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Julian- Section 4.1.2 or rfc2026 says: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. and in section 6.2: A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the IESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the IESG may recommend that the revision be treated as a new document, re- entering the standards track at the beginning. So, it appears to me (not in any RFC Editor capacity) that removing non-implemented options is part of going from Proposed to Draft and, so, doesn't push you back to the start. However, it appears to be a judgment call _on the part of the IESG_ as to whether the changes are significant enough. Now, speaking for the RFC Editor, since this is a standards process question, not an RFC publication question, rfc-i is the wrong list. I'd suggest addressing the IESG directly and cc'ing the IETF general list or possibly the newtrk list (since they are contemplating changes to the process). --aaron On May 7, 2004, at 7:33 AM, Julian Reschke wrote: > Hi, > > I have the following question about what kind of changes are allowable > when a specification is meant to be advanced from "Proposed" to > "Draft". > > Assuming a specification defines a core protocol, plus a set of > features that are clearly marked as "optional" (so a server doesn't > need to implement them), and in particular the protocol defines how > support for these features can be discovered at runtime. > > Is it possible to advance the base protocol to "Draft" while removing > optional features from the document (possibly moving them into a > separate document)? > > Looking at the history of RFC2396 (currently at "Draft") indicates > that this has happened before, and certainly this makes a lot of > sense. On the other hand, some people are telling me that in cases > like these, the protocol revision would need to go back to "Proposed". > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest --Apple-Mail-33-411382928 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAm7FB/i95hBY97NERAj32AKCOiqDYsUZyNuT6bWCJV+gdRl+qWwCgiofR kfTFHN5ssloKLzvyt66R/Vs= =gpkL -----END PGP SIGNATURE----- --Apple-Mail-33-411382928-- From julian.reschke@gmx.de Fri May 7 09:04:27 2004 Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i47G4BJ17453 for ; Fri, 7 May 2004 09:04:11 -0700 (PDT) Received: (qmail 7006 invoked by uid 65534); 7 May 2004 16:04:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.39]) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 07 May 2004 18:04:00 +0200 X-Authenticated: #1915285 Message-ID: <409BB365.3050605@gmx.de> Date: Fri, 07 May 2004 18:03:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Falk Subject: Re: [rfc-i] RFC Standard Process question References: <409B9E2F.9030600@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 16:04:27 -0000 Aaron Falk wrote: > ... > So, it appears to me (not in any RFC Editor capacity) that removing > non-implemented options is part of going from Proposed to Draft and, so, > doesn't push you back to the start. However, it appears to be a > judgment call _on the part of the IESG_ as to whether the changes are > significant enough. Thanks for the feedback. In this case however, we're not talking about about non-implemented features, but of features that *currently* have a set of interoperability issues that some of us would prefer to fix in a separate spec (allowing the base spec to progress more quickly). > Now, speaking for the RFC Editor, since this is a standards process > question, not an RFC publication question, rfc-i is the wrong list. I'd > suggest addressing the IESG directly and cc'ing the IETF general list or > possibly the newtrk list (since they are contemplating changes to the > process). Will do, thanks. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From braden@ISI.EDU Fri May 7 10:01:03 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47H07J01934; Fri, 7 May 2004 10:00:07 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA13204; Fri, 7 May 2004 10:00:06 -0700 (PDT) Date: Fri, 7 May 2004 10:00:06 -0700 (PDT) Message-Id: <200405071700.KAA13204@gra.isi.edu> To: rfc-interest@rfc-editor.org, julian.reschke@gmx.de Subject: Re: [rfc-i] RFC Standard Process question X-Sun-Charset: US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 17:01:27 -0000 *> Hi, *> *> I have the following question about what kind of changes are allowable *> when a specification is meant to be advanced from "Proposed" to "Draft". *> *> Assuming a specification defines a core protocol, plus a set of features *> that are clearly marked as "optional" (so a server doesn't need to *> implement them), and in particular the protocol defines how support for *> these features can be discovered at runtime. *> *> Is it possible to advance the base protocol to "Draft" while removing *> optional features from the document (possibly moving them into a *> separate document)? *> *> Looking at the history of RFC2396 (currently at "Draft") indicates that *> this has happened before, and certainly this makes a lot of sense. On *> the other hand, some people are telling me that in cases like these, the *> protocol revision would need to go back to "Proposed". *> *> Feedback appreciated, *> *> Julian *> Julian, This is a question about the IETF standards process rather than about RFCs, really. You can read what RFC 2026 says about Draft Standard in a lawyerly way, but in the end what really matters is what the current IESG members think ;-) Maybe you should take the question to the ietf list? (My personal reaction to your question would be, "generally, yes".) Bob Braden From harald@alvestrand.no Fri May 7 10:31:46 2004 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47HUsJ08898 for ; Fri, 7 May 2004 10:30:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2994961BE5; Fri, 7 May 2004 19:30:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07152-08; Fri, 7 May 2004 19:30:52 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D9E261BB5; Fri, 7 May 2004 19:30:50 +0200 (CEST) Date: Fri, 07 May 2004 09:18:54 -0700 From: Harald Tveit Alvestrand To: Aaron Falk , Julian Reschke Subject: Re: [rfc-i] RFC Standard Process question Message-ID: <747878402.1083921534@localhost> In-Reply-To: References: <409B9E2F.9030600@gmx.de> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: harald@alvestrand.no Cc: rfc-interest@rfc-editor.org, Scott Bradner X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 17:31:47 -0000 --On 7. mai 2004 08:54 -0700 Aaron Falk wrote (quoting): >> Is it possible to advance the base protocol to "Draft" while removing >> optional features from the document (possibly moving them into a >> separate document)? Yes, this is possible, and has been done. >> Looking at the history of RFC2396 (currently at "Draft") indicates >> that this has happened before, and certainly this makes a lot of >> sense. On the other hand, some people are telling me that in cases >> like these, the protocol revision would need to go back to "Proposed". The case that WOULD reset to Proposed is if you take away something, and replace it with something new to replace it. That would be an added feature. The other case is if you take away something that was required in order to have the functionality the protocol needs (for instance taking away all security functions, where security is a requirement). In that case, it's not likely to advance, because the resulting protocol would not be of Internet quality. Harald From julian.reschke@gmx.de Fri May 7 11:30:24 2004 Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id i47ITjJ24118 for ; Fri, 7 May 2004 11:29:46 -0700 (PDT) Received: (qmail 11083 invoked by uid 65534); 7 May 2004 18:29:39 -0000 Received: from pD950C24F.dip.t-dialin.net (EHLO [192.168.0.2]) (217.80.194.79) by mail.gmx.net (mp003) with SMTP; 07 May 2004 20:29:39 +0200 X-Authenticated: #1915285 Message-ID: <409BD590.7050602@gmx.de> Date: Fri, 07 May 2004 20:29:36 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [rfc-i] RFC Standard Process question References: <409B9E2F.9030600@gmx.de> <747878402.1083921534@localhost> In-Reply-To: <747878402.1083921534@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: julian.reschke@gmx.de Cc: rfc-interest@rfc-editor.org, Aaron Falk , Scott Bradner X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 18:30:25 -0000 Harald Tveit Alvestrand wrote: > The case that WOULD reset to Proposed is if you take away something, and > replace it with something new to replace it. That would be an added > feature. > > The other case is if you take away something that was required in order > to have the functionality the protocol needs (for instance taking away > all security functions, where security is a requirement). In that case, > it's not likely to advance, because the resulting protocol would not be > of Internet quality. Thanks, Harald. In this particular case, we're discussing to extract a feature that always has been optional (that is, servers don't need to support it, and clients can easily detect whether the server has support for it), so this shouldn't be an issue here. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From sob@harvard.edu Fri May 7 11:48:28 2004 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47IlxJ28278 for ; Fri, 7 May 2004 11:47:59 -0700 (PDT) Received: by newdev.harvard.edu (Postfix, from userid 501) id 1445B1E1BCF; Fri, 7 May 2004 14:47:53 -0400 (EDT) To: falk@ISI.EDU, julian.reschke@gmx.de Subject: Re: [rfc-i] RFC Standard Process question In-Reply-To: Message-Id: <20040507184753.1445B1E1BCF@newdev.harvard.edu> Date: Fri, 7 May 2004 14:47:53 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: sob@harvard.edu X-Mailman-Approved-At: Fri, 07 May 2004 13:59:53 -0700 Cc: harald@alvestrand.no, rfc-interest@rfc-editor.org, sob@harvard.edu X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 18:48:28 -0000 basic assumption for years has been that removing options (used or not) does not force a recycle Scott --- >From falk@ISI.EDU Fri May 7 11:55:58 2004 X-Original-To: sob@newdev.harvard.edu Delivered-To: sob@newdev.harvard.edu In-Reply-To: <409B9E2F.9030600@gmx.de> References: <409B9E2F.9030600@gmx.de> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-33-411382928" Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , Scott Bradner , rfc-interest@rfc-editor.org From: Aaron Falk Subject: Re: [rfc-i] RFC Standard Process question Date: Fri, 7 May 2004 08:54:41 -0700 To: Julian Reschke X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu --Apple-Mail-33-411382928 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Julian- Section 4.1.2 or rfc2026 says: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. and in section 6.2: A specification may be (indeed, is likely to be) revised as it advances through the standards track. At each stage, the IESG shall determine the scope and significance of the revision to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions are expected, but a significant revision may require that the specification accumulate more experience at its current maturity level before progressing. Finally, if the specification has been changed very significantly, the IESG may recommend that the revision be treated as a new document, re- entering the standards track at the beginning. So, it appears to me (not in any RFC Editor capacity) that removing non-implemented options is part of going from Proposed to Draft and, so, doesn't push you back to the start. However, it appears to be a judgment call _on the part of the IESG_ as to whether the changes are significant enough. Now, speaking for the RFC Editor, since this is a standards process question, not an RFC publication question, rfc-i is the wrong list. I'd suggest addressing the IESG directly and cc'ing the IETF general list or possibly the newtrk list (since they are contemplating changes to the process). --aaron On May 7, 2004, at 7:33 AM, Julian Reschke wrote: > Hi, > > I have the following question about what kind of changes are allowable > when a specification is meant to be advanced from "Proposed" to > "Draft". > > Assuming a specification defines a core protocol, plus a set of > features that are clearly marked as "optional" (so a server doesn't > need to implement them), and in particular the protocol defines how > support for these features can be discovered at runtime. > > Is it possible to advance the base protocol to "Draft" while removing > optional features from the document (possibly moving them into a > separate document)? > > Looking at the history of RFC2396 (currently at "Draft") indicates > that this has happened before, and certainly this makes a lot of > sense. On the other hand, some people are telling me that in cases > like these, the protocol revision would need to go back to "Proposed". > > Feedback appreciated, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest --Apple-Mail-33-411382928 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFAm7FB/i95hBY97NERAj32AKCOiqDYsUZyNuT6bWCJV+gdRl+qWwCgiofR kfTFHN5ssloKLzvyt66R/Vs= =gpkL -----END PGP SIGNATURE----- --Apple-Mail-33-411382928-- From hgs@cs.columbia.edu Fri May 14 18:08:38 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F16wJ28259 for ; Fri, 14 May 2004 18:06:58 -0700 (PDT) Received: from cs.columbia.edu (pool-138-89-37-220.mad.east.verizon.net [138.89.37.220]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4F16obt012360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 May 2004 21:06:51 -0400 (EDT) Message-ID: <40A56D25.9080307@cs.columbia.edu> Date: Fri, 14 May 2004 21:06:45 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: rfc-interest@rfc-editor.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.14.100834 X-PerlMx-Spam: Gauge=XXIIIIIII, Probability=27%, Report='Y_NJABL_DUL 3, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, __MIME_TEXT_ONLY 0, RELAY_IN_NJABL_ORG 0, __MOZILLA_MSGID 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Subject: [rfc-i] Draft: Representation of Unicode and UTF-8 characters X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 01:08:38 -0000 Here's a draft for the guidelines, as requested by Aaron: * Representation of Unicode and UTF-8 characters For names in acknowlegements and protocol examples, it is often desirable to represent Unicode characters, either abstractly or as the character would be coded in UTF-8 (RFC 3629). To avoid violating the US-ASCII-only rule for RFCs, it is suggested to write these characters using the following textual conventions: - Unicode strings use the notation suggested by the Unicode specification (http://www.unicode.org/versions/Unicode4.0.0/Preface.pdf#G1771), for example "Mnchen" for the Bavarian city Munich. - UTF-8 strings enumerate the bytes as uppercase hexadecimal digits in angled brackets, e.g., for the (copyright) character. - The literal < uses the Unicode rendition in those cases where this can be misinterpreted, i.e., where the open angle bracket is followed by U+ or a hex digit. Documents may choose a different convention, but then need to explain the notation. From rousskov@measurement-factory.com Fri May 14 21:05:40 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F441J01775 for ; Fri, 14 May 2004 21:04:01 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i4F43Cp6004327; Fri, 14 May 2004 22:03:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i4F43BV4004326; Fri, 14 May 2004 22:03:11 -0600 (MDT) (envelope-from rousskov) Date: Fri, 14 May 2004 22:03:11 -0600 (MDT) From: Alex Rousskov To: Henning Schulzrinne Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters In-Reply-To: <40A56D25.9080307@cs.columbia.edu> Message-ID: References: <40A56D25.9080307@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 04:05:40 -0000 On Fri, 14 May 2004, Henning Schulzrinne wrote: > * Representation of Unicode and UTF-8 characters > > For names in acknowlegements and protocol examples, it is often > desirable to represent Unicode characters, either abstractly or as > the character would be coded in UTF-8 (RFC 3629). FWIW, I would suggest to make the above more generic to avoid an implication that "names in acknowledgments and protocol examples" are the only use cases. I am also not sure what "abstract representation" is. How about something along these lines: IETF documents may need to represent Unicode characters while obeying the US-ASCII encoding rules. Unicode use cases include protocol examples and human names in acknowledgments. To represent Unicode characters in IETF documents, authors should use the following conventions: > To avoid violating the US-ASCII-only rule for RFCs, it is suggested > to write these characters using the following textual conventions: > > - Unicode strings use the notation suggested by the > Unicode specification > (http://www.unicode.org/versions/Unicode4.0.0/Preface.pdf#G1771), for > example "Mnchen" for the Bavarian city Munich. Why is U+1234 repeated above? If you meant to illustrate that "," is a character separator, consider using different characters. > - UTF-8 strings enumerate the bytes as uppercase hexadecimal digits in > angled brackets, e.g., for the (copyright) character. Is space the only correct delimiter here? Why is it inconsistent with comma delimiter used above? > - The literal < uses the Unicode rendition in those cases > where this can be misinterpreted, i.e., where the open angle bracket > is followed by U+ or a hex digit. Could somebody with direct access to a large RFC repository please scan it for " sequence matches the pattern and not just the prefix? > Documents may choose a different convention, but then need to > explain the notation. To make this work reliably, especially with automated tools, we need a blob of text that authors can include to indicate they _are_ following the above convention. RFCs without the blob would be assumed not to follow the convention (by default). Otherwise, it might not be clear whether an RFC is unaware of the above convention or knowingly uses it! An alternative is mandatory usage enforced by RFC Editor, but I am guessing we do not want to go that far. $0.02, Alex. From Kurt@OpenLDAP.org Fri May 14 21:48:56 2004 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F4mpJ09154 for ; Fri, 14 May 2004 21:48:51 -0700 (PDT) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id i4F4mNnC097615; Sat, 15 May 2004 04:48:23 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.0.1.1.0.20040514210809.02ca2630@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 21:48:27 -0700 To: Henning Schulzrinne From: "Kurt D. Zeilenga" Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters In-Reply-To: <40A56D25.9080307@cs.columbia.edu> References: <40A56D25.9080307@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: kurt@openldap.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 04:48:57 -0000 At 06:06 PM 5/14/2004, Henning Schulzrinne wrote: >Documents may choose a different convention, but then need to explain the notation. I think it would be better to say: Documents may choose different conventions. Regardless of what conventions are used, an explanation of the conventions used should be incorporated (possibly by reference) into the document. As this web page is subject to change, documents using these conventions should either directly incorporate applicable portions of the above explanation into their documents or incorporate by reference the Unicode specifications from which these conventions are derived from. Or restrict the use of these conventions (without incorporation) to Authors' Address, Acknowledgments, Contributors, References, and other sections which aren't specifying the protocol or providing examples of the protocol. Otherwise, we'll documents using unclear conventions inappropriately. Conventions stated outside of a protocol specification (include examples in that specifications) should be clear. Referencing a web page is not a good way to make conventions clear. Kurt From henrik@levkowetz.com Sat May 15 02:16:04 2004 Received: from av5-1-sn3.vrr.skanova.net (av5-1-sn3.vrr.skanova.net [81.228.9.113]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F9FOJ25554 for ; Sat, 15 May 2004 02:15:24 -0700 (PDT) Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 6551F37EB5; Sat, 15 May 2004 11:15:18 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5212437E87; Sat, 15 May 2004 11:15:18 +0200 (CEST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4433D38010; Sat, 15 May 2004 11:15:17 +0200 (CEST) Received: from chardonnay ([127.0.0.1]) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1BOvGG-000195-00; Sat, 15 May 2004 11:15:16 +0200 Date: Sat, 15 May 2004 11:15:15 +0200 From: Henrik Levkowetz To: Alex Rousskov Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters Message-Id: <20040515111515.72994d20.henrik@levkowetz.com> In-Reply-To: References: <40A56D25.9080307@cs.columbia.edu> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: henrik@levkowetz.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 09:16:05 -0000 Hi Alex, Friday 14 May 2004, Alex Rousskov wrote: > > - The literal < uses the Unicode rendition in those cases > > where this can be misinterpreted, i.e., where the open angle bracket > > is followed by U+ or a hex digit. > > Could somebody with direct access to a large RFC repository please > scan it for " probability that an unaware RFC uses the above convention [for > something else]? "" occurs on 444 lines in RFC's, most of which use it to indicate carriage advance, form feed, or html markup (e.g.

). All those RFC's are numbered below 1000. Henrik ---- Rawer data ------------------------------------------------------- $ grep "moglobin" in American vs. British English. rfc3454.txt: example,"") vs. the equivalent traditional rfc3454.txt: Chinese spelling (for example, ""). rfc3454.txt: Language-specific equivalences such as "Aepfel" vs. "pfel", rfc3454.txt: definitions; Latin digits ( through ) are examples of rfc3454.txt: Note that requirement 3 prohibits strings such as rfc3454.txt: ("aleph 1") but allows strings such as $ grep "<[A-H0-9][A-H0-9]\( [A-H0-9][A-H0-9]\)*>" rfc*.txt | wc -l 444 $ grep "<[A-H0-9][A-H0-9]\( [A-H0-9][A-H0-9]\)*>" rfc*.txt | grep "" | wc -l 238 $ grep "<[A-H0-9][A-H0-9]\( [A-H0-9][A-H0-9]\)*>" rfc*.txt | grep "" | wc -l 60 $ grep "<[A-H0-9][A-H0-9]\( [A-H0-9][A-H0-9]\)*>" rfc*.txt | grep "" | wc -l 28 $ grep "<[A-H0-9][A-H0-9]\( [A-H0-9][A-H0-9]\)*>" rfc*.txt | tail rfc732.txt: <17>Telephone number: rfc732.txt: <32><4> rfc732.txt: <24>Social Security Number: rfc732.txt: <0><11> [Establish a field that rfc732.txt: <32><5> rfc732.txt: Intensity=1><0><29> rfc732.txt: rfc765.txt: (i.e., , , , , ) which the printer rfc929.txt: 4 Format effectors rfc959.txt: (i.e., , , , , ) which the printer From paul.hoffman@vpnc.org Sat May 15 08:52:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4FFqoJ04013 for ; Sat, 15 May 2004 08:52:51 -0700 (PDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4FFqkTG024684 for ; Sat, 15 May 2004 08:52:47 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <40A56D25.9080307@cs.columbia.edu> References: <40A56D25.9080307@cs.columbia.edu> Date: Sat, 15 May 2004 08:52:45 -0700 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 15:52:57 -0000 At 9:06 PM -0400 5/14/04, Henning Schulzrinne wrote: >For names in acknowlegements and protocol examples... Two notes of major concern here: - Why is there a difference between names in acknowledgements and names of RFC authors? If this has been in place a little over a year ago, Patrik Fältström would have had his name spelled differently in RFC 3490 and RFC 3491, even though the two RFCs cover the same protocol. - Has anyone asked folks who have non-ASCII characters in their names how they feel about this? If not, we should stop immediately on this thread. Somehow, I can imagine that someone would rather have their name in the acknowledgements be spelled Jose Munoz instead of Jos Muoz --Paul Hoffman, Director --VPN Consortium From rousskov@measurement-factory.com Sat May 15 09:33:00 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4FGWDJ10531 for ; Sat, 15 May 2004 09:32:13 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i4FGWDp6044669; Sat, 15 May 2004 10:32:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i4FGWDUq044668; Sat, 15 May 2004 10:32:13 -0600 (MDT) (envelope-from rousskov) Date: Sat, 15 May 2004 10:32:13 -0600 (MDT) From: Alex Rousskov To: Paul Hoffman / VPNC Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters In-Reply-To: Message-ID: References: <40A56D25.9080307@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by boreas.isi.edu id i4FGWDJ10531 Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 16:33:00 -0000 My assumption is that, just like today, the spelling would be up to the author/editor writing the document; a person whose name is being spelled is given an informal opportunity to correct or suggest a different spelling. Thus, Patrik would be able to use whatever spelling he prefers. This is no different from current situation except folks do not have the opportunity to use Unicode characters. I agree that the necessity is debatable, but I assume that since folks propose it, they want/need it. FWIW, I have non-ASCII characters in my name, but would not use them in an all-ASCII all-English document. Note that the polished wording I proposed does not imply that "names in acknowledgments" is a special or one of two special cases. The document author can use the proposed representation for whatever purpose she needs (subject to other IETF rules, of course). Thanks, Alex. On Sat, 15 May 2004, Paul Hoffman / VPNC wrote: > At 9:06 PM -0400 5/14/04, Henning Schulzrinne wrote: > >For names in acknowlegements and protocol examples... > > Two notes of major concern here: > > - Why is there a difference between names in acknowledgements and > names of RFC authors? If this has been in place a little over a year > ago, Patrik Fältström would have had his name spelled differently in > RFC 3490 and RFC 3491, even though the two RFCs cover the same > protocol. > > - Has anyone asked folks who have non-ASCII characters in their names > how they feel about this? If not, we should stop immediately on this > thread. Somehow, I can imagine that someone would rather have their > name in the acknowledgements be spelled > Jose Munoz > instead of > Jos Muoz > > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest > From hgs@cs.columbia.edu Sat May 15 10:37:58 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4FHb2J22391 for ; Sat, 15 May 2004 10:37:02 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4FHavbt013966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 May 2004 13:36:57 -0400 (EDT) Message-ID: <40A65539.1040508@cs.columbia.edu> Date: Sat, 15 May 2004 13:36:57 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters References: <40A56D25.9080307@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.14.100877 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org, Paul Hoffman / VPNC X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 17:37:58 -0000 > Note that the polished wording I proposed does not imply that "names > in acknowledgments" is a special or one of two special cases. The > document author can use the proposed representation for whatever > purpose she needs (subject to other IETF rules, of course). The reason I chose the restricted wording is simple: since author names are used in various RFC databases, HTML RFC index pages and the like, inserting into those items seems counterproductive at this point. Naturally, this concern does not apply to acknowledgments, so personal preference can be given wider latitude there. Henning From hgs@cs.columbia.edu Sat May 15 11:06:57 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4FI6SJ27300 for ; Sat, 15 May 2004 11:06:28 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4FI5vbt015646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 May 2004 14:06:06 -0400 (EDT) Message-ID: <40A65C05.1020402@cs.columbia.edu> Date: Sat, 15 May 2004 14:05:57 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters References: <40A56D25.9080307@cs.columbia.edu> <6.0.1.1.0.20040514210809.02ca2630@127.0.0.1> In-Reply-To: <6.0.1.1.0.20040514210809.02ca2630@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.14.100877 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, __CHILD_PORN_NOT_1 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 18:06:58 -0000 > > Documents may choose different conventions. Regardless of what > conventions are used, an explanation of the conventions used > should be incorporated (possibly by reference) into the document. > > As this web page is subject to change, documents using these > conventions should either directly incorporate applicable portions > of the above explanation into their documents or incorporate by > reference the Unicode specifications from which these conventions > are derived from. Sure. > > Or restrict the use of these conventions (without incorporation) > to Authors' Address, Acknowledgments, Contributors, References, > and other sections which aren't specifying the protocol or > providing examples of the protocol. Since examples are the more (technically) important part of the motivation for this convention, I don't think this would be helpful. Since the description is one sentence long, including it is hardly an undue burden. > > Otherwise, we'll documents using unclear conventions inappropriately. > Conventions stated outside of a protocol specification (include > examples in that specifications) should be clear. Referencing a > web page is not a good way to make conventions clear. Agreed. > > Kurt From hgs@cs.columbia.edu Sat May 15 11:24:20 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4FINBJ00890 for ; Sat, 15 May 2004 11:23:11 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4FIN7bt016667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 May 2004 14:23:07 -0400 (EDT) Message-ID: <40A6600A.1010003@cs.columbia.edu> Date: Sat, 15 May 2004 14:23:06 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters References: <40A56D25.9080307@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.14.100877 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2004 18:24:20 -0000 > FWIW, I would suggest to make the above more generic to avoid an > implication that "names in acknowledgments and protocol examples" are > the only use cases. I am also not sure what "abstract representation" > is. How about something along these lines: > > IETF documents may need to represent Unicode characters while > obeying the US-ASCII encoding rules. Unicode use cases include > protocol examples and human names in acknowledgments. To > represent Unicode characters in IETF documents, authors should > use the following conventions: > Sure. > >>- UTF-8 strings enumerate the bytes as uppercase hexadecimal digits in >>angled brackets, e.g., for the (copyright) character. > > > Is space the only correct delimiter here? Why is it inconsistent with > comma delimiter used above? Both should probably use spaces - saves space. I misread the Unicode example. > To reduce the number of violations, should conflicts be restricted to > cases where the whole <> sequence matches the pattern and not just the > prefix? Yes. > > >>Documents may choose a different convention, but then need to >>explain the notation. > > > To make this work reliably, especially with automated tools, we need a > blob of text that authors can include to indicate they _are_ following > the above convention. RFCs without the blob would be assumed not to > follow the convention (by default). Otherwise, it might not be clear > whether an RFC is unaware of the above convention or knowingly uses > it! > > An alternative is mandatory usage enforced by RFC Editor, but I am > guessing we do not want to go that far. I suspect the more common case is that these will be xml2rfc drafts, where the author can turn on the relevant flag for appropriate HTML rendering. I don't think that translating plain-text RFCs into ASCII with a sprinkling of UTF-8/Unicode is all that helpful. For example, for protocol examples, I will likely want to see the underlying codes, to simply generating test examples from that. I think there is a danger of over-engineering here... > > $0.02, > > Alex. From rousskov@measurement-factory.com Mon May 17 08:27:59 2004 Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4HFRAJ13519 for ; Mon, 17 May 2004 08:27:10 -0700 (PDT) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i4HFQnp6085013; Mon, 17 May 2004 09:26:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i4HFQmRG085012; Mon, 17 May 2004 09:26:48 -0600 (MDT) (envelope-from rousskov) Date: Mon, 17 May 2004 09:26:48 -0600 (MDT) From: Alex Rousskov To: Henrik Levkowetz Subject: Re: [rfc-i] Draft: Representation of Unicode and UTF-8 characters In-Reply-To: <20040515111515.72994d20.henrik@levkowetz.com> Message-ID: References: <40A56D25.9080307@cs.columbia.edu> <20040515111515.72994d20.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rousskov@measurement-factory.com Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 15:28:00 -0000 On Sat, 15 May 2004, Henrik Levkowetz wrote: > " all using it to indicate Unicode. > > "<[A-H0-9][A-H0-9]( [A-H0-9][A-H0-9])*>" occurs on 444 lines in > RFC's, most of which use it to indicate carriage advance, form feed, > or html markup (e.g.

). All those RFC's are numbered below > 1000. Thanks for checking this, Henrik. It looks like there is no serious issue with past RFCs, although conflicts with popular HTML tags and less popular bracketed ASCII characters are rather unfortunate. Alex. From john+rfc@jck.com Mon May 17 13:18:44 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4HKI8J11790 for ; Mon, 17 May 2004 13:18:08 -0700 (PDT) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 1BPoYp-000Pb8-00 for rfc-interest@rfc-editor.org; Mon, 17 May 2004 15:18:07 -0500 Date: Mon, 17 May 2004 16:18:06 -0400 From: John C Klensin To: rfc-interest@rfc-editor.org Message-ID: <3BCBB4B45DA6699F8C0468F1@scan.jck.com> In-Reply-To: <200405171900.i4HJ05J18739@boreas.isi.edu> References: <200405171900.i4HJ05J18739@boreas.isi.edu> X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com Subject: [rfc-i] Re: Draft: Representation of Unicode and UTF-8 characters X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 20:18:44 -0000 --On Mon, 17 May 2004 09:26:48 -0600 (MDT), Alex Rousskov wrote... > On Sat, 15 May 2004, Henrik Levkowetz wrote: > >> "> 3454), and all using it to indicate Unicode. >> >> "<[A-H0-9][A-H0-9]( [A-H0-9][A-H0-9])*>" occurs on 444 lines >> in RFC's, most of which use it to indicate carriage advance, >> form feed, or html markup (e.g.

). All those RFC's are >> numbered below 1000. > > Thanks for checking this, Henrik. It looks like there is no > serious issue with past RFCs, although conflicts with popular > HTML tags and less popular bracketed ASCII characters are > rather unfortunate. Actually, Alex, Henrik, U+ notation (without the brackets) also appears in RFC 3743 and, I think, in several other places. That will, of course, not be picked up by Henrik's scan. FWIW. I also share the concern about overengineering this as well as Paul Hoffman's concern about changing mnemonic, but incorrectly-written, names into ones that look really ugly and lose mnenomic value. For names containing non-ASCII characters, it would seem to me to be appropriate to have, not only "author's choice", but also some convention for representing both "spellings" in the text. john From hgs@cs.columbia.edu Tue May 18 11:22:52 2004 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4IIMUJ12138 for ; Tue, 18 May 2004 11:22:30 -0700 (PDT) Received: from cs.columbia.edu (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4IIMMbt015842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 May 2004 14:22:26 -0400 (EDT) Message-ID: <40AA545D.9080103@cs.columbia.edu> Date: Tue, 18 May 2004 14:22:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [rfc-i] Re: Draft: Representation of Unicode and UTF-8 characters References: <200405171900.i4HJ05J18739@boreas.isi.edu> <3BCBB4B45DA6699F8C0468F1@scan.jck.com> In-Reply-To: <3BCBB4B45DA6699F8C0468F1@scan.jck.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.18.101048 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, __UNUSABLE_MSGID 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 18:22:53 -0000 > I also share the concern about overengineering this as well as Paul > Hoffman's concern about changing mnemonic, but incorrectly-written, > names into ones that look really ugly and lose mnenomic value. For > names containing non-ASCII characters, it would seem to me to be > appropriate to have, not only "author's choice", but also some > convention for representing both "spellings" in the text. > I've added text to the draft to require that all names have an ASCII-only spelling: * Representation of Unicode and UTF-8 characters IETF documents may need to represent Unicode characters while obeying the US-ASCII encoding rules. Unicode use cases include protocol examples and human names in acknowledgments. To represent Unicode characters in IETF documents, authors should use the following conventions: - Unicode strings use the notation suggested by the Unicode specification (http://www.unicode.org/versions/Unicode4.0.0/Preface.pdf#G1771), for example "Mnchen" for the Bavarian city Munich. - UTF-8 (RFC 3629) strings enumerate the bytes as uppercase hexadecimal digits in angled brackets, e.g., for the (copyright) character. - The literal < uses the Unicode rendition in those cases where this can be misinterpreted, i.e., where the open angle bracket is followed by U+ or a hex digit. Author and editor names in the RFC headings should not use this convention, as these names are included in databases, listings and web pages, where such usage would likely be confusing. Other names (e.g., in the list of contributors or acknowledgments) must provide the ASCII-only form first. For example, Wilhelm Conrad Roentgen (Rntgen), for the discoverer of X-rays. Documents may choose different conventions. Regardless of what conventions are used, an explanation of the conventions used should be incorporated into the document. As this web page is subject to change, documents using these conventions should either directly incorporate applicable portions of the above explanation into their documents or incorporate by reference the Unicode specifications from which these conventions are derived from. From fw@deneb.enyo.de Wed May 19 16:04:58 2004 Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4JN4SJ17170 for ; Wed, 19 May 2004 16:04:33 -0700 (PDT) Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BQa6p-00045h-6b for rfc-interest@rfc-editor.org; Thu, 20 May 2004 01:04:23 +0200 Received: from fw by deneb with local (Exim 4.34) id 1BQa6o-0002Pf-HO for rfc-interest@rfc-editor.org; Thu, 20 May 2004 01:04:22 +0200 To: rfc-interest@rfc-editor.org From: Florian Weimer Date: Thu, 20 May 2004 01:04:22 +0200 Message-ID: <877jv8m32h.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: fw@deneb.enyo.de Subject: [rfc-i] BibTeX entries for RFCs X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2004 23:04:58 -0000 Is there an up-to-date collection of BibTeX entries for RFCs? Has anybody succeeded in converting the bibliographical data on http://xml.resource.org/ ? I don't want to start completely from scratch, and compiling references manually is error-prone (and some researcher might claim I haven't read all those RFCs I'm citing if I introduce any errors 8-). From hgs@cs.columbia.edu Wed May 19 17:37:58 2004 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4K0bTJ13451 for ; Wed, 19 May 2004 17:37:29 -0700 (PDT) Received: from razor.cs.columbia.edu (IDENT:XHo6e/LIxVtf62L2KuPi2/eMVW/OUdho@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4K0aoV7027396 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 19 May 2004 20:36:50 -0400 (EDT) Received: from cs.columbia.edu (IDENT:fRH1034RmzHQfGzQTn9nbefk45WxnL3C@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i4K0aj4u021586; Wed, 19 May 2004 20:36:49 -0400 Message-ID: <40ABFDA5.7090200@cs.columbia.edu> Date: Wed, 19 May 2004 20:36:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer Subject: Re: [rfc-i] BibTeX entries for RFCs References: <877jv8m32h.fsf@deneb.enyo.de> In-Reply-To: <877jv8m32h.fsf@deneb.enyo.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: 2004.5.19.101193 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report='URI_HEAVY 0.206, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, __MOZILLA_MSGID 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 00:37:59 -0000 http://www.cs.columbia.edu/~hgs/bib (rfc.bib, i-d.bib) http://www.cs.columbia.edu/~hgs/netbib Florian Weimer wrote: > Is there an up-to-date collection of BibTeX entries for RFCs? Has > anybody succeeded in converting the bibliographical data on > http://xml.resource.org/ ? > > I don't want to start completely from scratch, and compiling > references manually is error-prone (and some researcher might claim I > haven't read all those RFCs I'm citing if I introduce any errors 8-). > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest From falk@ISI.EDU Tue Jun 1 15:13:07 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i51MCpJ28573 for ; Tue, 1 Jun 2004 15:12:51 -0700 (PDT) Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i51MCEH18947; Tue, 1 Jun 2004 15:12:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Aaron Falk Date: Tue, 1 Jun 2004 15:12:13 -0700 To: rfc-interest@rfc-editor.org X-Mailer: Apple Mail (2.618) X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: "Sean M. Burke" Subject: [rfc-i] RFC (and ID) announcements via RSS X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:13:07 -0000 Folks- Sean Burke put together a very nifty RSS feed of RFC and ID announcements. Forwarding with his encouragement... --aaron Begin forwarded message: > > > On May 28, 2004, at 6:31 PM, Sean M. Burke wrote: > >> At 01:54 PM 2004-05-28, you wrote: >>> Seems to be fixed. Can you send the info on the RSS feed? I know >>> you asked about us supporting it last year and am glad you put it >>> together on your own. I'd like to see what you've come up with.... >> >> OK, here's some relevent URLs: >> >> The Perl program that generates the feed: >> http://interglacial.com/rss/rfc/new_rfc_list_gen.pl >> The feed: >> http://interglacial.com/rss/rfc/new_rfcs.rss >> And the stylesheet it uses: >> http://interglacial.com/rss/rfc/rss.css >> That's it for mere RFCs. >> >> >> Meanwhile, more elaborate stuff is generated for IDs. >> The generator: >> http://interglacial.com/rss/internet-drafts/new_ids.pl >> See all the group-specific RSSs that it generates: >> http://interglacial.com/rss/internet-drafts/ >> A more machine-readable format of that list: >> >> http://interglacial.com/rss/internet-drafts/ >> internet_drafts___groups.dat >> >> >> An RSS of new RSSs in there (i.e., an RSS of new groups): >> >> http://interglacial.com/rss/internet-drafts/ >> internet_drafts___groups.rss >> >> An RSS of new ID documents across all groups: >> http://interglacial.com/rss/internet-drafts/internet-draft-__all.rss >> >> And the stylesheet that those RSSs use: >> http://interglacial.com/rss/rss.css >> >> >> I used to be very eager to get these hosted elsewhere, because I >> thought it would be responsible for a lot of server traffic. But >> that hasn't been the case, so I basically don't have to worry about >> it at all. Each of my other feeds (http://interglacial.com/rss/) >> gets a LOT more traffic than even all these RFC + ID things combined. >> So I'm perfectly happy having this all on my server. Feel free to >> link to it merrily and widely! The more the merrier the faster the >> easier. >> >> -- >> Sean M. Burke http://search.cpan.org/~sburke/ From paul.hoffman@vpnc.org Thu Jun 10 08:56:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AFuCJ15111 for ; Thu, 10 Jun 2004 08:56:12 -0700 (PDT) Received: from [10.20.30.239] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5AFu75O053745 for ; Thu, 10 Jun 2004 08:56:08 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 10 Jun 2004 08:56:08 -0700 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Subject: [rfc-i] Five-author maximum? X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 15:56:45 -0000 Greetings again. New in the pre-publication queue is: Network Working Group P. Karn, Ed. Request for Comments: 3819 Qualcomm BCP: 89 C. Bormann Category: Best Current Practice Universitaet Bremen FB3 TZI G. Fairhurst University of Aberdeen D. Grossman Motorola, Inc. R. Ludwig Ericsson Research J. Mahdavi Novell G. Montenegro Sun Microsystems Laboratories, Europe J. Touch USC/ISI L. Wood Cisco Systems June 2004 Advice for Internet Subnetwork Designers This seems to bust the five-authors suggestion by a significant number. Are each of these people really responsible for all of the content? Given Phil's designation as "Ed." on the top line, it seems likely that the author-name-padding should be removed. --Paul Hoffman, Director --VPN Consortium From mallman@icir.org Thu Jun 10 09:32:44 2004 Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AGWJJ26300 for ; Thu, 10 Jun 2004 09:32:19 -0700 (PDT) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i5AGWICJ011316; Thu, 10 Jun 2004 09:32:19 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id A9D5577AA17; Thu, 10 Jun 2004 12:32:17 -0400 (EDT) To: Paul Hoffman / VPNC From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Running On Empty MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 10 Jun 2004 12:32:17 -0400 Sender: mallman@icir.org Message-Id: <20040610163217.A9D5577AA17@guns.icir.org> X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: mallman@icir.org Subject: Re: [rfc-i] Five-author maximum? Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: mallman@icir.org List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 16:32:45 -0000 --=-=-= Content-Type: text/plain; charset=us-ascii Paul- > This seems to bust the five-authors suggestion by a significant > number. Are each of these people really responsible for all of the > content? Given Phil's designation as "Ed." on the top line, it seems > likely that the author-name-padding should be removed. Let me take a swing at this. I editted this document, as well. I took over from Phil for the final push. I was offered a spot on the author list and turned it down. This document was started before the 5-author limit was imposed. The folks (and more) on the current author list were all listed because they contributed lots of text and expertise. This is a big document and no one person had the required set of expertise to author it alone. When the 5-author limit was imposed the list was scaled back to just Phil. However, when we were preparing the last version of the document that felt all wrong. The people on the current author list had contributed substantially. And, it wasn't clear that we could pick 4 (besides Phil) who clearly contributed more than folks who would then have to be left off. In the 5-author policy there is a bit of wiggle room and an appeal was sent to Harald (and the IESG maybe) who seemed fine with wiggling in this particular case -- i.e., it wasn't an oversight, it was an explicit decision. That's the story. We might reasonably disagree whether it should be Phil or Phil+everyone else, or about the general policy, or whatever. **However**, I completely **reject** the notion that this document is "padded" with authors. If one were to look at the record from the PILC WG, I think one would see that all these folks made a substanative contribution. Further, this was an explicit decision not an oversight. Sorry for being a bit sensative here, but simply counting authors and suggesting author padding without attempting to understand the context and the process that was used to arrive at the author list slights these folk's work, IMO. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAyI0RWyrrWs4yIs4RAmApAJ9afvhdEHiRcv0bfKUKwWVyRySFbwCglvFU /RkZkRiVqCT3laGI8OQADmQ= =hwfb -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Thu Jun 10 09:47:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AGlQJ00591 for ; Thu, 10 Jun 2004 09:47:26 -0700 (PDT) Received: from [10.20.30.239] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5AGlLm1061774; Thu, 10 Jun 2004 09:47:22 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040610163217.A9D5577AA17@guns.icir.org> References: <20040610163217.A9D5577AA17@guns.icir.org> Date: Thu, 10 Jun 2004 09:47:23 -0700 To: mallman@icir.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Five-author maximum? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 16:47:46 -0000 At 12:32 PM -0400 6/10/04, Mark Allman wrote: >i.e., it wasn't an oversight, it was an explicit >decision. That's the story. Sounds good to me. It's hard to know that from looking at the document, of course. >We might reasonably disagree whether it should be Phil or Phil+everyone >else, or about the general policy, or whatever. **However**, I >completely **reject** the notion that this document is "padded" with >authors. If one were to look at the record from the PILC WG, I think >one would see that all these folks made a substanative contribution. >Further, this was an explicit decision not an oversight. Sorry for >being a bit sensative here, but simply counting authors and suggesting >author padding without attempting to understand the context and the >process that was used to arrive at the author list slights these folk's >work, IMO. My point about padding was in the Phil or Phil+everyone debate, not whether those people did much work. In many IETF documents, more than 5 people contribute a great deal of thought and text. --Paul Hoffman, Director --VPN Consortium From dmm@1-4-5.net Thu Jun 10 09:54:47 2004 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AGrjJ02242 for ; Thu, 10 Jun 2004 09:53:45 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i5AGrgIh020024; Thu, 10 Jun 2004 09:53:42 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) id i5AGrg0J020023; Thu, 10 Jun 2004 09:53:42 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 10 Jun 2004 09:53:42 -0700 From: David Meyer To: Paul Hoffman / VPNC Subject: Re: [rfc-i] Five-author maximum? Message-ID: <20040610165342.GA20015@1-4-5.net> References: <20040610163217.A9D5577AA17@guns.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: dmm@1-4-5.net Cc: rfc-interest@rfc-editor.org, mallman@icir.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 16:54:48 -0000 On Thu, Jun 10, 2004 at 09:47:23AM -0700, Paul Hoffman / VPNC wrote: >> At 12:32 PM -0400 6/10/04, Mark Allman wrote: >> >i.e., it wasn't an oversight, it was an explicit >> >decision. That's the story. >> >> Sounds good to me. It's hard to know that from looking at the >> document, of course. >> >> >We might reasonably disagree whether it should be Phil or Phil+everyone >> >else, or about the general policy, or whatever. **However**, I >> >completely **reject** the notion that this document is "padded" with >> >authors. If one were to look at the record from the PILC WG, I think >> >one would see that all these folks made a substanative contribution. >> >Further, this was an explicit decision not an oversight. Sorry for >> >being a bit sensative here, but simply counting authors and suggesting >> >author padding without attempting to understand the context and the >> >process that was used to arrive at the author list slights these folk's >> >work, IMO. >> >> My point about padding was in the Phil or Phil+everyone debate, not >> whether those people did much work. In many IETF documents, more than >> 5 people contribute a great deal of thought and text. Definitely true. One thing we should likely keep in mind here is that the point of this rule (AFAIK) is to help out the RFC Editor (and hence streamline our process). There are many ways to give credit in those cases where there is an editor (like a Contributors section, distinct from the Acknowledgments section). In any event, that is what I have done on several occasions, and it seems to work pretty well. Dave From falk@ISI.EDU Thu Jun 10 10:28:47 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AHSZJ11671 for ; Thu, 10 Jun 2004 10:28:35 -0700 (PDT) Received: from [128.9.168.79] (nak.isi.edu [128.9.168.79]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AHR9W17591; Thu, 10 Jun 2004 10:27:09 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65D850F1-BB03-11D8-B776-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] Five-author maximum? Date: Thu, 10 Jun 2004 10:27:07 -0700 To: Paul Hoffman / VPNC X-Mailer: Apple Mail (2.618) X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 17:28:47 -0000 On Jun 10, 2004, at 8:56 AM, Paul Hoffman / VPNC wrote: > This seems to bust the five-authors suggestion by a significant > number. Are each of these people really responsible for all of the > content? Given Phil's designation as "Ed." on the top line, it seems > likely that the author-name-padding should be removed. > Paul- A reasonable question. Hopefully, the email below will answer your concerns. It was sent by a co-chair of the working group which produced the document (me) and sent to the responsible AD (Allison) and the IESG Chair (Harald). Begin forwarded message: > From: Aaron Falk > Date: November 3, 2003 2:30:59 PM PST > To: Allison Mankin , Harald Tveit Alvestrand > > Subject: authors for draft-ietf-pilc-link-design > > Allison, Harald- > > Because of my role in RFC Editor, I felt it would be useful to make > draft-ietf-pilc-link-design an early test case in limiting authors. > Some time ago, while the document was in final working group editing, > we reduced the author count from twelve: > > Phil Karn, Carsten Bormann, Gorry Fairhurst, Aaron Falk, Dan > Grossman, Reiner Ludwig, Jamshid Mahdavi, Saverio Mascolo, > Marie-Jose Montpetit, Gabriel Montenegro, Joe Touch, Lloyd Wood > > to one (plus the wg): > > Phil Karn, editor > Performance Implications of Link Characteristics Working Group > > with a detailed contributors section immediately following the > abstract. > > However, as time has passed the unfairness of this approach has > started to grate on me and I feel that it was, basically, the Wrong > Thing to do. What I'd like to do is put the most significant > contributors, who number eight: > > Phil Karn, Carsten Bormann, Gorry Fairhurst, Dan Grossman, Reiner > Ludwig, Jamshid Mahdavi, Joe Touch, Lloyd Wood > > on the cover page. > > Reading the policy carfully > (http://www.rfc-editor.org/policy.html#policy.authlist), there is no > hard limit at five authors. The policy states that the exceptions to > the guidelines may be granted "by specific IESG request." So, I'd > like to ask that you request an exception with the following > justification: > > The document "Advice to Subnet Designers" is a compendium on variety > of topics relating (mostly) transport performance to link design > parameters. The proposed authors each contributed deep expertise > without which the document would have been incomplete. While this > document represents the consensus of the PILC working group, the > listed contibutors each share significant responsibility (& credit & > blame) for creating the document. Listing only one name gives undue > credit to the sole person listed. Listing a subset of the group is > unfair because each one made a significant contribution to the end > product. For this reason, I would like to request that IESG solicit > an exemption to the five author policy of the RFC Editor. I believe > they and the community will benefit from the clear association of > this list of authors with the content. > > I should note that none of the authors has requested that I do this. > There was some grumbling when we went from twelve to one but that was > some time ago. I am making this request only because my conscience is > bugging me. > > I am quite conscious of the potential appearance of a conflict of > interest in this situation. However, because the request for > exception must come from the IESG, rather than me, I don't believe my > role as part of the RFC Editor should play a role in making this > decision. > > Thanks, > > --aaron > In response to this request, Allison suggested that I add some text which was meant to head off any concerns of author padding. The resulting "Contributors" section describes some of the specific contributions of each listed author, as well as some we chose not to list as authors (including myself and Mark Allman): > Contributors > > This document represents a consensus of the members of the IETF > Performance Implications of Link Characteristics (PILC) working > group. > > This document would not have been possible without the contributions > of a great number of people in the Performance Implications of Link > Characteristics Working Group. In particular, the following people > provided major contributions of text, editing and advice to this > document: Mark Allman provided the final editing to complete this > document. Carsten Bormann provided text on robust header > compression. Gorry Fairhurst provided text on broadcast and > multicast issues and many valuable comments on the entire document. > Aaron Falk provided text on bandwidth on demand. Dan Grossman > provided text on security considerations as well as on many facets > of > the document. Reiner Ludwig provided thorough document review and > text on TCP vs. Link-Layer Retransmission. Jamshid Mahdavi provided > text on TCP performance calculations. Saverio Mascolo provided > feedback on the document. Gabriel Montenegro provided feedback on > the document. Marie-Jose Montpetit provided text on bandwidth on > demand. Joe Touch provided text on multicast and broadcast. and > Lloyd Wood provided many valuable comments on drafts of the > document. I hope this addresses your concern. Regards, --aaron From paul.hoffman@vpnc.org Thu Jun 10 11:01:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AI0mJ21524 for ; Thu, 10 Jun 2004 11:00:48 -0700 (PDT) Received: from [10.20.30.239] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5AI0hEX070795 for ; Thu, 10 Jun 2004 11:00:44 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Thu, 10 Jun 2004 11:00:47 -0700 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Subject: [rfc-i] Status of draft-rfc-editor-rfc2223bis? X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:01:45 -0000 Greetings again. According to the Internet Drafts tracker, draft-rfc-editor-rfc2223bis has been stuck for nine months waiting for comments back to the shepherding AD (Harald Alvestrand). Is that really true? We reall need this document finished and made an RFC. If it isn't true, someone should get the I-D tracker to reflect reality. --Paul Hoffman, Director --VPN Consortium From dmm@1-4-5.net Thu Jun 10 11:09:58 2004 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AI9IJ24171 for ; Thu, 10 Jun 2004 11:09:18 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i5AI9IBM021925; Thu, 10 Jun 2004 11:09:18 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) id i5AI9Ikv021924; Thu, 10 Jun 2004 11:09:18 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 10 Jun 2004 11:09:18 -0700 From: David Meyer To: Paul Hoffman / VPNC Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Message-ID: <20040610180918.GA21898@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: dmm@1-4-5.net Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:09:58 -0000 On Thu, Jun 10, 2004 at 11:00:47AM -0700, Paul Hoffman / VPNC wrote: >> Greetings again. According to the Internet Drafts tracker, >> draft-rfc-editor-rfc2223bis has been stuck for nine months waiting >> for comments back to the shepherding AD (Harald Alvestrand). Is that >> really true? We reall need this document finished and made an RFC. If >> it isn't true, someone should get the I-D tracker to reflect reality. >> >> Let me suggest that it can get worse. What happens when a document goes into "Expert Review :: External Party", and an expert registers comments (that get into the COMMENTS field), then never responds to the author's response to the comments? This is one way to effectively block a document (this is very much like filibuster, only by silence). Dave From narten@us.ibm.com Thu Jun 10 11:33:44 2004 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AIXaJ01963 for ; Thu, 10 Jun 2004 11:33:37 -0700 (PDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i5AIXMhF496016; Thu, 10 Jun 2004 14:33:22 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5AIY5DY097908; Thu, 10 Jun 2004 14:34:05 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id i5AIXOI4009425; Thu, 10 Jun 2004 14:33:24 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i5AIXOr9009421; Thu, 10 Jun 2004 14:33:24 -0400 Message-Id: <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> To: David Meyer In-Reply-To: Message from dmm@1-4-5.net of "Thu, 10 Jun 2004 11:09:18 PDT." <20040610180918.GA21898@1-4-5.net> Date: Thu, 10 Jun 2004 14:33:24 -0400 From: Thomas Narten X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: narten@us.ibm.com Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Cc: rfc-interest@rfc-editor.org, Paul Hoffman / VPNC X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:33:44 -0000 David, This is not really a topic for this list, but I can't ignore this either. > Let me suggest that it can get worse. What happens when a > document goes into "Expert Review :: External Party", and > an expert registers comments (that get into the COMMENTS > field), then never responds to the author's response to > the comments? This is one way to effectively block > a document (this is very much like filibuster, only by > silence). If a document gets stuck like this, frustrated parties should contact the Shepherding AD. If that doesn't get a reasonable response, escalate, either by trying other ADs you think might listen, or going directly to Harald (as IETF Chair). But letting documents just sit is not acceptable. I don't think anyone would argue for that. Thomas From braden@ISI.EDU Thu Jun 10 11:43:08 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AIgHJ05216; Thu, 10 Jun 2004 11:42:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA25497; Thu, 10 Jun 2004 11:42:16 -0700 (PDT) Date: Thu, 10 Jun 2004 11:42:16 -0700 (PDT) Message-Id: <200406101842.LAA25497@gra.isi.edu> To: paul.hoffman@vpnc.org Subject: Re: [rfc-i] Five-author maximum? X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-interest@rfc-editor.org, mallman@icir.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:43:08 -0000 I would like to make some general observations about the author list question, from our viewpoint here in the RFC Editor organization. We initiated the limit on authors, maybe a year ago (? ... how time flies), when we observed a disturbing trend towards RFC author list inflation. One factor driving this inflation seemed to be in increasing involvement of players from industry, particularly the telecomm industry, on the IETF stage. There seemed to be an urge for every company to get their name on RFCs, by having one of their guys as one of the authors, and the author lists were beginning to read like an article on the telecomm or IT industry in the WSJ. This seemed to us to be contrary to the long-standing tradition of individual, not corporate, efforts in the Internet technical community. The other tendency was to include everyone in a WG who contributed to a document. But this is a slippery slope, and we seemed to be starting a serious slide down it. It is true that this is not a new issue. In 1987-89 I chaired the Host Requirements Working Group. The Acknowledgments section of RFC 1122 lists some 25 major contributors, and another 25 who contributed some. In fact, there were probably 4 or 5 people who contributed significant nibbles of text that got incorporated, but it would have been really tough to draw the line. Fortunately, the WG felt comfortable with listing only the Editor on the document, so I did not have to make the judgment on who should be listed (clearly, not 25!) Authorship can of course be a minefield of personal anxiety. Some people care a great deal whether they are included, sometimes even though their contribution has been marginal. A futher problem arises in those cases (perhaps few, these days) when the starting point for an IETF spec was an earlier research effort. Should all those who contributed to the earlier research, but did not help write the subsequent IETF spec, claim authorship on the final RFC? It seems dubious to me, but I have received anguished messages on the topic. It seems that this could logically lead to a BGP4 RFC that carried the names of everyone who had contributed to BGP development over the years! We also note that some academic fields have a tradition of including everyone remotely involved. You not infrequently see articles in Physical Review Letters with 20 to 50 authors. OK, that's their thing, but that has not been the way of the Internet/IETF. We therefore proposed an author list limitation to the IESG and to the community. To help take the sting out, we invented a new official RFC section, the Contributors section. Fortunately, in fact, nearly everyone has accepted the general principle and cooperated in good spirit, and we are the RFC Editor are grateful. The (admittedly slightly arbitrary) limit of 5 has generally worked out. The limit gives WG chairs a stick that they can (and do ;-)) wield to control their author lists. But life is full of exceptions, and Jon Postel taught us to maintain general principles while being willing to Do The Right Thing in special cases. We try to maintain that tradition of principled flexiblity. There have been a (very) few exceptions to the rule-of-5 for author lists, but only after really good arguments were made. The topic of this discussion is the most recent example. Bob Braden for the RFC Editor From braden@ISI.EDU Thu Jun 10 11:50:44 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AInvJ07028; Thu, 10 Jun 2004 11:49:57 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA25513; Thu, 10 Jun 2004 11:49:56 -0700 (PDT) Date: Thu, 10 Jun 2004 11:49:56 -0700 (PDT) Message-Id: <200406101849.LAA25513@gra.isi.edu> To: rfc-interest@rfc-editor.org, paul.hoffman@vpnc.org Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 18:50:50 -0000 Paul Hoffman asks: *> *> Greetings again. According to the Internet Drafts tracker, *> draft-rfc-editor-rfc2223bis has been stuck for nine months waiting *> for comments back to the shepherding AD (Harald Alvestrand). Is that *> really true? We reall need this document finished and made an RFC. If *> it isn't true, someone should get the I-D tracker to reflect reality. *> Paul, It may be formally true, but it does not reflect reality. The reality is this: (1) the RFC Editor has generally taken a go-slow attitude on publishing 2223bis. We lived for many years with 2223 as it became more and more out of date. We have wanted to wait for a period of stability before publishing its successor. In the meantime, the I-D pointed to by the RFC Editor web page provides a living document with the latest information. We have thought this sufficient to bridge the gap for the time being. (2) events and people have put a great deal of pressure on the RFC Editor recently, and we have limited resources. Some staff members already put in significant unpaid effort because they believe in the effort. We simply have not had time to do the next update. We hope to do so before San Diego. Bob Braden for the RFC Editor From dmm@1-4-5.net Thu Jun 10 12:53:57 2004 Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AJr1J24462 for ; Thu, 10 Jun 2004 12:53:01 -0700 (PDT) Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i5AJr1ax023270; Thu, 10 Jun 2004 12:53:01 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) id i5AJqxe7023269; Thu, 10 Jun 2004 12:52:59 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 10 Jun 2004 12:52:59 -0700 From: David Meyer To: Thomas Narten Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Message-ID: <20040610195259.GA23155@1-4-5.net> References: <20040610180918.GA21898@1-4-5.net> <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406101833.i5AIXOr9009421@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go" -- John Lennon X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: dmm@1-4-5.net Cc: rfc-interest@rfc-editor.org, Paul Hoffman / VPNC X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 19:53:58 -0000 On Thu, Jun 10, 2004 at 02:33:24PM -0400, Thomas Narten wrote: >> David, >> >> This is not really a topic for this list, but I can't ignore this >> either. >> >> > Let me suggest that it can get worse. What happens when a >> > document goes into "Expert Review :: External Party", and >> > an expert registers comments (that get into the COMMENTS >> > field), then never responds to the author's response to >> > the comments? This is one way to effectively block >> > a document (this is very much like filibuster, only by >> > silence). >> >> If a document gets stuck like this, frustrated parties should contact >> the Shepherding AD. If that doesn't get a reasonable response, >> escalate, either by trying other ADs you think might listen, or going >> directly to Harald (as IETF Chair). But letting documents just sit is >> not acceptable. I don't think anyone would argue for that. Thomas, First, let me apologize for the off topic post (I didn't realize that it was off topic). That being said, I didn't say that this situation was acceptable. Nor did I say that any one is arguing that such a situation is desirable/acceptable. Rather, I did say is that it can (and does happen). That much can be stipulated (i.e., is fact). FTR, in the case(s) I know of, everything short of escalating to Harald was done (and more). There is also the issue of not wanting to use a heavyweight mechanism like appealing to the IETF chair to resolve these issues. This both because many of us would rather not put the person who made the comments in that position if possible (consider the possibility that there is a benign reason for the delay), and/or would like to avoid having to escalate anything to the IETF chair level (again, if possible). Dave From paul.hoffman@vpnc.org Thu Jun 10 13:02:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AK1jJ26784 for ; Thu, 10 Jun 2004 13:01:45 -0700 (PDT) Received: from [10.20.30.239] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5AK1dSO083296; Thu, 10 Jun 2004 13:01:39 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200406101849.LAA25513@gra.isi.edu> References: <200406101849.LAA25513@gra.isi.edu> Date: Thu, 10 Jun 2004 13:01:41 -0700 To: Bob Braden , rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 20:02:47 -0000 At 11:49 AM -0700 6/10/04, Bob Braden wrote: >It may be formally true, but it does not reflect reality. The reality >is this: > >(1) the RFC Editor has generally taken a go-slow attitude on >publishing 2223bis. We lived for many years with 2223 as it became >more and more out of date. We have wanted to wait for a period of >stability before publishing its successor. In the meantime, the I-D >pointed to by the RFC Editor web page provides a living document >with the latest information. We have thought this sufficient >to bridge the gap for the time being. A few things here: - This sets a really bad precedent. It is almost exactly akin to "create your protocol from the Internet Draft that we will keep renewing; we're not going to bother to get an RFC". - The draft expired many months ago, and is only being kept alive because of its status in the queue. Again, a bad precedent for the rest of the IETF. - The link from the RFC Editor's page seems to be broken. doesn't get me anything. >(2) events and people have put a great deal of pressure on the RFC >Editor recently, and we have limited resources. Some staff members >already put in significant unpaid effort because they believe in the >effort. We simply have not had time to do the next update. We hope >to do so before San Diego. This is very confusing. From the ID Tracker, it looks like there is only one small outstanding issue; it should take less than half an hour to fix. Are there issues not listed on the tracker? --Paul Hoffman, Director --VPN Consortium From braden@ISI.EDU Thu Jun 10 13:21:52 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AKLLJ01848; Thu, 10 Jun 2004 13:21:21 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA25580; Thu, 10 Jun 2004 13:21:21 -0700 (PDT) Date: Thu, 10 Jun 2004 13:21:21 -0700 (PDT) Message-Id: <200406102021.NAA25580@gra.isi.edu> To: braden@ISI.EDU, rfc-interest@rfc-editor.org, paul.hoffman@vpnc.org Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 20:21:58 -0000 *> *> - This sets a really bad precedent. It is almost exactly akin to *> "create your protocol from the Internet Draft that we will keep *> renewing; we're not going to bother to get an RFC". *> Sorry, I don't get your point. What is wrong with a living document as a bridge. *> - The draft expired many months ago, and is only being kept alive *> because of its status in the queue. Again, a bad precedent for the *> rest of the IETF. It happens. But in fact we should update it, and as I said we will do so before San Diego. *> *> - The link from the RFC Editor's page seems to be broken. *> *> doesn't get me anything. *> !? I just checked from both Explorer and Netscape, and neither had an trouble finding it. Could someone else verify an inability to reach this URL? *> >(2) events and people have put a great deal of pressure on the RFC *> >Editor recently, and we have limited resources. Some staff members *> >already put in significant unpaid effort because they believe in the *> >effort. We simply have not had time to do the next update. We hope *> >to do so before San Diego. *> *> This is very confusing. From the ID Tracker, it looks like there is *> only one small outstanding issue; it should take less than half an *> hour to fix. Are there issues not listed on the tracker? *> Paul, you obviously has no concept of the work needed to run the RFC Editor. Bob Braden *> --Paul Hoffman, Director *> --VPN Consortium *> From sob@harvard.edu Thu Jun 10 13:26:44 2004 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5AKQAJ02913 for ; Thu, 10 Jun 2004 13:26:10 -0700 (PDT) Received: by newdev.harvard.edu (Postfix, from userid 501) id 843AF25670B; Thu, 10 Jun 2004 16:26:02 -0400 (EDT) To: braden@ISI.EDU, paul.hoffman@vpnc.org, rfc-interest@rfc-editor.org Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? In-Reply-To: <200406102021.NAA25580@gra.isi.edu> Message-Id: <20040610202602.843AF25670B@newdev.harvard.edu> Date: Thu, 10 Jun 2004 16:26:02 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: sob@harvard.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 20:26:44 -0000 *> - The link from the RFC Editor's page seems to be broken. *> *> doesn't get me anything. works for me Safari on OSX Scott From paul.hoffman@vpnc.org Thu Jun 10 14:14:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5ALEBJ15512 for ; Thu, 10 Jun 2004 14:14:11 -0700 (PDT) Received: from [10.20.30.239] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ALE1Bg091856; Thu, 10 Jun 2004 14:14:01 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20040610202602.843AF25670B@newdev.harvard.edu> References: <20040610202602.843AF25670B@newdev.harvard.edu> Date: Thu, 10 Jun 2004 14:10:45 -0700 To: sob@harvard.edu (Scott Bradner), braden@ISI.EDU, rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 21:14:44 -0000 At 4:26 PM -0400 6/10/04, Scott Bradner wrote: > *> - The link from the RFC Editor's page seems to be broken. > *> > *> doesn't get me anything. > >works for me > >Safari on OSX Works for me now; possibly a short-term problem. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Jun 10 14:14:45 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5ALEBJ15511 for ; Thu, 10 Jun 2004 14:14:11 -0700 (PDT) Received: from [10.20.30.239] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5ALE1Bi091856; Thu, 10 Jun 2004 14:14:02 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200406102021.NAA25580@gra.isi.edu> References: <200406102021.NAA25580@gra.isi.edu> Date: Thu, 10 Jun 2004 14:13:07 -0700 To: Bob Braden , rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Status of draft-rfc-editor-rfc2223bis? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 21:14:45 -0000 At 1:21 PM -0700 6/10/04, Bob Braden wrote: > *> > *> - This sets a really bad precedent. It is almost exactly akin to > *> "create your protocol from the Internet Draft that we will keep > *> renewing; we're not going to bother to get an RFC". > *> > >Sorry, I don't get your point. What is wrong with a living document >as a bridge. In the IETF, this is usually considered a Bad Thing. If something is ready to become an RFC, it should become an RFC. Otherwise, people will assume that the "living document" is stable, and if it changes later, there will be ugly surprises. > *> - The draft expired many months ago, and is only being kept alive > *> because of its status in the queue. Again, a bad precedent for the > *> rest of the IETF. > >It happens. But in fact we should update it, and as I said we will do >so before San Diego. Great! --Paul Hoffman, Director --VPN Consortium From john+rfc@jck.com Fri Jun 11 13:21:47 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5BKLBJ09567 for ; Fri, 11 Jun 2004 13:21:12 -0700 (PDT) Received: from scan.jck.com ([209.187.148.215]) by bs.jck.com with esmtp (Exim 4.10) id 1BYsWV-000Dsx-00 for rfc-interest@rfc-editor.org; Fri, 11 Jun 2004 15:21:11 -0500 Date: Fri, 11 Jun 2004 16:21:11 -0400 From: John C Klensin To: rfc-interest@rfc-editor.org Message-ID: <9CAA548FCB84097B66705658@scan.jck.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: john+rfc@jck.com Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 20:21:47 -0000 --On Thu, 10 Jun 2004 14:13:07 -0700, Paul Hoffman / VPNC wrote: >> Sorry, I don't get your point. What is wrong with a living >> document as a bridge. > > In the IETF, this is usually considered a Bad Thing. If > something is ready to become an RFC, it should become an RFC. > Otherwise, people will assume that the "living document" is > stable, and if it changes later, there will be ugly surprises. Paul, I'm not wild about the current state of things either, nor am I wild about the example I'm about to cite, but I think it is important to recognize the resource and priority issues that Bob identifies. I note that 1id-guidelines.txt and the notorious and perhaps unlamented "id-nits" documents where both available online only, that the latter was often enforced as a set of binding rules by the IESG and the former was often (albeit sporadically and inconsistently) enforced by the secretariat. I don't remember a lot of protests about that situation (except from myself), evidence of serious harm caused by it, or people using it as a precedent. The RFC Editor at least aspires to keeping a good balance between consistency and flexibility. best, john From paul.hoffman@vpnc.org Fri Jun 11 14:19:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5BLJGJ22317 for ; Fri, 11 Jun 2004 14:19:16 -0700 (PDT) Received: from [10.20.30.239] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BLJ9E9080345; Fri, 11 Jun 2004 14:19:09 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <9CAA548FCB84097B66705658@scan.jck.com> References: <9CAA548FCB84097B66705658@scan.jck.com> Date: Fri, 11 Jun 2004 14:14:00 -0700 To: John C Klensin , rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 21:19:47 -0000 At 4:21 PM -0400 6/11/04, John C Klensin wrote: >I note that 1id-guidelines.txt and the notorious and perhaps >unlamented "id-nits" documents where both available online only, >that the latter was often enforced as a set of binding rules by >the IESG and the former was often (albeit sporadically and >inconsistently) enforced by the secretariat. I don't remember >a lot of protests about that situation (except from myself), >evidence of serious harm caused by it, or people using it as a >precedent. Your memory is probably faulty; I remember this coming up as a topic at least once a year at plenaries, and certainly often in the Apps area with the ADs. > The RFC Editor at least aspires to keeping a good >balance between consistency and flexibility. This is good. However, the document in question is updating an existing RFC that we working group chairs are supposed to enforce. Having a correct new RFC is much better than saying "you must follow this expired Internet Draft" to our document editors who we have been trying to convince to keep their documents up to date. --Paul Hoffman, Director --VPN Consortium From braden@ISI.EDU Fri Jun 11 15:55:48 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5BMtCJ14000; Fri, 11 Jun 2004 15:55:12 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id PAA25905; Fri, 11 Jun 2004 15:55:12 -0700 (PDT) Date: Fri, 11 Jun 2004 15:55:12 -0700 (PDT) Message-Id: <200406112255.PAA25905@gra.isi.edu> To: john+rfc@jck.com, rfc-interest@rfc-editor.org, paul.hoffman@vpnc.org Subject: Re: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 22:55:54 -0000 *> *> > The RFC Editor at least aspires to keeping a good *> >balance between consistency and flexibility. *> *> This is good. However, the document in question is updating an *> existing RFC that we working group chairs are supposed to enforce. Paul, The RFC Editor is of course grateful for the efforts of the WG chairs in preparing Internet Drafts that will become RFCs with minimum additional work. However, the rules that WG chairs should be using (pardon me, but "enforce" seems a bit overblown) are those set by the IESG in IDChecklist. We have endeavored to ensure that IDChecklist is as consistent with the final RFC rules, defined in RFC 2223bis, as possible, reasonable, and useful. I really think we are beating a dead horse here. Bob Braden *> Having a correct new RFC is much better than saying "you must follow *> this expired Internet Draft" to our document editors who we have been *> trying to convince to keep their documents up to date. *> *> --Paul Hoffman, Director *> --VPN Consortium *> _______________________________________________ *> rfc-interest mailing list *> rfc-interest@rfc-editor.org *> http://www.rfc-editor.org/mailman/listinfo/rfc-interest *> From braden@ISI.EDU Fri Jul 16 16:32:09 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6GNVnJ12689; Fri, 16 Jul 2004 16:31:49 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id QAA02753; Fri, 16 Jul 2004 16:31:48 -0700 (PDT) Date: Fri, 16 Jul 2004 16:31:48 -0700 (PDT) Message-Id: <200407162331.QAA02753@gra.isi.edu> To: rfc-interest@rfc-editor.org X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Cc: rfc-editor@rfc-editor.org Subject: [rfc-i] draft-rfc-editor-rfc2223bis-08.txt X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 23:32:11 -0000 We have just submitted a new Internet Draft that is an update to the replacement for RFC 2223, Instructions to RFC Authors. The major difference in the -08 version is that it contains the current rules for intellectual property boilerplate. For those who are interested in an advance look at it, see ftp://ftp.rfc-editor.org/in-notes/authors/draft-rfc-editor-rfc2223bis -08.txt for the .txt version, and ftp://ftp.rfc-editor.org/in-notes/authors/draft-rfc-editor-rfc2223bis -08.wdiff.html for an htmlwdiff file showing the differences between -07 and -08. RFC Editor From falk@ISI.EDU Wed Jul 28 21:13:02 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6T4ClJ28294; Wed, 28 Jul 2004 21:12:47 -0700 (PDT) Received: from [192.168.1.3] (dsl081-036-151.lax1.dsl.speakeasy.net [64.81.36.151]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6T4C2B07920; Wed, 28 Jul 2004 21:12:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Date: Wed, 28 Jul 2004 21:11:55 -0700 To: rfc-interest@rfc-editor.org X-Mailer: Apple Mail (2.618) X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: RFC Editor Subject: [rfc-i] bibliographic listing of RFCs X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 04:13:02 -0000 Hello All- We've put together a listing of bibliographic entries for RFCs in the format preferred by the RFC Editor. You can find it at ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt . Hope you find this helpful. Feedback is welcome. --aaron From john@jck.com Fri Jun 11 13:13:50 2004 Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5BKDMJ06689 for ; Fri, 11 Jun 2004 13:13:22 -0700 (PDT) Received: from scan.jck.com ([209.187.148.215]) by bs.jck.com with esmtp (Exim 4.10) id 1BYsOw-000DdH-00 for rfc-interest@rfc-editor.org; Fri, 11 Jun 2004 15:13:22 -0500 From: John C Klensin To: rfc-interest@rfc-editor.org Message-ID: <64901E0E17348BD7EBFFE032@scan.jck.com> In-Reply-To: <200406111900.i5BJ04J17741@boreas.isi.edu> References: <200406111900.i5BJ04J17741@boreas.isi.edu> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: john@jck.com X-Mailman-Approved-At: Thu, 29 Jul 2004 06:36:09 -0700 Subject: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 11 Jun 2004 20:13:50 -0000 X-Original-Date: Fri, 11 Jun 2004 16:13:21 -0400 X-List-Received-Date: Fri, 11 Jun 2004 20:13:50 -0000 --On Thu, 10 Jun 2004 14:13:07 -0700, Paul Hoffman / VPNC wrote: >> Sorry, I don't get your point. What is wrong with a living >> document as a bridge. > > In the IETF, this is usually considered a Bad Thing. If > something is ready to become an RFC, it should become an RFC. > Otherwise, people will assume that the "living document" is > stable, and if it changes later, there will be ugly surprises. Paul, I'm not wild about the current state of things either, nor am I wild about the example I'm about to cite, but I think it is important to recognize the resource and priority issues that Bob identifies. I note that 1id-guidelines.txt and the notorious and perhaps unlamented "id-nits" documents where both available online only, that the latter was often enforced as a set of binding rules by the IESG and the former was often (albeit sporadically and inconsistently) enforced by the secretariat. I don't remember a lot of protests about that situation (except from myself), evidence of serious harm caused by it, or people using it as a precedent. The RFC Editor at least aspires to keeping a good balance between consistency and flexibility. best, john From pk@TechFak.Uni-Bielefeld.DE Thu Jul 29 01:02:15 2004 Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6T81WJ18868 for ; Thu, 29 Jul 2004 01:01:32 -0700 (PDT) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i6T81UQI005279 for ; Thu, 29 Jul 2004 10:01:30 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i6T81Uh10859 for ; Thu, 29 Jul 2004 10:01:30 +0200 (MEST) Message-Id: <200407290801.i6T81Uh10859@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: rfc-interest@rfc-editor.org In-reply-to: Your message of "Wed, 28 Jul 2004 21:11:55 PDT." <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10854.1091088087.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 29 Jul 2004 10:01:29 +0200 From: Peter Koch X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: pk@techfak.uni-bielefeld.de Subject: Re: [rfc-i] bibliographic listing of RFCs X-Mailman-Approved-At: Thu, 29 Jul 2004 06:36:09 -0700 X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 08:02:16 -0000 Aaron Falk wrote: > ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt . > > Hope you find this helpful. Feedback is welcome. thanks, the pointers to the superseding docs are helpful. Maybe you could add another column "updated by"? On a related topic: When citing RFCs outside IETF documents one usually has to name a publisher or issuer/editor. During the years I've seen different approaches to this, naming either the IAB, the IETF/IESG or sometimes the author's (or authors') institution(s). "The RFC-Editor" would also come to mind, but I'm not too sure what's the right thing to do here (not even that there is one right way at all). -Peter From falk@ISI.EDU Thu Jul 29 06:43:00 2004 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6TDglJ17145 for ; Thu, 29 Jul 2004 06:42:47 -0700 (PDT) Received: from [192.168.1.3] (dsl081-036-151.lax1.dsl.speakeasy.net [64.81.36.151]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6TDgNB14007; Thu, 29 Jul 2004 06:42:23 -0700 (PDT) In-Reply-To: <64901E0E17348BD7EBFFE032@scan.jck.com> References: <200406111900.i5BJ04J17741@boreas.isi.edu> <64901E0E17348BD7EBFFE032@scan.jck.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B18D936-E165-11D8-9810-000A95DBDB84@isi.edu> Content-Transfer-Encoding: 7bit From: Aaron Falk Subject: Re: [rfc-i] Re: Status of draft-rfc-editor-rfc2223bis? Date: Thu, 29 Jul 2004 06:42:16 -0700 To: John C Klensin X-Mailer: Apple Mail (2.618) X-ISI-4-30-3-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: falk@isi.edu Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 13:43:00 -0000 [This message was wedged in the list server, sorry about the delay. --aaron] On Jun 11, 2004, at 1:13 PM, John C Klensin wrote: > > > --On Thu, 10 Jun 2004 14:13:07 -0700, Paul Hoffman / VPNC > wrote: > >>> Sorry, I don't get your point. What is wrong with a living >>> document as a bridge. >> >> In the IETF, this is usually considered a Bad Thing. If >> something is ready to become an RFC, it should become an RFC. >> Otherwise, people will assume that the "living document" is >> stable, and if it changes later, there will be ugly surprises. > > Paul, I'm not wild about the current state of things either, nor > am I wild about the example I'm about to cite, but I think it is > important to recognize the resource and priority issues that Bob > identifies. > > I note that 1id-guidelines.txt and the notorious and perhaps > unlamented "id-nits" documents where both available online only, > that the latter was often enforced as a set of binding rules by > the IESG and the former was often (albeit sporadically and > inconsistently) enforced by the secretariat. I don't remember > a lot of protests about that situation (except from myself), > evidence of serious harm caused by it, or people using it as a > precedent. The RFC Editor at least aspires to keeping a good > balance between consistency and flexibility. > > best, > john > > > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest From paul.hoffman@vpnc.org Thu Jul 29 08:33:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6TFWLJ14761; Thu, 29 Jul 2004 08:32:21 -0700 (PDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TFWG3A047185; Thu, 29 Jul 2004 08:32:17 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> References: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> Date: Thu, 29 Jul 2004 08:32:18 -0700 To: Aaron Falk , rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Subject: Re: [rfc-i] bibliographic listing of RFCs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: RFC Editor X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 15:33:02 -0000 At 9:11 PM -0700 7/28/04, Aaron Falk wrote: >We've put together a listing of bibliographic entries for RFCs in >the format preferred by the RFC Editor. Looks great. One editorial question: why do you prefer listing all authors instead of the first author plus "et. al." for lists greater than two? The latter seems to be more popular these days. --Paul Hoffman, Director --VPN Consortium From hgs@cs.columbia.edu Thu Jul 29 10:46:04 2004 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6THj2J23471; Thu, 29 Jul 2004 10:45:02 -0700 (PDT) Received: from panther.cs.columbia.edu (IDENT:4vHNj+FLZJlkrJjlz0hhwDw2vXMC+9cp@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i6THislD006318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 29 Jul 2004 13:44:55 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i6THisHr004065; Thu, 29 Jul 2004 13:44:54 -0400 Message-ID: <41093795.2060400@cs.columbia.edu> Date: Thu, 29 Jul 2004 13:44:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC Subject: Re: [rfc-i] bibliographic listing of RFCs References: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.6.1.106153, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.28.108995 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__MOZILLA_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, __USER_AGENT 0, X_ACCEPT_LANG 0, __MIME_VERSION 0, __TO_MALFORMED_2 0, __REFERENCES 0, __IN_REP_TO 0, __EVITE_CTYPE 0, __CT_TEXT_PLAIN 0, __CT 0, __CTE 0, EMAIL_ATTRIBUTION 0, QUOTED_EMAIL_TEXT 0, __MIME_TEXT_ONLY 0, REFERENCES 0.000, IN_REP_TO 0, USER_AGENT 0.000' X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: hgs@cs.columbia.edu Cc: rfc-interest@rfc-editor.org, Aaron Falk , RFC Editor X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 17:46:04 -0000 Why shouldn't authors be listed? It's not like they haven't contributed and the usual motivation (space constraints in paper publications) doesn't apply here. Paul Hoffman / VPNC wrote: > At 9:11 PM -0700 7/28/04, Aaron Falk wrote: > >> We've put together a listing of bibliographic entries for RFCs in the >> format preferred by the RFC Editor. > > > Looks great. One editorial question: why do you prefer listing all > authors instead of the first author plus "et. al." for lists greater > than two? The latter seems to be more popular these days. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > http://www.rfc-editor.org/mailman/listinfo/rfc-interest From paul.hoffman@vpnc.org Thu Jul 29 11:54:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6TIrWJ11949; Thu, 29 Jul 2004 11:53:32 -0700 (PDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6TIrI3J085390; Thu, 29 Jul 2004 11:53:19 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <41093795.2060400@cs.columbia.edu> References: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> <41093795.2060400@cs.columbia.edu> Date: Thu, 29 Jul 2004 11:53:22 -0700 To: Henning Schulzrinne From: Paul Hoffman / VPNC Subject: Re: [rfc-i] bibliographic listing of RFCs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: rfc-interest@rfc-editor.org, Aaron Falk , RFC Editor X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 18:54:34 -0000 At 1:44 PM -0400 7/29/04, Henning Schulzrinne wrote: >Why shouldn't authors be listed? I didn't say they shouldn't be listed: I asked why there was a preference for listing them all given that such a preference is not as popular these days in the publication field. I'm happy with everyone being listed, and I'm happy with a consistent subset being listed. And, I'm quite happy that the RFC Editor has given us an easy way of copy-and-pasting the references! --Paul Hoffman, Director --VPN Consortium From lars.eggert@netlab.nec.de Thu Jul 29 12:21:07 2004 Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i6TJJxJ20534; Thu, 29 Jul 2004 12:20:00 -0700 (PDT) Received: from [10.10.10.11] (p5084234B.dip0.t-ipconnect.de [80.132.35.75]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 163A91BAC4D; Thu, 29 Jul 2004 21:19:48 +0200 (CEST) Message-ID: <41094DD0.1090306@netlab.nec.de> Date: Thu, 29 Jul 2004 21:19:44 +0200 From: Lars Eggert Organization: NEC Network Laboratories User-Agent: Mozilla Thunderbird 0.7.1 (Macintosh/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / VPNC Subject: Re: [rfc-i] bibliographic listing of RFCs References: <6D55317E-E115-11D8-9810-000A95DBDB84@isi.edu> <41093795.2060400@cs.columbia.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010002020906030302040801" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: lars.eggert@netlab.nec.de Cc: RFC Editor , rfc-interest@rfc-editor.org, Aaron Falk X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2004 19:21:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010002020906030302040801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Paul, Paul Hoffman / VPNC wrote: > > I didn't say they shouldn't be listed: I asked why there was a > preference for listing them all given that such a preference is not as > popular these days in the publication field. FWIW, I see no evidence that listing all authors is currently unpopular, at least for the publications I regularly follow. Furthermore, giving all authors due credit through inclusion in a citation is the right think to do, IMO. Lars -- Lars Eggert NEC Network Laboratories --------------ms010002020906030302040801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJpzCC Ay4wggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAz WjCBhDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqG SIb3DQEJARYTbGFycy5lZ2dlcnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAOowMZjwQREXIdWxQacJDyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugU zjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsL uAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhf S6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1xisltw2eRT0txoUCqq0mjFEp8LgJ+s6p1 4M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8UOH5GsH+Vkjbz5yFO1SsCAwEAAaNL MEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYETbGFycy5lZ2dlcnRA Z214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAE9rOnUtJERYLNbDztLI sH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZL9kb8RZnzGBii8a/ XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5kIHRjNvXpNGYe C7S3K8YsMIIDLjCCApegAwIBAgIDDIVaMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDA2MTcwNzIyMDNaFw0wNTA2 MTcwNzIyMDNaMIGEMQ8wDQYDVQQEEwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMT C0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBnbXgubmV0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6jAxmPBBERch1bFBpwkPKpzPKQql8hWaJ3abzEG5Q7ne5aCcrcXx HbS7/s9W6BTOM02pqK+dTqoe2v+N0CfVSfJfMD/hF74Cqwo2LDyFmRWieQn4bg7RMXMw15ZR 2uNfUVpICwu4A8DrrrVw3hgPOs5gLc7fOAa1W8kCtrT6LD14PapaycfQBUsW2rsflkWHPnN4 54KutrKoSF9Lq2dNKMHNofxI5156Y9PF0tFsym0tLLuUQWjx/XGKyW3DZ5FPS3GhQKqrSaMU SnwuAn6zqnXgzhwbcIOQp3mQ2N1NZqiQCjiqal8X0jIDu6F5oAcDPxQ4fkawf5WSNvPnIU7V KwIDAQABo0swSTA5BgNVHREEMjAwgRlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlgRNsYXJz LmVnZ2VydEBnbXgubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAT2s6dS0k RFgs1sPO0siwfgCiUBaS80qiPsiSy3UzVfebJerFgAdr1uyg8nLXmoRXYHh+06Ykutkv2Rvx FmfMYGKLxr9dDnCpodkAlhzFDqWnpQNNpuFA3snW2sA4qCz48WUXeWbo06RfKCJAfk887mQg dGM29ek0Zh4LtLcrxiwwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyFWjAJBgUr DgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NDA3MjkxOTE5NDRaMCMGCSqGSIb3DQEJBDEWBBTfGCNffdTajJ79BKYoXXDGxcPO1TBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDIVaMHoGCyqGSIb3DQEJEAIL MWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjANBgkqhkiG9w0BAQEFAASCAQDNgLu0HFDVHVOVZLWoYlz4VnUoJh8vKL2GY4WFzVFEHDBh nXIXxrDRSc4+xN8eVRmjFUvRZFLhu2vakalpPUmXmYWmEuiM887nS4COgNZ5K1OW0tLWKf0C ectQLH2IdL/6OocE63uXPBzX2nTc1hJilIkbePxFaH5TJdkTq+ak755MHhfhJDvqhCgPoQYq 4836A/+pL/2LGiJev6OxovnIKm2n5dr6NrbItbgrA6M3n5HAwHbIEAQe/gCVQsvI1sO4EDKF LWqgg0L0UmA0JoecU9TvyzHyKwrN0YFD2J1VMp08L/n1xhMRwZ4lPfbZIBleHY1t69f1dxqp spazc0KdAAAAAAAA --------------ms010002020906030302040801-- From braden@ISI.EDU Mon Aug 9 10:02:30 2004 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i79H1nJ13788 for ; Mon, 9 Aug 2004 10:01:49 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA04586 for rfc-interest@rfc-editor.org; Mon, 9 Aug 2004 10:01:49 -0700 (PDT) Date: Mon, 9 Aug 2004 10:01:49 -0700 (PDT) Message-Id: <200408091701.KAA04586@gra.isi.edu> To: rfc-interest@rfc-editor.org X-Sun-Charset: US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu Subject: [rfc-i] Presentation on RFC Editor at IETF X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 17:02:30 -0000 The slides that were used in the RFC Editor report to the IETF Plenary last Wednesday are available at: ftp://ftp.rfc-editor.org/in-notes/IETFreports/aug04-report.ppt, .pdf The RFC Editor From paul.hoffman@vpnc.org Wed Sep 1 21:46:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i824jrJ29674 for ; Wed, 1 Sep 2004 21:45:53 -0700 (PDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i824jExe040306 for ; Wed, 1 Sep 2004 21:45:15 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 1 Sep 2004 21:45:18 -0700 To: rfc-interest@rfc-editor.org From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Subject: [rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 04:46:40 -0000 Greetings again. I have reformulated draft-rfc-editor-rfc2223bis in a couple of ways. I removed what I hope is all the material that a document author doesn't need to know, re-organized it to bring the required information together into two sections and the optional information into a different section, cleaned up a lot of the wording and examples, and made all the reference citations use the same format. Please let me know if you think this is a useful document. It is always sad to hear people say that they spent hours doing things for Internet Drafts that turn out to be irrelevant to getting published as an RFC, and I hope this alternate presentation will make it much clearer what they do and don't need to do. There are also a few open questions that would be good to clean up for the -01. Comments are, of course, welcome. --Paul Hoffman >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Instructions to Request for Comments (RFC) Authors > Author(s) : P. Hoffman > Filename : draft-hoffman-rfc-author-guide-00.txt > Pages : 0 > Date : 2004-9-1 > >This document explains what authors who are writing Internet Drafts >which are intended to become Request for Comments (RFC) documents need >to do, and also gives suggestions for those documents. It explains the >process of RFC publication and lists the requirements for Internet >Drafts that will eventually become RFCs. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-rfc-author-guide-00.txt From pekkas@netcore.fi Thu Sep 2 04:42:50 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i82BgKJ03454 for ; Thu, 2 Sep 2004 04:42:20 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i82Bg1j31162; Thu, 2 Sep 2004 14:42:02 +0300 Date: Thu, 2 Sep 2004 14:42:01 +0300 (EEST) From: Pekka Savola To: Paul Hoffman / VPNC Subject: Re: [rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: pekkas@netcore.fi Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 11:42:50 -0000 On Wed, 1 Sep 2004, Paul Hoffman / VPNC wrote: > Please let me know if you think this is a useful document. It is > always sad to hear people say that they spent hours doing things for > Internet Drafts that turn out to be irrelevant to getting published > as an RFC, I'm intrigued -- could you elaborate on what are these things which turn out to be irrelevant? As a general note, I'm not sure whether I saw the point of the rewrite. Probably a lot of useful information has been lost, while adding some amount of new text. But couldn't this have been done based on the earlier draft? ... Meta-question: -------------- An Internet Draft that is submitted to the RFC Editor enters the RFC Editor's publication queue; the queue is viewable at the RFC Editor Web site. ==> does RFC-editor do some kind of submission tracking? I've heard reports of these submissions sometimes getting lost without a reply or appearance in the publication queue. Maybe one should say a few words how soon one should expect the document to be seen in the queue (and if not, complain about it)? major comments: --------------- 1) I think the section 2.1 on submission from the IETF should refer to the I-D guidelines document (or some other relevant documents) which describe additional requirements placed on the documents if they have come through the IETF process. This would seem to be useful to make sure that the readers are not confused to think that just doing what this document suggests is enough (editorially) to get to the RFC. It might or might not be the case if you do an independent submission, but it certainly isn't if you go through the IETF (which is what the majority probably are doing). 2) IMHO, it would seem to be useful to give better guidance on the use of tools, i.e., to more strongly recommend and justify XML. It's just *SO* much easier to get decent-looking documents with xml2rfc than any of the alternatives, and i believe this format is also best to the RFC editor. The editors typically pick either Word or nroff (based on their background) and later on waste a lot of hours bashing their head against the wall to get out decent documents (or just push out not-so-great documents). 3) the document doesn't appear to use many words to discuss the order of the sections. Is this useful? A couple of editorial or minor comments: ---------------------------------------- To maintain the integrity of the RFC document series and to avoid wasting scarce publication resources, the RFC Editor may reject an independent submission because its content is uninteresting or irrelevant, or because its editorial quality is acceptable. ==> s/acceptable/unacceptable/ Once the RFC Editor has determined that an independent submission is acceptable, ==> s/Once/Once and if/ (?) RFCs published this way have often been not as useful as those in plain ASCII because many people do not know to retrieve the alternate versions, ==> s/those/those only/ (to drive the point home that even if you PS/PDF, you'll have to do the text version as well) -- this might possibly be underlined further. Most RFCs require a security considerations section that describes any issues that affect security on the Internet. ==> isn't this required on *all* RFCs? Lately, I've certainly never seen one which wouldn't have this section.. The distinction between normative and informative references is often important. The IETF standards process and the RFC Editor publication process need to know whether a reference to a work in progress is normative. A standards-track RFC cannot be published until all of the documents that it lists as normative references have been published. In practice, this often results in the simultaneous publication of a group of interrelated RFCs. ==> there should probably be a reference pointer here. 4.9 Author's address section Th author's address section, which is required for all RFCs, gives the name(s) and contact information for the author(s) who are listed in the first-page header. Contact information must include at least a postal address, a telephone number, and/or a long-lived email address. ==> this is not correct. postal and telephone address and such are not required.. and there are good reasons for that [I certainly don't want to be called, faxed or spammed by snailmail] IP addresses in generic examples should be from the private IP address spaces [BCP5]. ==> Rather, use the IP address reserved for examples, not private address. At least that's the IETF policy. A satisfactory abstract can often be constructed from a summary of some of the material within the Introduction section. An abstract is not a substitute for an introduction; the RFC should be self-contained as if there were no Abstract section. ==> shouldn't you say that the Introduction is the first numbered section? An abstract should be complete in itself; it should not contain citations unless they are completely defined within the abstract. ==> what are 'citations ... [that] are completely defined within the abstract'? just make it a hard rule without the exception ? When turning in an Internet Draft, do not fill the text with extra spaces to provide a straight right margin. Do not right justify the text. ==> s/margin. Do/margin, i.e., do/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From paul.hoffman@vpnc.org Thu Sep 2 08:32:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i82FVdJ03644 for ; Thu, 2 Sep 2004 08:31:39 -0700 (PDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82FVSqD097371; Thu, 2 Sep 2004 08:31:29 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 2 Sep 2004 08:29:04 -0700 To: Pekka Savola From: Paul Hoffman / VPNC Subject: Re: [rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: paul.hoffman@vpnc.org Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 15:32:43 -0000 Thanks for the extensive comments! At 2:42 PM +0300 9/2/04, Pekka Savola wrote: >I'm intrigued -- could you elaborate on what are these things which >turn out to be irrelevant? Well, there were many. For example, the history of RFCs is interesting but irrelevant to someone who is turning in their draft to become an RFC unless they have never read other RFCs; that is rare. Other things removed include the Postscript formatting rules (which apply to very few people and are probably best dealt with by the RFC Editor on a case-by-case basis), header and footer formats (which are added by the RFC Editor, not the person turning in the draft), and so on. >As a general note, I'm not sure whether I saw the point of the >rewrite. Probably a lot of useful information has been lost, while >adding some amount of new text. If I have lost any useful information from draft-rfc-editor-rfc2223bis, by all means let me know. > But couldn't this have been done >based on the earlier draft? It *was* based on draft-rfc-editor-rfc2223bis. That's why I credited those folks in the acknowledgements (and added Jon Postel), and moved the acknowledgements up towards the beginning of the document. >1) > >I think the section 2.1 on submission from the IETF should refer to >the I-D guidelines document (or some other relevant documents) which >describe additional requirements placed on the documents if they have >come through the IETF process. Sounds good. I pointed to that document a few paragraphs earlier, but it is good to say that there are some requirements on IETF-based submissions. >This would seem to be useful to make sure that the readers are not >confused to think that just doing what this document suggests is >enough (editorially) to get to the RFC. It might or might not be the >case if you do an independent submission, but it certainly isn't if >you go through the IETF (which is what the majority probably are >doing). Indeed. I'll add a note about that as well, since it has caused confusion in some working groups. >2) IMHO, it would seem to be useful to give better guidance on the use >of tools, i.e., to more strongly recommend and justify XML. It's just >*SO* much easier to get decent-looking documents with xml2rfc than any >of the alternatives, and i believe this format is also best to the RFC >editor. The editors typically pick either Word or nroff (based on >their background) and later on waste a lot of hours bashing their head >against the wall to get out decent documents (or just push out >not-so-great documents). As a recent user of xml2rfc, I think it still needs a bit of work before I strongly recommend it. Two people I have workd with have not been able to figure out the TCL shell part, and it took me a while to get it working for me. But I certainly agree that it is better than the alternatives for formatting. Some of use still prefer plain-old text, however. >3) the document doesn't appear to use many words to discuss the order >of the sections. Is this useful? It would be useful if we could agree on them. :-) >Most RFCs require a security considerations section that describes any >issues that affect security on the Internet. > >==> isn't this required on *all* RFCs? Lately, I've certainly never >seen one which wouldn't have this section.. Not all security sections describe the effects on the Internet. This document is a good example of that. >Th author's address section, which is required for all RFCs, gives the >name(s) and contact information for the author(s) who are listed in >the first-page header. Contact information must include at least a >postal address, a telephone number, and/or a long-lived email address. > >==> this is not correct. postal and telephone address and such are >not required.. and there are good reasons for that [I certainly >don't want to be called, faxed or spammed by snailmail] According to draft-rfc-editor-rfc2223bis, at least one is required. > IP addresses in generic >examples should be from the private IP address spaces [BCP5]. > >==> Rather, use the IP address reserved for examples, not private >address. At least that's the IETF policy. Where is that written down? I thought I remembered that document but couldn't find it. >A satisfactory abstract can often be constructed from a summary of >some of the material within the Introduction section. An abstract is >not a substitute for an introduction; the RFC should be self-contained >as if there were no Abstract section. > >==> shouldn't you say that the Introduction is the first numbered >section? Only if it is true. Some RFCs have different names for the first section. >An abstract should be complete in itself; it should not contain >citations unless they are completely defined within the abstract. > >==> what are 'citations ... [that] are completely defined within the >abstract'? just make it a hard rule without the exception ? I'm happy with that if other folks are. --Paul Hoffman, Director --VPN Consortium From fenner@research.att.com Thu Sep 2 09:38:48 2004 Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i82Gc1J19815 for ; Thu, 2 Sep 2004 09:38:01 -0700 (PDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 72B72A7BB3; Thu, 2 Sep 2004 12:37:55 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i82GbsO21316; Thu, 2 Sep 2004 09:37:54 -0700 (PDT) Message-Id: <200409021637.i82GbsO21316@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: paul.hoffman@vpnc.org Subject: Re: [rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt References: Date: Thu, 2 Sep 2004 09:37:50 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: fenner@research.att.com Cc: rfc-interest@rfc-editor.org, pekkas@netcore.fi X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 16:38:48 -0000 >As a recent user of xml2rfc, I think it still needs a bit of work [...] Not that this is necessarily any more straightforward, but I have an XSL transform that turns xml2rfc source into nroff, which with some macros builds the whole RFC in txt or PDF (the PDF has clickable cross-references, [sometimes]). It uses too many groff features for the RFC-Editor to be happy with the output (e.g., it builds the TOC using an auxilliary file), but I think it's reasonable for creating I-Ds for submission. Bill From pekkas@netcore.fi Thu Sep 2 23:32:48 2004 Received: from netcore.fi (netcore.fi [193.94.160.1]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i836WBJ17932 for ; Thu, 2 Sep 2004 23:32:11 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i836VnA21604; Fri, 3 Sep 2004 09:31:53 +0300 Date: Fri, 3 Sep 2004 09:31:49 +0300 (EEST) From: Pekka Savola To: Paul Hoffman / VPNC Subject: Re: [rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: pekkas@netcore.fi Cc: rfc-interest@rfc-editor.org X-BeenThere: rfc-interest@rfc-editor.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "A list for discussion of the RFC series and RFC Editor functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 06:32:49 -0000 On Thu, 2 Sep 2004, Paul Hoffman / VPNC wrote: > At 2:42 PM +0300 9/2/04, Pekka Savola wrote: > >I'm intrigued -- could you elaborate on what are these things which > >turn out to be irrelevant? > > Well, there were many. For example, the history of RFCs is > interesting but irrelevant to someone who is turning in their draft > to become an RFC unless they have never read other RFCs; that is > rare. Other things removed include the Postscript formatting rules > (which apply to very few people and are probably best dealt with by > the RFC Editor on a case-by-case basis), header and footer formats > (which are added by the RFC Editor, not the person turning in the > draft), and so on. OK, I agree that these are not so interesting. > >As a general note, I'm not sure whether I saw the point of the > >rewrite. Probably a lot of useful information has been lost, while > >adding some amount of new text. > > If I have lost any useful information from > draft-rfc-editor-rfc2223bis, by all means let me know. OK... I guess I could check this in detail, but based on a quick scan compared rfc-editor-rfc2223bis-08.txt, some which at least could be considered to be useful in rfc-editor-rfc2223bis-08.txt: - section 2.9, last paragraph - section 2.10, 2nd and 3rd paragraph - section 2.11, the paragraph about not being updated in the documents themselves, and reference to the RFC index - section 2.14 - section 3.1 (12) [it might also be useful to say explicitly that even if you don't have IANA considerations, it's good idea to say so explicitly] - section 4.6, esp. 1st paragraph - appendix C as an appendix [...] > >2) IMHO, it would seem to be useful to give better guidance on the use > >of tools, i.e., to more strongly recommend and justify XML. It's just > >*SO* much easier to get decent-looking documents with xml2rfc than any > >of the alternatives, and i believe this format is also best to the RFC > >editor. The editors typically pick either Word or nroff (based on > >their background) and later on waste a lot of hours bashing their head > >against the wall to get out decent documents (or just push out > >not-so-great documents). > > As a recent user of xml2rfc, I think it still needs a bit of work > before I strongly recommend it. Two people I have workd with have not > been able to figure out the TCL shell part, and it took me a while to > get it working for me. But I certainly agree that it is better than > the alternatives for formatting. The point I have tried to make multiple times is that you *don't* need to download the xml2rfc program, or an xml editor to do xml2rfc. For example, I've been extremely happy with a dozen or so drafts by just using my favourite editor to edit the .xml file manually, and use the web interface at xml.resource.org to produce the text version. I've never even tried to compile the program, or care to do that. (There are good reasons to use the web interface: for example, you don't need to have a local copy of the references, you can just do them automatically.) There are even a couple of copies of .xml templates which should allow one to "learn as you go", without having to learn it the hard way. One of these should probably end up in the EDU team web site, RFC-editor website, or at xml2rfc web site. > Some of use still prefer plain-old text, however. And that causes no end of trouble, e.g., when the ToC gets out of date (or must be done manually, or is at the end of the draft), the boilerplates are invalid, text goes beyond 72 chars/line, references aren't kept up-to-date automatically, etc.etc. -- both from the people who want to get the drafts to a good quality and must waste time on commenting, and the folks who need to fix all of these manually. > >3) the document doesn't appear to use many words to discuss the order > >of the sections. Is this useful? > > It would be useful if we could agree on them. :-) True enough ;-) -- but I think there's some rough consensus about this except from the location of appendices wrt references. The reason I say this is because sometimes folks put e.g., Acknowledgements or Security Considerations in appendices (after the References). rfc-editor-rfc2223bis-08.txt includes a pretty good order, though by default I'd change the order or references and appendices. > >Most RFCs require a security considerations section that describes any > >issues that affect security on the Internet. > > > >==> isn't this required on *all* RFCs? Lately, I've certainly never > >seen one which wouldn't have this section.. > > Not all security sections describe the effects on the Internet. This > document is a good example of that. Yes, but the security considerations *section* must still be present, even though the draft does not discuss security considerations, right? Current text could be read such that you could've omitted the section for this draft, and that would have been OK. > >Th author's address section, which is required for all RFCs, gives the > >name(s) and contact information for the author(s) who are listed in > >the first-page header. Contact information must include at least a > >postal address, a telephone number, and/or a long-lived email address. > > > >==> this is not correct. postal and tele