Subject: [newtrk] Rough outline of evolutionary approach.

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Jun 2005 18:08:08 -0700

TOC 
newtrk
D. Otis
Internet-Draft
Kelkea Inc.
Expires: November 30, 2005
june 2005

                                XML structure for Set of RFC Descriptors

                                            draft-otis-newtrk-rfc-set-00

Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
section 3 of RFC 3667. 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
become aware will be disclosed, in accordance with RFC 3668.

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 November 30, 2005.

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. To provide current information
related to the detailed adoption of the endeavour, encompassed by the
set of RFCs, a formulaic html link will retrieve Status information
stored in a database. It is also hoped the RFC Errata information will
be made available in the same manner.

This document proposes developing an XML structure to define a set of
RFCs related to a specific endeavour. It is hoped that by being able to
obtain a comprehensive overview, together with topical information
covering adoption, the IETF will be able to better prioritize updates to
RFC designations. This document does not intend to alter processes
defined in RFC 2026 or RFC1311. However, the Status database may evolve
into becoming an alternative to RFC designations. 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 the RFC is useful for some current endeavour.

________________________________________________________________________

Table of Contents

1.  Introduction
2.  SRD Identification and References
3.  XML Conversion Considerations
4.  Example XML structure
5.  Example HTML Page
6.  Example RSS Feed 
7.  Security Considerations
8.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

________________________________________________________________________
 TOC 

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]Bradner, S., The Internet Standards Process -- Revision 3,
October 1996. and [RFC1311]Postel, J., Introduction to STD Notes, March
1992. to poorly reflect current usage. Rather than revisiting this
designation process, it is hoped that by providing a coherent
organization of sets of documents, along with relevant inter-operational
information, reliance upon RFC designators is reduced. This could either
spur better maintenance of the designator approach, or perhaps the
designator process could become supplanted by the set of RFCs Status.
This draft does not wish to predict how this will develop, but simply
outlines an evolutionary rather than a revolutionary approach in for a
more comprehensible organization of documents. If this set descriptor
strategy proves untenable or unuseful, it can be dropped, as it makes no
changes to current procedures.

________________________________________________________________________
 TOC 

2. SRD Identification and References

This document proposes that a new document series called Set of RFC
Descriptors ("SRD") that are comprised of XML structures for generating
HTML, RSS, and plain-text outputs that link together the related RFCs.
The documents would be managed under the direction of the IESG, where
they would also establish procedures for updating the relevant SRD
Status 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.

The SRD is identified by a combination of name and number in the form of
{srd-name.serial-number}. When an HTML or database reference excludes
the serial-number, it will reference the current serial-number for the
SRD. This auto-generated serial-number simplifies link maintenance. The
name for each SRD is unique. To share the infrastructure supporting
database references for Status and Errata, an SRD being modified and not
yet approved includes a prefix to indicate this effort represents WIP.

The WIP SRD is identified by a prefix added. The prefix used for an
RFC-Set, while it is being modified, would be
{'X'<iteration-number><group-identifier>'-'}. If this document was
modifying {foobar.2} by group 'newtrk', the first iteration would be
{X0newtrk-foobar.2}. When the document becomes accepted at some point,
it would become {foobar.3}. The 'newtrk' represents a group identifier.
This group identifier permits simultaneous WIP SRD documents to be
pending for approval. A link that excludes the iteration-number would
reference the most recent document.

Normally, an SRD is not allowed to reference an Internet-Draft, but
there would be an exception made for a WIP SRD. Exclusion of the
Internet-Draft version number also returns the most current draft. The
WIP SRD can not receive approval until all Internet-Drafts have also
been accepted as RFCs. 

________________________________________________________________________
 TOC 

3. XML Conversion Considerations

The use of the XML structures are used to create HTML, RSS, and
Plain-Text outputs. 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 there is
such information available.

When there are empty sections within the SRD structure, those sections
are automatically excluded from the HTML page as well. The intent is to
ensure a minimum amount of information is presented.

