From julian.reschke at gmx.de Fri Jan 4 06:00:00 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Fri, 04 Jan 2008 15:00:00 +0100 Subject: [rfc-i] rfc errata HTML format Message-ID: <477E3BE0.3050707@gmx.de> Hi, here's a wish for 2008...: it would be great if the RFC errata pages () would assign a stable identifier to each erratum, and use that as an anchor in the HTML output. For instance, I'd like to be able to link to the first erratum for RFC4918 using something like (extra points for using URLs that are cool, meaning not exposing internal implementation issues as a PHP file extension, such as BR, Julian From nobody at xyzzy.claranet.de Mon Jan 7 15:35:04 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue, 8 Jan 2008 00:35:04 +0100 Subject: [rfc-i] rfc errata HTML format References: <477E3BE0.3050707@gmx.de> Message-ID: Julian Reschke wrote: > > (extra points for using URLs that are cool, meaning not exposing > internal implementation issues as a PHP file extension, such as > You could add http://purl.net/net/rfc/errata/* to the existing http://purl.net/net/rfc/* redirections. With a normal "interwiki map" (IIRC) that would be [[purlnet:rfc/errata/4918#e1 erratum]] to refer to this erratum in a Wiki. Frank P.S. for those who don't know it, to test the PURL redirection try or From hagens at ISI.EDU Tue Jan 15 18:18:53 2008 From: hagens at ISI.EDU (Alice Hagens) Date: Tue, 15 Jan 2008 18:18:53 -0800 Subject: [rfc-i] rfc errata HTML format In-Reply-To: <477E3BE0.3050707@gmx.de> References: <477E3BE0.3050707@gmx.de> Message-ID: <786A3B0B-7D2F-4542-8A6B-827F08BB374F@isi.edu> Julian & Frank, Thank you for the feedback on the errata system. We have received similar requests from IESG members. We are analyzing the idea and considering how it might integrate into the errata process. Since there are existing unique identifiers (internal) for each errata report, the most straight-forward way to this type of functionality would be to make them available. For example, the URL would of the form http://www.rfc-editor.org/errata_search.php? rfc=4918&eid=1234. In part, the design was intended to encourage a user to look at all of the errata reported for a given RFC, not one in particular. This is especially relevant to having a Verifier aware of all errata (for a particular RFC) that are awaiting verification. That said, we understand that a unique identifier for a report would make things easier during discussions of an errata report. Frank's PURL suggestion can be considered more fully once we have some experience with how this change integrates into our site. RFC Editor/ah On Jan 7, 2008, at 3:35 PM, Frank Ellermann wrote: > Julian Reschke wrote: > >> >> (extra points for using URLs that are cool, meaning not exposing >> internal implementation issues as a PHP file extension, such as >> > > You could add http://purl.net/net/rfc/errata/* to the existing > http://purl.net/net/rfc/* redirections. With a normal "interwiki > map" (IIRC) that would be [[purlnet:rfc/errata/4918#e1 erratum]] > to refer to this erratum in a Wiki. > > Frank > > P.S. for those who don't know it, to test the PURL redirection > try or > > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest > On Jan 4, 2008, at 6:00 AM, Julian Reschke wrote: > Hi, > > here's a wish for 2008...: it would be great if the RFC errata pages > () would > assign a > stable identifier to each erratum, and use that as an anchor in the > HTML > output. For instance, I'd like to be able to link to the first erratum > for RFC4918 using something like > > > > (extra points for using URLs that are cool, meaning not exposing > internal implementation issues as a PHP file extension, such as > > > > BR, Julian > _______________________________________________ > rfc-interest mailing list > rfc-interest at rfc-editor.org > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From nobody at xyzzy.claranet.de Tue Jan 15 22:11:50 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Wed, 16 Jan 2008 07:11:50 +0100 Subject: [rfc-i] rfc errata HTML format References: <477E3BE0.3050707@gmx.de> <786A3B0B-7D2F-4542-8A6B-827F08BB374F@isi.edu> Message-ID: Alice Hagens wrote: > Frank's PURL suggestion can be considered more fully once we have > some experience with how this change integrates into our site. If you end up with a PURL account please tell us. The failsafe for http://purl.net/net/rfc and .../rfc/ could be improved, IETF-TOOLS boils down to Julian, St?phane, and me at the moment. Frank -- http://purl.net/maint/display.pl.cgi?noedit=on&purl=/NET/rfc&id=nobody http://purl.net/maint/display.pl.cgi?noedit=on&purl=/NET/rfc/&id=nobody From lars.eggert at nokia.com Tue Jan 15 23:05:31 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Wed, 16 Jan 2008 08:05:31 +0100 Subject: [rfc-i] rfc errata HTML format In-Reply-To: <786A3B0B-7D2F-4542-8A6B-827F08BB374F@isi.edu> References: <477E3BE0.3050707@gmx.de> <786A3B0B-7D2F-4542-8A6B-827F08BB374F@isi.edu> Message-ID: <8EF69FEE-0FEA-4CCE-91F6-0F171E64AD9D@nokia.com> On 2008-1-16, at 3:18, ext Alice Hagens wrote: > For example, the URL > would of the form http://www.rfc-editor.org/errata_search.php? > rfc=4918&eid=1234 I'd like to second Julian's suggestion to use a URL format that doesn't expose the details of the underlying implementation. (Tell your admin to read up on apache URL rewriting.) In your example, the name of the script handling the search (errata_search.php) and the name of its parameters (rfc, eid) are exposed, so it'll be difficult to change the underlying implementation in the future without changing the URLs. Lars From bortzmeyer at nic.fr Wed Jan 16 00:27:02 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 16 Jan 2008 09:27:02 +0100 Subject: [rfc-i] rfc errata HTML format In-Reply-To: <8EF69FEE-0FEA-4CCE-91F6-0F171E64AD9D@nokia.com> References: <477E3BE0.3050707@gmx.de> <786A3B0B-7D2F-4542-8A6B-827F08BB374F@isi.edu> <8EF69FEE-0FEA-4CCE-91F6-0F171E64AD9D@nokia.com> Message-ID: <20080116082702.GA1063@nic.fr> On Wed, Jan 16, 2008 at 08:05:31AM +0100, Lars Eggert wrote a message of 19 lines which said: > I'd like to second Julian's suggestion to use a URL format that > doesn't expose the details of the underlying implementation. Yes, it should go without saying. Since it does not, the first reference to read is "Cool URIs don't change" http://www.w3.org/Provider/Style/URI The ".php" extension is specially unfortunate, for reasons explained in the above text. > (Tell your admin to read up on apache URL rewriting.) Rather than reading on a specific technology (after all, the RFC editor may not use Apache today or may stop using it tomorrow and, even with Apache, there are several ways to do so), people should read up on good persistent URI practices. From danny at tcb.net Mon Jan 21 14:09:29 2008 From: danny at tcb.net (Danny McPherson) Date: Mon, 21 Jan 2008 15:09:29 -0700 Subject: [rfc-i] comments on draft-rfc-editor-errata-process-00 In-Reply-To: <002a01c836b0$071611d0$df128182@Wylie> References: <002a01c836b0$071611d0$df128182@Wylie> Message-ID: <44EFF9FC-078D-4419-8C50-7CA342061C71@tcb.net> On Dec 4, 2007, at 12:58 PM, Turner, Sean P. wrote: > Three comments on the draft/process: > > 1. Should we add a link to the errata on the http://www.ietf.org/ > iesg/1rfc_index.txt page? This way if somebody does download the > index and do a search on it then it's pretty clear that there's > errata. > I think this is probably worthwhile, in particular for existing specifications. Same applies to your point 2 below, for that matter. > 2. Likewise should we add a link on the WG pages? > > 3. I know RFCs never change, but with errata they kind of do - so > should we add a link/note in to the boilerplate either at the > beginning or at the end of the RFC. > This is somewhat akin to what BRC suggested and W3C employs today, as outlined in the text in Appendix A. 1. Brian Carpenter has suggested an approach similar to that used by W3C: Add a URL to every published RFC that points to its errata (if any). For W3C examples, see: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ and http://www.w3.org/TR/2006/REC-xml-names-20060816 They include the text: "Please refer to the for this document, which may include some normative corrections." where is a hyperlink to the list of all errata or a page that says: "There are no errata to this document yet." Similarly, a URL could be added to all (future) RFCs pointing to where the relevant errata are posted. -danny From danny at tcb.net Mon Jan 21 14:30:01 2008 From: danny at tcb.net (Danny McPherson) Date: Mon, 21 Jan 2008 15:30:01 -0700 Subject: [rfc-i] RFC Errata - Slippery Slope Message-ID: <876767E8-C039-414E-8BE0-4761BEA660AB@tcb.net> Upon rereading this draft and discussing this some offline with Bob, Olaf and others, I figured I'd kick a message here for discussion. Section 1.1 of draft-rfc-editor-errata-process-00 shares this observation: [...] Another issue with errata is that some of the reported errors are not simply editorial, but rather correct technical contents of RFCs. A savvy implementer of the specification can often, but not always, figure out what was intended by the RFC as published, but technical errors should be announced somehow. Furthermore, posting technical errata for Standards Track documents should always involve the IESG, as a matter of correct process. Technical errata may require much review and discussion among the author(s), Area Directors, and other interested parties. We note that allowing technical errata is a slippery slope: there may be a temptation to use errata to "fix" protocol design errors, rather than publishing new RFCs that update the erroneous documents. In general, an erratum is intended to report an error in a document, rather than an error in the design of the protocol or other entity defined in the document, but this distinction may be too imprecise to avoid hard choices. For the IETF stream, these choices should be made by the IESG, not the RFC Editor. [...] The current draft process doesn't distinguish between technical and editorial errata. Are more specific guidelines needed here? Guidelines that are generic to all streams with respect to distinguishing between errors in documents and errors in protocol, e.g. what happens with errata that are rejected because they would change the protocol although they clearly and unambiguously demonstrate an error? Is there a need to keep such information around and tag it? I know Bob Braden has some information of the RFC Editor bits (he's clued me in here already), I'm sure he'll share those with the folks here as well. I'm wondering more about what folks here believe needs to happen on the process front. The second question is if there is a need to describe in more detail the stream dependent management of such normative changes. For the IETF stream it would probably mean 'back to the WG/sponsoring AD and work on a new RFC'. How about the independent, IAB, and IRTF stream? Also, are the current guidelines regarding notification to ietf-announce sufficient, or should each status change trigger some note every time an erratum is verified, rejected to altered? I'm quite interested in seeing more discussion on this. -danny From henrik at levkowetz.com Mon Jan 21 19:10:56 2008 From: henrik at levkowetz.com (Henrik Levkowetz) Date: Tue, 22 Jan 2008 04:10:56 +0100 Subject: [rfc-i] comments on draft-rfc-editor-errata-process-00 In-Reply-To: <44EFF9FC-078D-4419-8C50-7CA342061C71@tcb.net> References: <002a01c836b0$071611d0$df128182@Wylie> <44EFF9FC-078D-4419-8C50-7CA342061C71@tcb.net> Message-ID: <47955EC0.20702@levkowetz.com> On 2008-01-21 23:09 Danny McPherson said the following: > On Dec 4, 2007, at 12:58 PM, Turner, Sean P. wrote: ... >> 3. I know RFCs never change, but with errata they kind of do - so >> should we add a link/note in to the boilerplate either at the >> beginning or at the end of the RFC. >> > > This is somewhat akin to what BRC suggested and W3C employs today, > as outlined in the text in Appendix A. > > 1. Brian Carpenter has suggested an approach similar to that > used by > W3C: Add a URL to every published RFC that points to its errata > (if any). > > For W3C examples, see: > > http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ and > > http://www.w3.org/TR/2006/REC-xml-names-20060816 > > They include the text: > > "Please refer to the for this document, which may > include some normative corrections." > > where is a hyperlink to the list of all errata or a > page that says: > > "There are no errata to this document yet." > > Similarly, a URL could be added to all (future) RFCs pointing to > where the relevant errata are posted. An example of how this could look is the errata link which exists for all RFCs with errata in their htmlized form at http://tools.ietf.org/html/, e.g., http://tools.ietf.org/html/rfc4954 -- see the top right-hand corner of the added header, under the standard-level indication. Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 155 bytes Desc: OpenPGP digital signature Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080122/dcb0bcab/signature.bin From julian.reschke at gmx.de Tue Jan 29 02:11:44 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 29 Jan 2008 11:11:44 +0100 Subject: [rfc-i] references vs front matter Message-ID: <479EFBE0.8030506@gmx.de> Hi, here's a simple question: Let's say RFC YYYY obsoletes RFC XXXX, and says so on the front page. However, RFC XXXX isn't mentioned anywhere else throughout the text. Should it still contain an Informative Reference to RFC XXXX? I would think so, but the RFC-Editor seems to disagree. BR, Julian From duerst at it.aoyama.ac.jp Tue Jan 29 03:11:51 2008 From: duerst at it.aoyama.ac.jp (Martin Duerst) Date: Tue, 29 Jan 2008 20:11:51 +0900 Subject: [rfc-i] references vs front matter In-Reply-To: <479EFBE0.8030506@gmx.de> References: <479EFBE0.8030506@gmx.de> Message-ID: <6.0.0.20.2.20080129201009.0af73620@localhost> I don't see a need for that. Informative References are for cases where there is indeed relevant information in the old RFC. If that RFC is obsoleted by the new one, the usual case is that the old RFC doesn't contain any relevant information anymore, the information is either taken over into the new RFC, or is, as it says, obsolete. There may be exceptions to this, e.g. if the old RFC contains some design discussions that haven't been taken over into the new RFC, but are still of interest, or if the Acks section in the old RFC is still relevant, and so on. Regards, Martin. At 19:11 08/01/29, Julian Reschke wrote: >Hi, > >here's a simple question: > >Let's say RFC YYYY obsoletes RFC XXXX, and says so on the front page. > >However, RFC XXXX isn't mentioned anywhere else throughout the text. > >Should it still contain an Informative Reference to RFC XXXX? I would >think so, but the RFC-Editor seems to disagree. > >BR, Julian >_______________________________________________ >rfc-interest mailing list >rfc-interest at rfc-editor.org >http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp From nobody at xyzzy.claranet.de Tue Jan 29 03:48:58 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue, 29 Jan 2008 12:48:58 +0100 Subject: [rfc-i] references vs front matter References: <479EFBE0.8030506@gmx.de> Message-ID: Julian Reschke wrote: > Let's say RFC YYYY obsoletes RFC XXXX, and says so on the front page. For xml2rfc that's an obsoletes="XXXX" in the rfc-tag. > However, RFC XXXX isn't mentioned anywhere else throughout the text. > Should it still contain an Informative Reference to RFC XXXX? For xml2rfc that could give you an unused reference error. If that's the case it's arguably an xml2rfc oddity. With an obvious workaround, mention "this documents obsoletes RFC XXXX" somewhere. Normally RFC YYYY has no business to obsolete RFC XXXX without saying so - this could be a typo / "joke" / "attack". Frank From paul.hoffman at vpnc.org Tue Jan 29 07:59:46 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 29 Jan 2008 07:59:46 -0800 Subject: [rfc-i] references vs front matter In-Reply-To: References: <479EFBE0.8030506@gmx.de> Message-ID: >For xml2rfc that could give you an unused reference error. Just for the record: that is irrelevant to the question of what the RFC should look like. xml2rfc is a tool that is used to produce RFCs. If the tool isn't producing them correctly, then we should fix the tool. --Paul Hoffman, Director --VPN Consortium From Donald.Eastlake at motorola.com Tue Jan 29 08:01:58 2008 From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008) Date: Tue, 29 Jan 2008 11:01:58 -0500 Subject: [rfc-i] references vs front matter In-Reply-To: <6.0.0.20.2.20080129201009.0af73620@localhost> References: <479EFBE0.8030506@gmx.de> <6.0.0.20.2.20080129201009.0af73620@localhost> Message-ID: <3870C46029D1F945B1472F170D2D979003762D42@de01exm64.ds.mot.com> I think the RFC being deleted should be mentioned and there should be at least a few words in the new RFC on why/how it is being deleted or what is different about the new RFC in comparison with the old. Thanks, Donald -----Original Message----- From: rfc-interest-bounces at rfc-editor.org [mailto:rfc-interest-bounces at rfc-editor.org] On Behalf Of Martin Duerst Sent: Tuesday, January 29, 2008 6:12 AM To: Julian Reschke; rfc-interest at rfc-editor.org Subject: Re: [rfc-i] references vs front matter I don't see a need for that. Informative References are for cases where there is indeed relevant information in the old RFC. If that RFC is obsoleted by the new one, the usual case is that the old RFC doesn't contain any relevant information anymore, the information is either taken over into the new RFC, or is, as it says, obsolete. There may be exceptions to this, e.g. if the old RFC contains some design discussions that haven't been taken over into the new RFC, but are still of interest, or if the Acks section in the old RFC is still relevant, and so on. Regards, Martin. At 19:11 08/01/29, Julian Reschke wrote: >Hi, > >here's a simple question: > >Let's say RFC YYYY obsoletes RFC XXXX, and says so on the front page. > >However, RFC XXXX isn't mentioned anywhere else throughout the text. > >Should it still contain an Informative Reference to RFC XXXX? I would >think so, but the RFC-Editor seems to disagree. > >BR, Julian >_______________________________________________ >rfc-interest mailing list >rfc-interest at rfc-editor.org >http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp _______________________________________________ rfc-interest mailing list rfc-interest at rfc-editor.org http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest From julian.reschke at gmx.de Tue Jan 29 08:15:06 2008 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 29 Jan 2008 17:15:06 +0100 Subject: [rfc-i] references vs front matter In-Reply-To: References: <479EFBE0.8030506@gmx.de> Message-ID: <479F510A.70801@gmx.de> Paul Hoffman wrote: >> For xml2rfc that could give you an unused reference error. > > Just for the record: that is irrelevant to the question of what the > RFC should look like. xml2rfc is a tool that is used to produce RFCs. > If the tool isn't producing them correctly, then we should fix the > tool. rfc2629.xslt already reminds the author that if an RFC is being obsoleted or updated, it should be mentioned somewhere in the text as well (yes, that's my preference). BR, Julian From nobody at xyzzy.claranet.de Tue Jan 29 08:47:07 2008 From: nobody at xyzzy.claranet.de (Frank Ellermann) Date: Tue, 29 Jan 2008 17:47:07 +0100 Subject: [rfc-i] references vs front matter References: <479EFBE0.8030506@gmx.de> Message-ID: Paul Hoffman wrote: >> For xml2rfc that could give you an unused reference error. > Just for the record: that is irrelevant to the question of > what the RFC should look like. It was only a plauible example how "unnecessary" references can be found. Not finding them is sub-optimal, last year I stumbled over an RFC with a reference to MD5. Because MD5 interests me I read it, and MD5 was nowhere used. After some digging it was clear that the RFC was based on a draft, -09, and MD5 was removed after draft -05 (or similar). I've submitted that as an "erratum" (editorial: unused reference). Frank From braden at ISI.EDU Tue Jan 29 09:42:21 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 29 Jan 2008 09:42:21 -0800 (PST) Subject: [rfc-i] references vs front matter Message-ID: <200801291742.JAA09974@gra.isi.edu> *> *> I think the RFC being deleted should be mentioned and there should be at *> least a few words in the new RFC on why/how it is being deleted or what *> is different about the new RFC in comparison with the old. *> *> Thanks, *> Donald Donald's suggestion would seem to solve the problem of violating the (very useful!) rule that citations and references must match. In addition, his proposed "few words" seem socially useful, if not strictly necessary. OTOH, the RFC Editor could consider the OBSOLETES: field as a citation, I suppose. Bob Braden From paul.hoffman at vpnc.org Tue Jan 29 10:08:52 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 29 Jan 2008 10:08:52 -0800 Subject: [rfc-i] references vs front matter In-Reply-To: <200801291742.JAA09974@gra.isi.edu> References: <200801291742.JAA09974@gra.isi.edu> Message-ID: At 9:42 AM -0800 1/29/08, Bob Braden wrote: >OTOH, the RFC Editor could consider the OBSOLETES: field as a citation, >I suppose. How would that work? According to the current RFC Document Style document: * Citations must be enclosed square brackets ("[CITE1]"). Are you saying that you would start putting square brackets in the OBSOLETES field? --Paul Hoffman, Director --VPN Consortium From paul.hoffman at vpnc.org Tue Jan 29 08:53:56 2008 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Tue, 29 Jan 2008 08:53:56 -0800 Subject: [rfc-i] references vs front matter In-Reply-To: <479F510A.70801@gmx.de> References: <479EFBE0.8030506@gmx.de> <479F510A.70801@gmx.de> Message-ID: At 5:15 PM +0100 1/29/08, Julian Reschke wrote: >Paul Hoffman wrote: > >> For xml2rfc that could give you an unused reference error. >> > > Just for the record: that is irrelevant to the question of what the >> RFC should look like. xml2rfc is a tool that is used to produce RFCs. >> If the tool isn't producing them correctly, then we should fix the >> tool. > >rfc2629.xslt already reminds the author that if an RFC is being >obsoleted or updated, it should be mentioned somewhere in the text as >well (yes, that's my preference). Just for the record: that is irrelevant to the question of what the RFC should look like. rfc2629.xslt is a tool that is used to produce RFCs. If the tool isn't producing them correctly, then we should fix the tool. :-), kind of. --Paul Hoffman, Director --VPN Consortium From braden at ISI.EDU Tue Jan 29 10:45:49 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 29 Jan 2008 10:45:49 -0800 (PST) Subject: [rfc-i] references vs front matter Message-ID: <200801291845.KAA10016@gra.isi.edu> *> How would that work? According to the current RFC Document Style document: *> * Citations must be enclosed square brackets ("[CITE1]"). *> Are you saying that you would start putting square brackets in the *> OBSOLETES field? *> Anyway, I have been overruled on this one ]-) The RFC Editor staff thinks that Donald Eastlake had the (only) right idea. Bob Braden From braden at ISI.EDU Tue Jan 29 10:44:04 2008 From: braden at ISI.EDU (Bob Braden) Date: Tue, 29 Jan 2008 10:44:04 -0800 (PST) Subject: [rfc-i] references vs front matter Message-ID: <200801291844.KAA10011@gra.isi.edu> *> *> At 9:42 AM -0800 1/29/08, Bob Braden wrote: *> >OTOH, the RFC Editor could consider the OBSOLETES: field as a citation, *> >I suppose. *> *> How would that work? According to the current RFC Document Style document: *> * Citations must be enclosed square brackets ("[CITE1]"). *> Are you saying that you would start putting square brackets in the *> OBSOLETES field? *> *> --Paul Hoffman, Director *> --VPN Consortium *> Paul, "... consider as a citation..." Bob Braden From housley at vigilsec.com Tue Jan 29 12:02:59 2008 From: housley at vigilsec.com (Russ Housley) Date: Tue, 29 Jan 2008 15:02:59 -0500 Subject: [rfc-i] references vs front matter In-Reply-To: <479EFBE0.8030506@gmx.de> References: <479EFBE0.8030506@gmx.de> Message-ID: <200801292043.m0TKh1uM017470@boreas.isi.edu> If the IESG approves the document, we insist on a section that describes the differences between the two RFCs. That provides the linkage that you are seeking. Russ At 05:11 AM 1/29/2008, Julian Reschke wrote: >Hi, > >here's a simple question: > >Let's say RFC YYYY obsoletes RFC XXXX, and says so on the front page. > >However, RFC XXXX isn't mentioned anywhere else throughout the text. > >Should it still contain an Informative Reference to RFC XXXX? I would >think so, but the RFC-Editor seems to disagree. > >BR, Julian >_______________________________________________ >rfc-interest mailing list >rfc-interest at rfc-editor.org >http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest