One document matched: draft-iab-streams-headers-boilerplates-01.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:headers-boilerplates.xml"?>
<!-- automatically generated by xml2rfc v1.33 on 2008-10-06T08:45:07Z -->
<!--
# $Id: headers-boilerplates.xml 21 2008-10-06 08:32:53Z olaf $
# See thread:
# Subject: Re: [IAOC] RFC Editing silly states
# Date: 23May 2007 8:33:16 PM GMT+02:00
-->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!-- xml2rfc-processed-entity rfc2629 -->
]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="full3978"
updates="4844, 2223"
category="info"
docName="draft-iab-streams-headers-boilerplates-01"
>
<front>
<title abbrev="RFC Streams, Headers, Boilerplates">
On RFC Streams, Headers, and Boilerplates
</title>
<author role="editor" initials="L." surname="Daigle" fullname="Leslie Daigle">
<organization> </organization>
<address>
<email>daigle@isoc.org, leslie@thinkingcat.com</email>
</address>
</author>
<author role="editor" initials="O.M." surname="Kolkman" fullname="Olaf M. Kolkman">
<organization></organization>
<address>
<email>olaf@nlnetlabs.nl</email>
</address>
</author>
<author surname="Internet Architecture Board">
<organization abbrev="(IAB)">Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email>
</address>
</author>
<date year="2008"/>
<abstract>
<t>
RFC documents contain a number of fixed elements such as the
title page header, standard boilerplates and copyright/IPR
statements. This document describes them and introduces some
updates to reflect current usage and requirements of RFC
publication. In particular, this updated structure is
intended to communicate clearly the source of RFC creation and
review.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Previously RFCs (e.g. <xref target="RFC4844" />) contained a
number of elements that were there for historical, practical,
and legal reasons. They also contained boilerplate material to
clearly indicate the status of the document and possibly
contained "Notes" to indicate how the document interacts with
IETF standard track documents.
</t>
<t>
As the RFC Series has evolved over the years, there has been
increasing concern over appropriate labelling of the
publications to make clear the status of each RFC and the
status of the work it describes. Chiefly, there is a
requirement that RFCs published as part of the IETF's review
process not be easily confused with RFCs that may have had a
very different review and approval process. Various
adjustments have been made over the years, including evolving
text of "Notes" included in the published RFC.
</t>
<t>
With the definition of the different RFC streams <xref
target="RFC4844"/> it is appropriate to formalize the
definition of the various pieces of standard RFC boilerplate
and introduce some adjustments to ensure better clarity of
expression of document status, aligned with the review and
approval processes defined for each stream.
</t>
<t>
This memo identifies and describes the common elements of RFC
boilerplate structure, and provides a comprehensive approach
to updating and using those elements to communicate, with
clarity, RFC document and content status. Most of the
historical structure information is collected from <xref
target="RFC2223"/>.
</t>
<t>
The changes introduced by this memo should be implemented as
soon as practically possible after the document has been
approved for publication.
</t>
<!-- The Introduction section -->
</section>
<section anchor="standards" title="RFC Streams and Internet Standards">
<t>
Users of RFCs should be aware that while all Internet
standards-related documents are published as RFCs, not all
RFCs are Internet standards-related documents.
</t>
<t>
The IETF is responsible for maintaining the Internet Standards
Process, which includes the requirements for developing,
reviewing and approving Standards Track and BCP RFCs. These,
and any other standards-related documents (Informational or
Experimental) are reviewed by appropriate IETF bodies and
published as part of the IETF Stream.
</t>
<t>
Documents published in streams other than the IETF Stream are
not reviewed by the IETF for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. They have also not been subject to IESG approval,
including an IETF-wide last call. Therefore, the IETF
disclaims, for any of the non-IETF Stream documents, any
knowledge of the fitness of those RFCs for any purpose.
</t>
<t>
Refer to <xref target="RFC2026"/>, <xref
target="I-D.housley-iesg-rfc3932bis"/>, and <xref target="RFC4844"/> and their
successors for current details of IETF process and RFC
streams.
</t>
</section>
<section title="RFC Structural Elements">
<section title="The title page header">
<t>
An RFC title page header can be described as follows:
<figure>
<artwork>
------------------------------------------------------------------------
<document source> <author name>
Request for Comments: <RFC number> [<author affiliation>]
[<subseries ID> <subseries number>] [more author info as appropriate]
[<RFC relation>:<RFC number[s]>]
Category: <category>
<month year>
------------------------------------------------------------------------
</artwork>
</figure>
For example, a sample earlier RFC header is as follows:
<figure>
<artwork>
------------------------------------------------------------------------
Network Working Group T. Dierks
Request for Comments: 4346 Independent
Obsoletes: 2246 E. Rescorla
Category: Standards Track RTFM, Inc.
April 2006
------------------------------------------------------------------------
</artwork>
</figure>
</t>
<t>
The right column contains author name and affiliation
information as well as RFC publication date. Conventions
and restrictions for these elements are described in RFC
style norms and some individual stream definitions.
</t>
<t>
This section is primarily concerned with the information in
the left column:
</t>
<t>
<list style="hanging">
<t hangText="<document source>">
This describes the area where the work originates.
Historically, all RFCs were labeled Network Working
Group. "Network Working Group" refers to the original
version of today's IETF when people from the original
set of ARPANET sites and whomever else was interested --
the meetings were open -- got together to discuss,
design and document proposed protocols<xref
target='RFC0003'/>. Here, we obsolete the term "Network
Working Group" in order to indicate the originating
stream.
</t>
<t>
The <document source> is the name of the RFC
stream, as defined in <xref target="RFC4844"/> and its
successors. At the time of this publication, the
streams, and therefore the possible entries are:
<list style='symbols'>
<t>Internet Engineering Task Force</t>
<t>Internet Architecture Board</t>
<t>Internet Research Task Force</t>
<t>Independent</t>
</list>
</t>
<t hangText="Request for Comments: <RFC number>">
This indicates the RFC number, assigned by the RFC
Editor upon publication of the document. This element
is unchanged.
</t>
<t hangText="<subseries ID> <subseries number>">
Some document categories are also labeled as a subseries
of RFCs. These elements appear as appropriate for such
categories, indicating the subseries and the documents
number within that series. Currently, there are
subseries for BCPs, STDs and FYIs. These subseries
numbers may appear in several RFCs. For example, when a
new RFC updates an old one, the same subseries number is
used. Also, several RFCs may be assigned the same
subseries number: a single STD, for example, may be
composed of several RFCs, each of which will bear the
same STD number. This element is unchanged.
</t>
<t hangText="[<RFC relation>:<RFC number[s]>]">
Some relations between RFCs in the series are explicitly
noted in the RFC header. For example, a new RFC may
update one or more earlier RFCs. Currently two
relationships are defined "Updates" and
"Obsoletes". Other types of relations may be defined
elsewhere.
</t>
<t hangText="Category: <category>">
This indicates the RFC document category of the
publication. These are defined in <xref
target="RFC2026"/>. Currently, this is always one of:
Standards Track, Best Current Practice, Experimental,
Informational, or Historic. This element is unchanged.
</t>
</list>
</t>
<!-- Title Page Header section -->
</section>
<section anchor="Status" title="The Status of this Memo">
<t>
The "Status of This Memo" describes the category of the RFC,
including the distribution statement. This text is included
irrespective of the source stream of the RFC.
</t>
<t>
From now on, the "Status of This Memo" will start with a
single line describing the status. It will also include a
statement describing the stream-specific review of the
material (which is stream-dependent). This is an important
component of status, insofar as it clarifies the breadth and
depth of review, and gives the reader an understanding of
how to consider its content.
</t>
<t>
The first paragraph of the Status of this Memo section
contains a single line, clearly standing out. It depends on
the category of the document.
<list>
<t hangText="For 'Standards Track' documents:" >
This memo is an Internet Standards Track document.
</t>
<t hangText="For 'Best Current Practices' documents:" >
This memo documents an Internet Best Current Practice
</t>
<t hangText="For other categories" >
This memo is not an Internet Standards Track
specifiation, <it is published for other
purposes>.
</t>
<t> For Informational, Experimental and other future
categories of RFC editor will maintain an appropriate text
for <it is published for other purposes>. For
example, with an Informational document this could read
"It is published for informational purposes".
</t>
</list>
</t>
<t hangText="Request for Comments: <RFC number>">
This indicates the RFC number, assigned by the RFC Editor
upon publication of the document. This element is
unchanged.
</t>
<t>
The second paragraph contains category-specific text
as follows:
<list style='hanging'>
<t hangText="Standards Track:">
"This document specifies an Internet standards track
protocol for the Internet community. Please see the
"Updates to the RFC" section of this document for
information on where to find the status of this protocol
and the availability of errata for this memo."
</t>
<t hangText="Best Current Practice:">
"This document specifies an Internet Best Current
Practices for the Internet Community. Please see the
"Updates to the RFC" section of this document for
information on where to find the status of this
protocol and the availability of errata for this memo."
</t>
<t hangText="Experimental:">
"This memo defines an Experimental Protocol for the
Internet community. This memo does not specify an
Internet standard of any kind. Discussion and
suggestions for improvement are requested."
</t>
<t hangText="Informational:">
"This memo provides information for the Internet
community. This memo does not specify an Internet
standard of any kind. "
</t>
</list>
</t>
<t>
The third paragraph of the "Status of This Memo" will now
include a paragraph describing the type of review and
exposure the document has received. This is defined on a
per-stream basis. From now on, these paragraphs will be
defined as part of RFC stream definition.
</t>
<t>
The following texts may be updated if the stream definitions
are updated, but initial paragraphs for the existing streams are:
<list style='hanging'>
<t hangText="IETF Stream:">
"This document is a product of the Internet Engineering
Task Force (IETF). "
</t>
<t> If there has been an IETF consensus call per IETF
process, an additional sentence should be added: "This
document represents a consensus of the IETF community.
It has received public review and has been approved for
publication by the IESG."
</t>
<t hangText="IAB Stream:">
"This document is a product of the Internet Architecture
Board (IAB), and represents information that the IAB has
deemed valuable to provide for permanent record. This
document has been approved for publication by the IAB
and is therefore not a candidate for any level of
Internet Standard; see section <xref
target="standards"/> of RFCXXXX."
</t>
<t hangText="IRTF Stream:">
"This document is a product of the Internet Research
Task Force (IRTF). The IRTF publishes the results of
Internet-related research and development activities.
These results might not be suitable for deployment.
This document has been approved for publication by the
IRSG. It is not a product of the IETF and is therefore
not a candidate for any level of Internet Standard; see
section <xref target="standards"/> of RFCXXXX."
</t>
<t>
In addition a sentence indicating the consensus base
within the IRTF may be added: "This RFC represents the
consensus of the <insert_name> Research Group of
the Internet Research Task Force (IRTF)." or
alternatively "This RFC represents the individual
opinion(s) of one or more members of the
<insert_name> Research Group of the Internet
Research Task Force (IRTF)".
</t>
<t hangText="Independent Stream:">
"This document is a contribution to the RFC Series,
independently of any other RFC stream. The RFC Editor
has chosen to publish this document at its discretion
and makes no statement about its value for
implementation or deployment. It is therefore not a
candidate for any level of Internet Standard; see
section <xref target="standards"/> of RFCXXXX."
</t>
</list>
</t>
<!-- Status of This Memo section -->
</section>
<section title="Additional Notes">
<t>
Exceptionally, a review and publication process may
prescribe additional notes that will appear as labelled
notes after the "Status of This Memo".
</t>
<t>
While this has been a common feature of recent RFCs, it is
the goal of this exercise to make the overall RFC structure
adequately clear to remove the need for such notes, or at
least make their usage truly exceptional.
</t>
<!-- Additional Notes section -->
</section>
<section title="Other structural information in RFCs">
<t> RFCs contain other structural informational elements. The
RFC Editor is responsible for the positioning and layout of
these structural element. Note also that new elements may be
introduced or obsoleted using a process consistent with
<xref target="RFC4844" />. These additions may or may not require
documentation in an RFC.
</t>
<t>
Currently the following structural information is available
in RFCs.
</t>
<t>
<list style="hanging">
<t hangText="Copyright Notice">
A copyright notice with a reference to BCP78 and an
Intellectual Property statement referring to BCP78 and BCP79. The
content of these statements are defined by those BCPs.
</t>
<t hangText="ISSN">
The International Standard Serial Number<xref
target="ISO3297"/>: ISSN 2070-1721. The ISSN uniquely
identifies the RFC series as title regardless of
language or country in which published. The ISSN itself
has no significance other than the unique identification
of a serial publication.
<!-- I stole that piece of text from
http://www.loc.gov/issn/issnbro.html -->
</t>
<t hangText="Updates to the RFC">
A reference identifying where more information
about the document can be found. This includes
information wether the RFC has been updated, obsoleted,
or clarified, a listing of possible errata, and
information on how to submit errata as described in
<xref target="I-D.rfc-editor-errata-process"/>.
</t>
</list>
</t>
<!--Other structural information-->
</section>
<!-- Structural Elements section -->
</section>
<section title="Security considerations" >
<t>
This document tries to clarify the descriptions of the status
of an RFC. Misunderstanding the status of a memo could cause
interoperability problems, hence security and stability
problems.
</t>
<!-- Security Considerations section -->
</section>
<section title="IANA considerations" >
<t>
None.
</t>
<!-- IANA consideration -->
</section>
<section title="RFC Editor Considerations" >
<t>
The RFC Editor is responsibile for maintaining the consistency
of the RFC series. To that end the RFC Editor maintains a
style manual [insert reference]. In this memo we mention a few
explicit structural elements that the RFC editor needs to maintain.
The conventions for the content and use of all current and
future elements are to be documented in the style manual.
</t>
<t>
</t>
<t>
[The rest of this section contains specific instructions towards
editing this document and can be removed before publication]
</t>
<t>
The documents has two sections, including this one that need
to be removed before publication as an RFC. This one and <xref target="details" />.
</t>
<t>
This memo introduces a number of modifications that will have
to be implemented in various tools, such as the xml2rfc tool,
the nit tracker and the rfc-erratum portal.
</t>
<t>
The number "XXXX" is to be replaced with RFC number of this
memo.
</t>
<!-- RFC consideration -->
</section>
</middle>
<back>
<!-- <references title='Normative References'> </references>-->
<references title="Normative References">
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.2026"?>
<reference anchor='RFC2026'>
<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1996' month='October' />
<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>
<seriesInfo name='BCP' value='9' />
<seriesInfo name='RFC' value='2026' />
<format type='TXT' octets='86731' target='ftp://ftp.isi.edu/in-notes/rfc2026.txt' />
</reference>
<?rfc linefile="541:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.I-D.draft-housley-iesg-rfc3932bis-01.xml"?>
<reference anchor='I-D.housley-iesg-rfc3932bis'>
<front>
<title>IESG Procedures for Handling of Independent and IRTF Stream Submissions</title>
<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
<organization />
</author>
<author initials='R' surname='Housley' fullname='Russ Housley'>
<organization />
</author>
<date month='August' day='21' year='2008' />
<abstract><t>This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-housley-iesg-rfc3932bis-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-housley-iesg-rfc3932bis-01.txt' />
</reference>
<?rfc linefile="542:headers-boilerplates.xml"?>
</references>
<references title="Informative References">
<reference anchor="ISO3297">
<front>
<title>
Information and documentation - International standard serial number (ISSN)
</title>
<author>
<organization abbrev="ISO/TC46">
Technical Committee ISO/TC 46, Information and
documentation, Subcommittee SC 9, Identification and
description.
</organization>
</author>
<date month='09' day="09" year="2007"/>
</front>
</reference>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.0003"?>
<reference anchor='RFC0003'>
<front>
<title>Documentation conventions</title>
<author initials='S.' surname='Crocker' fullname='Steve Crocker'>
<organization>University California Los Angeles (UCLA)</organization></author>
<date year='1969' day='9' month='April' />
<abstract>
<t>The Network Working Group seems to consist of Steve Carr of Utah, Jeff Rulifson and Bill Duvall at SRI, and Steve Crocker and Gerard Deloche at UCLA. Membership is not closed.</t>
<t>The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experiments with the network.</t>
<t>Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series.</t></abstract></front>
<seriesInfo name='RFC' value='3' />
<format type='TXT' octets='2323' target='ftp://ftp.isi.edu/in-notes/rfc3.txt' />
</reference>
<?rfc linefile="564:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.2223"?>
<reference anchor='RFC2223'>
<front>
<title>Instructions to RFC Authors</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street></postal>
<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>Postel@ISI.EDU</email></address></author>
<author initials='J.K.' surname='Reynolds' fullname='Joyce K. Reynolds'>
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<street>Marina del Rey</street>
<street>CA 90292</street></postal>
<phone>+1 310-822-1511</phone>
<facsimile>+1 310-823-6714</facsimile>
<email>jkrey@isi.edu</email></address></author>
<date year='1997' month='October' />
<area>General</area>
<keyword>RFC authors</keyword></front>
<seriesInfo name='RFC' value='2223' />
<format type='TXT' octets='37948' target='ftp://ftp.isi.edu/in-notes/rfc2223.txt' />
<format type='HTML' octets='52847' target='http://xml.resource.org/public/rfc/html/rfc2223.html' />
<format type='XML' octets='37425' target='http://xml.resource.org/public/rfc/xml/rfc2223.xml' />
</reference>
<?rfc linefile="565:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.2629"?>
<reference anchor='RFC2629'>
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country></postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri></address></author>
<date year='1999' month='June' />
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t></abstract></front>
<seriesInfo name='RFC' value='2629' />
<format type='TXT' octets='48677' target='ftp://ftp.isi.edu/in-notes/rfc2629.txt' />
<format type='HTML' octets='71741' target='http://xml.resource.org/public/rfc/html/rfc2629.html' />
<format type='XML' octets='53481' target='http://xml.resource.org/public/rfc/xml/rfc2629.xml' />
</reference>
<?rfc linefile="566:headers-boilerplates.xml"?>
<!-- <?rfc?><?rfc linefile="1:bibxml/reference.RFC.3967"?>
<reference anchor='RFC3967'>
<front>
<title>Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level</title>
<author initials='R.' surname='Bush' fullname='R. Bush'>
<organization /></author>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<date year='2004' month='December' />
<abstract>
<t>IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='97' />
<seriesInfo name='RFC' value='3967' />
<format type='TXT' octets='12251' target='ftp://ftp.isi.edu/in-notes/rfc3967.txt' />
</reference>
<?rfc linefile="567:headers-boilerplates.xml"?> -->
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.3978"?>
<reference anchor='RFC3978'>
<front>
<title>IETF Rights in Contributions</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='78' />
<seriesInfo name='RFC' value='3978' />
<format type='TXT' octets='43574' target='ftp://ftp.isi.edu/in-notes/rfc3978.txt' />
</reference>
<?rfc linefile="568:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.4844"?>
<reference anchor='RFC4844'>
<front>
<title>The RFC Series and RFC Editor</title>
<author initials='L.' surname='Daigle' fullname='L. Daigle'>
<organization /></author>
<author>
<organization>Internet Architecture Board</organization></author>
<date year='2007' month='July' />
<abstract>
<t>This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4844' />
<format type='TXT' octets='38752' target='ftp://ftp.isi.edu/in-notes/rfc4844.txt' />
</reference>
<?rfc linefile="569:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.I-D.draft-rfc-editor-errata-process-02.xml"?>
<reference anchor='I-D.rfc-editor-errata-process'>
<front>
<title>RFC Editor Proposal for Handling RFC Errata</title>
<author initials='S' surname='Ginoza' fullname='Sandy Ginoza'>
<organization />
</author>
<author initials='A' surname='Hagens' fullname='Alice Hagens'>
<organization />
</author>
<author initials='R' surname='Braden' fullname='Robert Braden'>
<organization />
</author>
<date month='May' day='21' year='2008' />
<abstract><t>This document describes a web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the book-keeping for handling errata.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-rfc-editor-errata-process-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-rfc-editor-errata-process-02.txt' />
</reference>
<?rfc linefile="570:headers-boilerplates.xml"?>
</references>
<section title="Acknowledgements">
<t>
Thanks to Bob Braden, Brian Carpenter, Steve Crocker and John
Klensin who provided background information and inspiration.
</t>
<t>Various people have made suggestions that improved the
document. Among them are: Loa Andersson, Lars Eggert, Alfred Hines, Russ
Housley, and David Oran.
</t>
<t>
This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.
</t>
<!-- Acknowledgements section -->
</section>
<section anchor="details" title="Document Editing Details">
<t>
[To Be Removed before publication]
</t>
<section title="version 00->01">
<t>
Fixed the header so it appropriatly shows that the document
updates RFC 4844, 2223. And added a link to 3932-bis that
should appear in tandem with this publication.
</t>
<t>
Introduced the "Other structural information in RFCs"
section and moved the ISSN number from the front matter to
this section. The "Other structural information in RFCs"
intends to give very rough guidance providing the RFC editor
with sufficient freedom to move pieces around and edit them to
please the eye and mind.
</t>
<t>
Modified the last sentence 3rd paragraph of the Status of
this memo section for the IRTF Stream in accordance to a
suggestion by Aaron Falk; Indicating that review happend by
the IRSG and not indicating that review did not happen by
the IESG.
</t>
<t> Introduced the square brackets around the <author
affiliation> in the header. To highlight this is an
optional elelment.
</t>
<t>
The definition of the "Clarifies" relation has been taken
out. There are arguments that introducing the relation
needs a bit more thought and is better done by a seperate
document.
</t>
<t>
Provided the RFC Editor with responsibility to maintain
several text pieces.
</t>
<t>
In <xref target="Status"/> some modifications were applied
to the text.
</t>
<t>
The <discription> contains the full name of the
stream.
</t>
<t>
RFC2223 and 4844 moved to the informative reference
section. Although I am not sure if those are not
normative. Guidance!!!
</t>
<section title="open issues">
<t>
Does the RFC Editor wants to supply text with respect to
the level of review in <xref target="Status"/> for the
Independent Stream?
</t>
</section>
</section>
<!-- Document Editing Details section -->
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:45:39 |