________________________________________________________________________
 TOC 

4. Example XML structure

<srd>

<title>SRD Example</title>

<description>XML structure for example SRD.</description>

<pubDate>Tue, 10 Jun 2005 04:00:00 GMT</pubDate>

<docs>http://www.ietf.org/srd/</docs>

<core>

<xref target="rfc9876">

<xref target="rfc9875">

</core>

<extensions>

<xref target="rfc9912">

</extensions>

<guidance>

<xref target="rfc9815">

</guidance>

<obsoletes>

<xref target="rfc9811">

</obsoletes>

<companion>

<xref target="srd-set_reference.1">

</compainion>

</srd>

________________________________________________________________________
 TOC 

5. Example HTML Page

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<base href="http://srd.ieft.org/">

<title>SRD xxxx: Simple Mail Transfer Protocol, SMTP</title>

</head>

<body>

<div id="Documents making up the SMTP standard, STD10">

<h1><a href="http://srd.ietf.org/">Set of RFC Descriptors</a></h1>

<p STYLE="font-weight: bold;"> xxxx: Simple Mail Transfer Protocol,
SMTP, STD10; <a href="http://srd.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
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://srd.ietf.org/srd/srd-smtp-dsn.html">SRD-SMTP-DSN
SMTP Delivery Status Notifications (DSN)</a>

<br>

<a href="http://srd.ietf.org/srd/srd-smtp-spam.html">SRD-SMTP-SPAM SMTP
and SPAM (SMTP-SPAM)</a>

<br>

<a href="http://srd.ietf.org/srd/srd-smtp-odrd.html">On-demand relay,
delivery, and alternatives to TURN 

</a></div>

</body>

</html>

________________________________________________________________________
 TOC 

6. Example RSS Feed 

<?xml version="1.0"?>

<rss version="2.0">

<channel>

<title>SRD List</title>

<link>http://srd.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>[email-masked]</managingEditor>

<webMaster>[email-masked]</webMaster>

<item>

<title>srd xxxx: Simple Mail Transfer Protocol, SMTP</title>

<link>http://srd.ietf.org/srd/srd-smtp.html</link>

<description>Simple Mail Transfer Protocol, SMTP
href="http://srd.ietf.org/srd/srd-xxxx-smtp.html">SMTP</a>;.</description>

<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>

<guid>http://srd.ietf.org/srd/srd-xxxx-smtp.html#item01</guid>

</item>

<item>

<title>SRD xxxx: POP/IMAP Authentication with CRAM-MD5, CRAM-MD5</title>

<link>http://srd.ietf.org/srd/srd-cram-md5.html</link>

<description>POP/IMAP Authentication with CRAM-MD5, SMTP
href="http://srd.ietf.org/srd/srd-xxxx-cram-md5.html">CRAM-MD5</a>;.</description>

<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>

<guid>http://srd.ietf.org/srd/srd-xxxx-cram-md5.html#item01</guid>

</item>

...

</channel>

</rss>

________________________________________________________________________
 TOC 

7. 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.

________________________________________________________________________
 TOC 

8 Informative References

[RFC1311]
Postel, J., "Introduction to STD
Notes", RFC 1311, March 1992.
[RFC2026]
Bradner, S., "The Internet Standards
Process -- Revision 3", RFC 2026,
October 1996.

________________________________________________________________________
 TOC 

Author's Address

Douglas Otis
 
Kelkea Inc.
 
1737 North First Street, Suite 680
 
San Jose, CA 94043
 
USA
                             Phone: 
+1.408.453.6277
                             EMail: 
[email-masked]

________________________________________________________________________
 TOC 

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
[email-masked].

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jun 2005 13:31:34 +0200

I like the simplicity. I think a more filled out example
with text comments, pointers to interop report(s), and
pointers to errata, would be quite convincing in its HTML
version.

    Brian

>                                             draft-otis-newtrk-rfc-set-00
<snip>

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html