One document matched: draft-otis-newtrk-rfc-set-00.txt
newtrk D. Otis
Internet-Draft Trend Micro
Expires: January 2, 2006 july 2005
XML structure for Set of RFC Descriptors
draft-otis-newtrk-rfc-set-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
With many RFC updates resulting in differing RFC designations, this
creates difficulty when determining which RFCs are significant for
use within a particular endeavour. Grouping RFC into sets that
embody a specific endeavour would permit a stable reference for those
interested in discovering the related details at a later date. To
provide current information related to the detailed adoption of the
endeavour, encompassed by the set of RFCs, a formulaic html link will
retrieve information stored in an IETF managed Status database. It
is also hoped the RFC Errata information will be made available in
Otis Expires January 2, 2006 [Page 1]
Internet-Draft SRD july 2005
the same manner.
This document proposes developing an Extensible Markup Language (XML)
structure to define a set of RFCs related to a specific endeavour.
The set would be limited to RFCs that are inter-related and describe
an isolated function. The set should not attempt to encompass
diverse applications which utilize a broad range of separable
functions. The intent of this document is to provide an optimal
means for locating relevant information made increasingly difficult
with a growing number or RFCs, updates, and corrections. The
expectation in this effort is that any RFC not found within some "set
of RFCs" is no longer relevant to any current endeavour. Being
within a "set of RFCs" does not infer any designation, other than an
RFC within the set is useful for some current endeavour.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SRD Identification and References . . . . . . . . . . . . . 3
3. XML Conversion Considerations . . . . . . . . . . . . . . . 4
4. The srd element . . . . . . . . . . . . . . . . . . . . . . 5
5. The title element . . . . . . . . . . . . . . . . . . . . . 6
6. The description element . . . . . . . . . . . . . . . . . . 6
7. The srdDate element . . . . . . . . . . . . . . . . . . . . 6
8. The docs element . . . . . . . . . . . . . . . . . . . . . . 6
9. The core element . . . . . . . . . . . . . . . . . . . . . . 7
10. The extensions element . . . . . . . . . . . . . . . . . . . 7
11. The guidance element . . . . . . . . . . . . . . . . . . . . 7
12. The obsoletes element . . . . . . . . . . . . . . . . . . . 7
13. The experimental element . . . . . . . . . . . . . . . . . . 7
14. The companion element . . . . . . . . . . . . . . . . . . . 8
15. Example HTML Page . . . . . . . . . . . . . . . . . . . . . 8
16. Example RSS Feed . . . . . . . . . . . . . . . . . . . . . . 9
17. Security Considerations . . . . . . . . . . . . . . . . . . 10
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
18.1 Normative References . . . . . . . . . . . . . . . . . . 10
18.2 Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 12
Otis Expires January 2, 2006 [Page 2]
Internet-Draft SRD july 2005
1. Introduction
The IETF has produced a large number of RFC documents. These
documents often are inter-related and may also emerge as a succession
of attempts. The large and often rapidly changing documents that
follow hundreds of separate endeavours has caused RFC designators
defined in [RFC2026] and [RFC1311] to poorly reflect current usage.
Rather than revisiting this designation process, it is hoped that by
providing a coherent organization using sets of documents, along with
relevant inter-operational information contained within a Status
database, reliance upon RFC designators can be reduced. This could
either spur better maintenance of the RFC designator approach, or
perhaps the designator process could become supplanted by the set of
RFCs Status database. This draft does not wish to predict how this
will develop, but simply outlines an evolutionary rather than a
revolutionary approach for a more comprehensible organization of
documents. If this set descriptor strategy proves untenable or
unuseful, it can be dropped, as it makes no other changes to current
procedures.
2. SRD Identification and References
This document proposes that a new document series called Set of RFC
Descriptors ("SRD"). These documents are comprised of Extensible
Markup Language, XML [W3C.REC-xml-20040204], structures used for
generating HTML, RSS, and plain-text outputs that link together the
related RFCs. The SRD documents would be managed under the direction
of the IESG, where they would also establish procedures for updating
the relevant SRD Status database, and hopefully include overview of
the RFC Editor's Errata database. Rather than publishing simple
pointers in indexes as, e.g., the STD series, this document proposes
that SRDs be created to encompass all useful RFCs. This document
also proposes a version of the SRDs be used in the initial
development process, to allow an overview of Work-In-Progess, WIP,
which may involve an extended work and approval time period.
The SRD is identified by a combination of name and number in the form
of {srd-name.serial-number}. As a general rule, when an HTML or
database link excludes the serial, version, or iteration number,
through the use of scripts, it will automatically reference the
current document. This auto-generated link is to simplify link
maintenance and to stabilize the SRD structures. The name for each
SRD is unique. To utilize the infrastructure supporting database
references for Status and Errata, an SRD being modified and not yet
approved, will include a prefix to indicate this effort represents
WIP.
The WIP SRD is identified by a prefix added. The prefix used for an
Otis Expires January 2, 2006 [Page 3]
Internet-Draft SRD july 2005
RFC-Set, while it is being modified, would be {'X'<iteration-
number>'-'<group-identifier>'-'}. If this document was modifying
{foobar.2} by the working group 'newtrk', the first iteration would
be {X0-newtrk-foobar.2}. When the document becomes accepted at some
point, it would become {foobar.3}. The 'newtrk' represents a group
identifier or possibly the name of an individual. This group
identifier permits simultaneous WIP SRD documents to be pending for
approval. Normally, an SRD is not allowed to reference an Internet-
Draft, but there would be an exception made for a WIP SRD. The WIP
SRD can not receive approval until all referenced Internet-Drafts
have also been accepted and replaced as RFCs.
To establish comprehensive coverage of RFCs with the SRD XML
documents, script generated relationships could automatically
generate rough versions of these documents. These automatically
generated documents would be given to the most relevant working
group, or a special working group dedicated to the task of making
needed corrections. Upon completion of this effort, only those RFCs
deemed currently unused should be excluded from being found within
some SRD document.
Once SRD documents are established, the Working Group chair is
responsible for ensuring the WIP version of all affected SRD
documents accompany an Internet-Draft submitted to the Area Director
for IESG action. The WIP SRD and the Internet-Draft would be
considered together through all review stages. Of course, all
referenced Internet-Draft acceptance must precede WIP SRD acceptance.
3. XML Conversion Considerations
XML and XSLT structures are used to create HTML, RSS, and Plain-Text
outputs for establishing stable hyper-link references. It is
expected that as information is added to the Errata Database, the
related HTML pages are regenerated to provide a means to
intelligently include an Errata link, in the case where such errata
information becomes available. When there are empty or missing
elements within the SRD document, those elements are automatically
excluded from the HTML page as well. The intent is to ensure a
minimum amount of information is presented.
This proposal is attempting to follow a similar process defined in
[RFC2629] and assumes the reader is familiar with this document. The
SRD XML declaration begins with a reference to the DTD, XSLT
[W3C.REC-xslt-19991116], processing options, and the "srd" element:
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE srd SYSTEM "rfcxxxx.dtd" >
<?xml-stylesheet type='text/xsl' href='rfcxxxx.xslt' ?>
Otis Expires January 2, 2006 [Page 4]
Internet-Draft SRD july 2005
<?srd sortrefs="yes"?>
<?srd strict="yes" ?>
<srd ... >
...
</srd>
The XML declaration and the following two lines of reference
information should be treated as opaque strings and nothing should
follow the "</srd>" tag. Make sure that all elements are properly
matched and nested.
4. The srd element
The "<srd ...>" tag at the beginning of the document, with a "wip"
attribute, produces an interim working draft that may include
references to Internet-Drafts. However, when this attribute is
removed by the RFC editor, a final SRD document is produced.
<srd set="foobar.2" wip="0-newtrk">
At a minimum, the "set" attribute should be present which indicates
both the set name and version. In the case of a WIP SRD, this
version number would be of the current SRD being modified. The other
attribute is "wip" which specifies both the current iteration and the
name of the entity making a change, as required when adding or
modifying an RFC. The srd information includes a sequence of
elements being the title, description, srdDate, doc, core,
extensions, guidance, obsoletes, experimental, and companion. The
Status database will provide a reference to an accountable entity for
the SRD, where this is not included within the srd itself.
<title>XML SRD</title>
<description>XML structure for example SRDs.</description>
<srdDate>2005-07-16T19:20:30+01:00</srdDate>
<docs>http://www.ietf.org/</docs>
<core>
<?srd include="reference.RFC.9876" ?>
<?srd include="reference.RFC.9875" ?>
</core>
<extensions>
<?srd include="reference.RFC.9912" ?>
</extensions>
<guidance>
<?srd include="reference.RFC.9915" ?>
</guidance>
<obsoletes>
<?srd include="reference.RFC.9811" ?">
</obsoletes>
Otis Expires January 2, 2006 [Page 5]
Internet-Draft SRD july 2005
<experimental>
<?srd include="reference.RFC.9837" ?">
</experimental>
<companion>
<?srd include="reference.SRD.srd-example.1" ?>
</compainion>
5. The title element
<title>
Title describes the entire RFC set.
</title>
The title element represents the title for the entire SRD set. This
supplements the simple label used as a set reference.
6. The description element
<description>
Description more fully describes the entire RFC set.
</description>
Description should be only a few sentences describing the RFC set.
7. The srdDate element
<srdDate>
YYYY-MM-DDThh:mm:ssTZD
</srdDate>
The srdDate element provides the date when the RFC set was accepted
for publishing. The format for the date is specified as a complete
date plus hours, minutes and seconds as specified in Date and Time
Formats [W3C.NOTE-datetime-19980827]. The 'T' between DD and hh is a
character used to separate date and time information. The "TZD"
represents the Time Zone Designator ('Z' or +hh:mm or -hh:mm).
8. The docs element
<docs>
http://www.ietf.org/
</docs>
The docs element provides the base used to reference related
documents.
Otis Expires January 2, 2006 [Page 6]
Internet-Draft SRD july 2005
9. The core element
<core>
<?srd include="reference.RFC.9876" ?>
<?srd include="reference.RFC.9875" ?>
</core>
The core element includes a list of references elements for RFCs as
defined for use with [RFC2629]. These RFCs encompass the basic
definitions. For WIP SRDs, a reference to an Internet-Draft would
take the form:
<?srd include="reference.I-D.housley-binarytime" ?>
10. The extensions element
<extensions>
<?srd include="reference.RFC.9912 ?">
</extensions>
The extension element includes a list of references elements for RFCs
as defined for use with [RFC2629]. These RFCs encompass optional
enhancements to the basic definitions.
11. The guidance element
<guidance>
<?srd include="reference.RFC.9815" ?>
</guidance>
The guidance element includes a list of references elements for RFCs
as defined for use with [RFC2629]. These RFCs encompass advice
related to the deployment of the RFCs within the set.
12. The obsoletes element
<obsoletes>
<?srd include="reference.RFC.9811" ?>
</obsoletes>
The obsoletes element includes a list of references elements for RFCs
as defined for use with [RFC2629]. These RFCs encompass RFCs which
have been replaced by the RFCs within the set.
13. The experimental element
<obsoletes>
<?srd include="reference.RFC.9811" ?>
Otis Expires January 2, 2006 [Page 7]
Internet-Draft SRD july 2005
</obsoletes>
The obsoletes element includes a list of references elements for RFCs
as defined for use with [RFC2629]. These RFCs encompass RFCs which
are deemed experimental and relate to either core or extension RFCs.
14. The companion element
<companion>
<?srd include="reference.SRD.srd-example.1">
</compainion>
The companion element includes a list of references elements for SRDs
using the same structure as defined for use with [RFC2629]. These
RFCs encompass optional enhancements to the basic definitions.
15. Example HTML Page
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<base href="http://www.ieft.org/">
<title>SRD Simple Mail Transfer Protocol:xxxx, SMTP</title>
</head>
<body>
<div id="Documents making up the SMTP standard, STD10">
<h1><a href="http://www.ietf.org/">Set of RFC Descriptors</a></h1>
<p STYLE="font-weight: bold;"> Simple Mail Transfer Protocol:xxxx,
SMTP, STD10; <a href="http://www.ietf.org/srd/srd-status.html?
srd=smtp">Status</a><br>
</p>
</div>
<div>
<span></span><a href="http://www.ietf.org/rfc/rfc2821.txt">RFC2821
Simple Mail Transfer Protocol, SMTP</a> <a href="http://
www.rfc-editor.org/errata/errata.html?rfc=2821">Errata</a>
<br>
<br>
<span STYLE="font-weight: bold;">Extensions </span><br>
<a href="http://www.ietf.org/rfc/rfc3463.txt">RFC3463 Enhanced Mail
System Status Codes</a> <br>
<a href="http://www.ietf.org/rfc/rfc3848.txt">RFC3848 ESMTP and LMTP
Transmission Types Registration</a> <br>
<a href="http://www.ietf.org/rfc/rfc1652.txt">RFC1652 SMTP Service
Extension for 8bit-MIME transport</a> <br>
<a href="http://www.ietf.org/rfc/rfc1870.txt">RFC1870 SMTP Service
Extension for Message Size Declaration</a> <br>
<a href="http://www.ietf.org/rfc/rfc2920.txt">RFC2920 SMTP Service
Otis Expires January 2, 2006 [Page 8]
Internet-Draft SRD july 2005
Extension for Command Pipelining</a> <br>
<a href="http://www.ietf.org/rfc/rfc2034.txt">RFC2034 SMTP Service
Extension for Returning Enhanced Error Codes</a> <br>
<a href="http://www.ietf.org/rfc/rfc2554.txt">RFC2554 SMTP Service
Extension for Authentication</a> <br>
<a href="http://www.ietf.org/rfc/rfc3207.txt">RFC3207 SMTP Service
Extension for Secure SMTP over Transport Layer Security</a> <br>
<a href="http://www.ietf.org/rfc/rfc3030.txt">RFC3030 SMTP Service
Extensions for Transmission of Large and Binary MIME Messages</a> <a
href="http://www.rfc-editor.org/errata/errata.html?
rfc=3030">Errata</a><br>
<span><br>
<pan STYLE="font-weight: bold;">Experimental</span><br>
</span><a href="http://www.ietf.org/rfc/rfc1830.txt">RFC1830 SMTP
Service Extensions for Transmission of Large and Binary MIME
Messages</a>
<br>
<a href="http://www.ietf.org/rfc/rfc1845.txt">RFC1845 SMTP Service
Extension for Checkpoint/Restart</a><br>
<br>
<span><span STYLE="font-weight: bold;">Related SRD</span><br>
</span><a
href="http://www.ietf.org/srd/srd-smtp-dsn.html">SRD-SMTP-DSN SMTP
Delivery Status Notifications (DSN)</a>
<br>
<a href="http://www.ietf.org/srd/srd-smtp-spam.html">SRD-SMTP-SPAM
SMTP and SPAM (SMTP-SPAM)</a>
<br>
<a href="http://www.ietf.org/srd/srd-smtp-odrd.html">On-demand relay,
delivery, and alternatives to TURN
</a></div>
</body>
</html>
16. Example RSS Feed
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title>SRD List</title>
<link>http://www.ietf.org/</link>
<description>Set of RFC Descriptors.</description>
<language>en-us</language>,
<pubDate>Tue, 10 Jun 2005 04:00:00 GMT</pubDate>
<lastBuildDate>Tue, 10 Jun 2005 09:41:01 GMT</lastBuildDate>
<docs>http://www.ietf.org/srd/</docs>
<generator>IETF Editor 2.0</generator>
<managingEditor>editor@ietf.org</managingEditor>
Otis Expires January 2, 2006 [Page 9]
Internet-Draft SRD july 2005
<webMaster>webmaster@www.ietf.org</webMaster>
<item>
<title>SRD Simple Mail Transfer Protocol:xxxx, SMTP</title>
<link>http://www.ietf.org/srd/srd-smtp.html</link>
<description>Simple Mail Transfer Protocol, SMTP href="http://
www.ietf.org/srd/srd-smtp-xxxx.html">SMTP</a>;.</description>
<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
<guid>http://www.ietf.org/srd/srd-smtp-xxxx.html#item01</guid>
</item>
<item>
<title>SRD POP/IMAP Authentication with CRAM-MD5:xxxx, CRAM-MD5</
title>
<link>http://www.ietf.org/srd/srd-cram-md5.html</link>
<description>POP/IMAP Authentication with CRAM-MD5, SMTP
href="http://www.ietf.org/srd/srd-cram-md5-xxxx.html">CRAM-MD5</
a>;.</description>
<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
<guid>http://www.ietf.org/srd/srd-cram-md5-xxxx.html#item01</guid>
</item>
...
</channel>
</rss>
17. Security Considerations
This document specifies an administrative procedure for the IETF and
hence does not raise any new issues about the security of the
Internet. However, the availability of the type of document
described here may provide a convenient mechanism and repository of
vulnerabilities and other issues that are discovered after RFCs are
issued, but that do not justify updating (or for which resources are
not available to update) the relevant RFC. Having an obvious place
to look for those notifications and discussions for relevant
documents might enhance overall security somewhat.
18. References
18.1 Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[W3C.NOTE-datetime-19980827]
Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C
NOTE NOTE-datetime-19980827, August 1998.
[W3C.REC-xml-20040204]
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
Otis Expires January 2, 2006 [Page 10]
Internet-Draft SRD july 2005
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC REC-xml-20040204, February 2004.
[W3C.REC-xslt-19991116]
Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C
REC REC-xslt-19991116, November 1999.
18.2 Informative References
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
Author's Address
Douglas Otis
Trend Micro
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires January 2, 2006 [Page 11]
Internet-Draft SRD july 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otis Expires January 2, 2006 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 10:01:18 |