One document matched: draft-iab-streams-headers-boilerplates-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:headers-boilerplates.xml"?>
<!-- automatically generated by xml2rfc v1.33 on 2008-06-27T10:35:57Z -->
<!--
# $Id: headers-boilerplates.xml 15 2008-06-26 15:05:41Z 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'
category="bcp"
docName="draft-iab-streams-headers-boilerplates-00"
>
<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 abbrev="(IAB)">Internet Architecture
Board</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 a standard
acknowledgement section. 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>
RFCs published before this document (e.g. the one immeditatly
prior to this one <xref target="RFCXXXX-1" />) (??? or is it
prior to approval of this document?) 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>
<!-- 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"/> and <xref target="RFC4844"/>
and their succession for current detail of IETF process and
RFCs 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>
ISSN: [TBD] <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 memo is primarily concerned with the information in
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.' [Steve Crocker,
private communication]. 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>IETF Stream </t>
<t>IAB Stream</t>
<t>IRTF Stream</t>
<t>Independent Stream</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. Current relationships
are "Updates" and "Obsoletes". This document introduces
the new relation "Clarifies" which can be used when a
new RFC updates a previous RFC without making any
normative changes.
</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>
<t>
The ISSN number is the International Standard Serial
Number<xref target="ISO3297"/>. Once such number has been assigned to the RFC series this
element will appear here.
</t>
</list>
</t>
<!-- Title Page Header section -->
</section>
<section 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>
Going forward, the "Status of This Memo" will start with a
single line describing the status. It will also include a
statement describing the 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. 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 is documents a Best Current Practice
</t>
<t hangText="For other categories" >
This memo is not an Internet Standard Track
specification, it is published for Informational
purposes.
</t>
</list>
</t>
<t>
The second paragraph contains the current text <xref
target="RFC2223"/> describing categories is as follows:
<list style='hanging'>
<t hangText="Standards Track:">
"This document specifies an Internet standards track
protocol for the Internet community, and requests
discussion and suggestions for improvements. Please
refer to the current edition of the "Internet Official
Protocol Standards" (STD 1) for the standardization
state and status of this protocol. Distribution of this
memo is unlimited."
</t>
<t hangText="Best Current Practice:">
"This document specifies an Internet Best Current
Practices for the Internet Community, and requests
discussion and suggestions for improvements.
Distribution of this memo is unlimited."
</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. Distribution
of this memo is unlimited."
</t>
<t hangText="Informational:">
"This memo provides information for the Internet
community. This memo does not specify an Internet
standard of any kind. Distribution of this memo is
unlimited."
</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. Going forward, these paragraphs will be
defined as part of RFC stream definition.
</t>
<t>
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). Per the IETF's specification
process, 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 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>
<!-- 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>
[To Be Removed before publication]
</t>
<t>
The documents has two sections, including this one that need
to be removed after publication.
</t>
<t>
ISSN: [TBD] is where the International Standards Serial Number will
need to be appear once assigned.
</t>
<t>
The number "XXXX" is to be replaced with RFC number of this
memo.
</t>
<t>
The Reference RFCXXXX-1 is to be replaced with the details of
the RFC published prior to this publication.
</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="480: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="481: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="482: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>
<reference anchor='RFCXXXX-1'>
<front>
<title>[The RFC previous to this one]</title>
<author initials='' surname=''
fullname='John Doe'>
<organization abbrev='Foo'>
Blaaa Fooo
</organization>
</author>
<date month='---' year='2007' day='---'/>
</front>
</reference>
<?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="518: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="519: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="520: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, Russ
Housley, David Oran.
</t>
<t>
This document was produced using the xml2rfc tool <xref
target="RFC2629"/>.
</t>
<!-- Acknowledgements section -->
</section>
<section title="Document Editing Details">
<t>
[To Be Removed before publication]
</t>
<t>
This section will contain a discription of the changes between
the various versions of this document.
</t>
<!-- Document Editing Details section -->
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:57:37 |