One document matched: draft-iab-streams-headers-boilerplates-08.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:headers-boilerplates.xml"?>
<!-- automatically generated by xml2rfc v1.34pre3 on 2009-04-23T06:35:17Z -->
<!--
# $Id: headers-boilerplates.xml 83 2009-04-23 06:35:05Z 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="trust200902"
updates="4844, 2223"
category="info"
docName="draft-iab-streams-headers-boilerplates-08"
>
<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="2009"/>
<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 Standards-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 generally reviewed by the IETF for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. They have also not been subject to approval by the
Internet Engineering Steering Group (IESG), 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 the IETF process and RFC
streams.
</t>
</section>
<section title="RFC Structural Elements">
<section title="The title page header">
<t>
This section describes the elements that are commonly found
in RFCs published today. For the sake of clarity, this
document specifies the elements precisely as a specification.
However, this is not intended to specify a single, static
format. Details of formatting are decided by the RFC Editor.
Substantive changes to the header and boilerplate structure
and content may be undertaken in the future, and are subject
to general oversight and review by the IAB.
</t>
<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 the RFC publication month. 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 <xref target="RFC2026"/>, STDs <xref
target="RFC1311"/>, and FYIs <xref target="RFC1150"/>.
These subseries numbers may appear in several RFCs. For
example, when a new RFC obsoletes or 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"
<xref target="RFC2223"/>. Variants like "Obsoleted by"
are also used (e.g in <xref target="RFC5143"/>). Other
types of relationships may be defined by the RFC Editor
and may appear in future RFCs.
</t>
<t hangText="Category: <category>">
This indicates the initial 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>
The "Status of This Memo" will start with a single sentence
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>
<section title="Paragraph 1">
<t>
The first paragraph of the Status of this Memo section
contains a single sentence, clearly standing out. It depends on
the category of the document.
<list style='hanging'>
<t hangText="For 'Standards Track' documents:" >
"This 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 document is not an Internet Standards Track
specification; <it is published for other
purposes>."
</t>
</list>
For Informational, Experimental, Historic and future
categories of RFCs, the RFC editor will maintain an
appropriate text for <it is published for other
purposes>. Initial values are:
</t>
<list style='hanging'>
<t hangText="Informational: "> "it is published for informational purposes."
</t>
<t hangText="Historic: "> "it is published for the historical record."
</t>
<t hangText="Experimental: "> "it is published for examination,
experimental implementation, and evaluation."
</t>
</list>
</section>
<section title="Paragraph 2">
<t>
The second 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, subject to general review and oversight by
the RFC Editor and IAB. There is a specific structure
defined here to ensure there is clarity about review
processes and document types. These paragraphs will need to
be defined and maintained as part of RFC stream definitions.
Initial text, for current streams, is provided below.
</t>
<t>The paragraph may include some text that is specific to the
initial document category, as follows:
when a document is Experimental or Historic the
second paragraph opens with:
</t>
<list style='hanging'>
<t hangText="Experimental:">
"This document defines an Experimental Protocol for the
Internet community."
</t>
<t hangText="Historic:">
"This document defines a Historic Document for the Internet
community."
</t>
</list>
<t>
The text that follows is stream dependent -- these are initial values and may be updated by stream definition document updates.
</t>
<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: "It
represents the consensus of the IETF community. It has
received public review and has been approved for
publication by the Internet Engineering Steering Group
(IESG)." If there has not been such a consensus call then this
simply reads: "It has been approved for
publication by the Internet Engineering Steering Group
(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."
</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."
</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 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.
</t>
</list>
<t>
For non-IETF stream documents a reference to <xref
target="standards"/> of this RFC is added with the following
sentence: "Documents approved for publication by the [stream
approver -- currently, one of: "IAB", "IRSG", or "RFC
Editor"] are not a candidate for any level of Internet
Standard; see <xref target="standards"/> of RFC XXXX."
</t>
<t>
For IETF stream documents a similar reference is added:
"Further information on [BCPs or Internet Standards] is
available in <xref target="standards"/> of RFC XXXX." for BCP
and Standard Track documents; "Not all documents approved by
the IESG are candidate for any level of Internet Standards;
see <xref target="standards"/> of RFC XXXX." for all other categories.
</t>
</section>
<section title="Paragraph 3">
<t>
The boilerplate ends with a reference to where further
relevant information can be found. This information may
include, subject to the RFC Editor's discretion, information
whether the RFC has been updated or obsoleted, the RFC's
origin, a listing of possible errata, information about how
to provide feedback and suggestion, and information on how
to submit errata as described in <xref
target="I-D.rfc-editor-errata-process"/>. The exact wording
and URL is subject to change (at the RFC Editor's
discretion), but current text is:
</t>
<t>
"Information about the current status of this document, any errata, and how to provide feedback on it
may be obtained at http://www.rfc-editor.org/<static-path>/rfc<rfc-no>.html"
</t>
</section>
<section title="Noteworthy">
<t>
Note that the texts in paragraph 1 and 2 of the boilerplate
indicate the initial status of a document. During their
lifetime documents can change status to e.g. Historic. This
cannot be reflected in the document itself and will need be
reflected in the information refered to in <xref
target="Structure"/>.
</t>
</section>
<!-- 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 document 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 anchor="Structure" 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
or is being considered for inclusion in RFCs:
</t>
<list style='hanging'>
<t hangText="Copyright Notice">
A copyright notice with a reference to BCP78 <xref
target="BCP78"/> and an Intellectual Property statement
referring to BCP78 and BCP79 <xref target="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 it is 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>
</list>
<!--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 responsible for maintaining the consistency
of the RFC series. To that end the RFC Editor maintains a
style manual <xref target="RFC-style"/>. 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>
Adding a reference to the stream in the header of RFCs is only
one method for clarifying from which stream an RFC
originated. The RFC editor is encouraged to add such
indication in e.g. indices and interfaces.
</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>
<t>
References <xref target="RFC-style"/>, <xref target="BCP78"/>
and <xref target="BCP79"/> have been constructed. Please bring
these in line with RFC Editorial conventions.
</t>
<t> In section <xref target="Structure"/>:
For the final publication, it should be warranted that the
ISSN is *not* split by a line break, for clarity.
</t>
<t>
The URL in <xref target="Examples"/> should be replaced with whatever the RFC Editor decides upon.
</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="613:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.I-D.draft-housley-iesg-rfc3932bis-06.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='November' day='19' 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-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-housley-iesg-rfc3932bis-06.txt' />
</reference>
<?rfc linefile="614: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="635:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.1311"?>
<reference anchor='RFC1311'>
<front>
<title abbrev='RFC on STD RFCs'>Introduction to the STD Notes</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country></postal>
<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>Postel@ISI.EDU</email></address></author>
<date year='1992' month='March' /></front>
<seriesInfo name='RFC' value='1311' />
<format type='TXT' octets='11308' target='ftp://ftp.isi.edu/in-notes/rfc1311.txt' />
</reference>
<?rfc linefile="636:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.1150"?>
<reference anchor='RFC1150'>
<front>
<title abbrev='F.Y.I. on F.Y.I.'>FYI on FYI: Introduction to the FYI Notes</title>
<author initials='G.' surname='Malkin' fullname='Gary Scott Malkin'>
<organization>Proteon, Inc.</organization>
<address>
<postal>
<street>2 Technology Drive</street>
<city>Westborough</city>
<region>MA</region>
<code>01581-5008</code>
<country>US</country></postal>
<phone>+1 508 898 2800</phone>
<email>gmalkin@proteon.com</email></address></author>
<author initials='J.' surname='Reynolds' fullname='Joyce K. Reynolds'>
<organization>University of Southern California (USC), Information Sciences Institute (ISI)</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone>
<email>jkrey@isi.edu</email></address></author>
<date year='1990' day='1' month='March' /></front>
<seriesInfo name='RFC' value='1150' />
<format type='TXT' octets='7867' target='ftp://ftp.isi.edu/in-notes/rfc1150.txt' />
</reference>
<?rfc linefile="637: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="638: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="639: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="640:headers-boilerplates.xml"?> -->
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.3979"?>
<reference anchor='RFC3979'>
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. 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='79' />
<seriesInfo name='RFC' value='3979' />
<format type='TXT' octets='41366' target='ftp://ftp.isi.edu/in-notes/rfc3979.txt' />
</reference>
<?rfc linefile="641: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="642:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.4749"?>
<reference anchor='RFC4749'>
<front>
<title>RTP Payload Format for the G.729.1 Audio Codec</title>
<author initials='A.' surname='Sollaud' fullname='A. Sollaud'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4749' />
<format type='TXT' octets='28838' target='ftp://ftp.isi.edu/in-notes/rfc4749.txt' />
</reference>
<?rfc linefile="643:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.5143"?>
<reference anchor='RFC5143'>
<front>
<title>Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation</title>
<author initials='A.' surname='Malis' fullname='A. Malis'>
<organization /></author>
<author initials='J.' surname='Brayley' fullname='J. Brayley'>
<organization /></author>
<author initials='J.' surname='Shirron' fullname='J. Shirron'>
<organization /></author>
<author initials='L.' surname='Martini' fullname='L. Martini'>
<organization /></author>
<author initials='S.' surname='Vogelsang' fullname='S. Vogelsang'>
<organization /></author>
<date year='2008' month='February' />
<abstract>
<t>This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. This memo defines a Historic Document for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='5143' />
<format type='TXT' octets='52534' target='ftp://ftp.isi.edu/in-notes/rfc5143.txt' />
</reference>
<?rfc linefile="644:headers-boilerplates.xml"?>
<?rfc?><?rfc linefile="1:bibxml/reference.RFC.5378"?>
<reference anchor='RFC5378'>
<front>
<title>Rights Contributors Provide to the IETF Trust</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<author initials='J.' surname='Contreras' fullname='J. Contreras'>
<organization /></author>
<date year='2008' month='November' />
<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 obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, 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='5378' />
<format type='TXT' octets='37980' target='ftp://ftp.isi.edu/in-notes/rfc5378.txt' />
</reference>
<?rfc linefile="645: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="646:headers-boilerplates.xml"?>
<reference anchor="BCP78" >
<front>
<title>Rights Contributors Provide to the IETF Trust</title>
<author role="editor" initials="S." surname="Bradner">
<organization />
</author>
<author role="editor" initials="J." surname="Contreras">
<organization />
</author>
<date month='November' year="2008"/>
</front>
<seriesInfo name='BCP' value='78' />
<annotation>At the moment of publication:<xref target="RFC5378"/></annotation>
</reference>
<reference anchor="BCP79" >
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author role="editor" initials="S." surname="Bradner">
<organization />
</author>
<author role="editor" initials="T." surname="Narten">
<organization/>
</author>
<date month='April' year="2007"/>
</front>
<seriesInfo name='BCP' value='79' />
<annotation>At the moment of publication:<xref target="RFC3979"/>and<xref target="RFC4749"/></annotation>
</reference>
<reference anchor="RFC-style" target='http://www.rfc-editor.org/styleguide.html' >
<front>
<title>RFC Style Guide</title>
<author initials="" surname="">
<organization>RFC Editor</organization>
</author>
<date month='' year=""/>
</front>
</reference>
</references>
<section title="Some Example 'Status of this Memo' boilerplates" anchor="Examples">
<t>[Editor note: The URLs used in this example are examples.]
</t>
<section title="IETF Standards Track">
<t>The boilerplate for a Standards Track document that (by
definition) has been subject to an IETF consensus call.</t>
<figure>
<artwork>
------------------------------------------------------------------------
Status of this Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents a consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group. Further information on
the Internet Standards Track is available in Section 2 of RFC
XXXX."
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/status/rfc0000.html
------------------------------------------------------------------------
</artwork>
</figure>
</section>
<section title="IETF Experimental, with Consensus Call">
<t>The boilerplate for an Experimental document that has been
subject to an IETF consensus call.</t>
<figure>
<artwork>
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it
has been published for Experimental purposes.
This document defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are
requested. This document is a product of the Internet Engineering
Task Force (IETF). It represents a consensus of the IETF
community. It has received public review and has been approved
for publication by the Internet Engineering Steering Group
(IESG). Not all documents approved by the IESG are candidate for
any level of Internet Standards see Section 2 of RFC XXXX.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/status/rfc0000.html
------------------------------------------------------------------------
</artwork>
</figure>
</section>
<section title="IETF Experimental, No Consensus Call">
<t>The boilerplate for an Experimental document that not has been
subject to an IETF consensus call.</t>
<figure>
<artwork>
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it
has been published for Experimental purposes.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It has been approved for publication by the
Internet Engineering Steering Group. Not all documents approved
by the IESG are candidate for any level of Internet Standards see
Section 2 of RFC XXXX.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/status/rfc0000.html
------------------------------------------------------------------------
</artwork>
</figure>
</section>
<section title="IAB Informational">
<t>The boilerplate for an Informational IAB document.</t>
<figure>
<artwork>
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it
has been published for Informational purposes.
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. Documents approved for
publication by the IAB are not a candidate for any level of
Internet Standard; see Section 2 of RFC XXXX."
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/status/rfc0000.html
------------------------------------------------------------------------
</artwork>
</figure>
</section>
<section title="IRTF Experimental">
<t>The boilerplate for an Experimental document that has been
produced by the IRTF and for which there was no RG
consensus. This variation is the most verbose boilerplate in
the current set.</t>
<figure>
<artwork>
------------------------------------------------------------------------
Status of this Memo
This document is not an Internet Standards Track specification; it
has been published for Experimental purposes.
This document defines an Experimental Protocol for the Internet
community. 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 RFC represents the individual
opinion(s) of one or more members of the BLAFOO Research Group of
the Internet Research Task Force (IRTF). Documents approved for
publication by the IRTF are not a candidate for any level of
Internet Standard; see Section 2 of RFC XXXX."
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/status/rfc0000.html
------------------------------------------------------------------------
</artwork>
</figure>
</section>
</section>
<section title="IAB members at time of approval">
<t>
The IAB members at the time this memo was approved
were (in alphabetical order):
Loa Andersson,
Gonzalo Camarillo,
Stuart Cheshire,
Russ Housley,
Olaf Kolkman,
Gregory Lebovitz,
Barry Leiba,
Kurtis Lindqvist,
Andrew Malis,
Danny McPherson,
David Oran,
Dave Thaler, and
Lixia Zhang.
In addition, the IAB included two ex-officio members: Dow Street, who
was serving as the IAB Executive Director, and Aaron Falk, who was
serving as the IRTF Chair.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Bob Braden, Brian Carpenter, Steve Crocker, Sandy
Ginoza, and John Klensin who provided background information
and inspiration.
</t>
<t>Various people have made suggestions that improved the
document. Among them are: Lars Eggert, Alfred Hoenes, and Joe Touch.
</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>
<t>
$Id: headers-boilerplates.xml 83 2009-04-23 06:35:05Z olaf $
</t>
<section title="version 00->01">
<t>
Fixed the header so it appropriately 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 happened 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 element.
</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 separate
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 <description> 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>
<section title="version 01->02">
<t>
Fixed some editorial nits and missing references.
</t>
<t>
Clarified that the status and category are initial.
</t>
<t>
Added boilerplate text for documents that are initially published as Historic.
</t>
<t>
Added members of IAB, and removed those members from acknowledgements
</t>
<t>
Added References to BCP78 and BCP79. The exact formatting of
those references may need to be done by the RFC editor.
</t>
<t>
Added text to recognize occurrences of variations of "Obsolete" and "Update"
</t>
</section>
<section title="version 02->03">
<t>
Stray language in the "IAB members at time of approval"
section removed.
</t>
</section>
<section title="version 03->04">
<t>
Addressed the minor nit from Brian Carpenter.
</t>
<t>
Reference to style guide stet to styleguide.html
</t>
</section>
<section title="version 04->05">
<t>
References updated to reflect BCP78 being updated
</t>
<t>
Submitted under new boilerplate
</t>
<t>
Rewording of boilerplate material based on rfc-interest discussion starting with
http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-December/001078.html
</t>
<t>
Added examples in Appendix A
</t>
</section>
<section title="version 05->06">
<t>
Nits corrected
</t>
<t>
Fixede Boilerplate for IETF stream document without IETF consensus.
</t>
<t>
Corruption of examples due to XML bug corrected
</t>
</section>
<section title="version 06->07">
<t>
Nits corrected
</t>
<t>
Fixed inconsistency: Request for feedback only appeared in
the Experimental category, moved this to the "Update to this
memo section"
</t>
<t>
Changed the content of the 3rd paragraph of document status
to be a static (per stream) pointer to finding more information
about the document status, errata, and providing feedback.
This was to address the concern of having dynamic (per-document)
text in the boilerplate, if this "updates" section was
document specific.
</t>
</section>
<section title="version 07->08">
<t>
Introduced language to clarify that the RFC Editor is
responsible for details with respect to style and
formatting.
</t>
</section>
<!-- Document Editing Details section -->
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:45:42 |