idnits 2.17.1 draft-otis-newtrk-rfc-set-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 809. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... The set SHOULD NOT encompass divers...' RFC 2119 keyword, line 119: '...RD within an SRD MUST include the seri...' RFC 2119 keyword, line 163: '... MUST precede WIP SRD acceptance....' RFC 2119 keyword, line 208: '... "set" attribute MUST be present and i...' RFC 2119 keyword, line 261: '...erence. This element MUST be present....' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2005) is 6772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC9875' is mentioned on line 769, but not defined == Missing Reference: 'RFC9876' is mentioned on line 770, but not defined == Missing Reference: 'RFC9912' is mentioned on line 773, but not defined == Missing Reference: 'RFC9915' is mentioned on line 776, but not defined == Missing Reference: 'RFC9811' is mentioned on line 779, but not defined == Missing Reference: 'RFC9837' is mentioned on line 782, but not defined ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 newtrk D. Otis 3 Internet-Draft Trend Micro 4 Expires: April 14, 2006 J. Leslie 5 JLC.net 6 October 11, 2005 8 XML structure for Set of RFC Descriptors 9 draft-otis-newtrk-rfc-set-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 14, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document introduces a new document series called Set of RFC 43 Documents (SRDs). SRDs will be distinguished by names and serial 44 numbers. SRDs contain Extensible Markup Language (XML) which can 45 automatically produce HTML and plaintext versions for human 46 consumption 48 With many RFC being updated, this creates difficulty when determining 49 which RFCs are necessary as references when implementing or using 50 protocols. Grouping RFC into sets that embody a specific endeavour 51 would permit stable references for those interested in discovering 52 related details. The SRD name may also serve as a reference for 53 topical information stored in a database that is made available. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. SRD Identification and References . . . . . . . . . . . . . 3 59 3. SRD Development . . . . . . . . . . . . . . . . . . . . . . 3 60 4. XML Conversion Considerations . . . . . . . . . . . . . . . 4 61 5. The srd element . . . . . . . . . . . . . . . . . . . . . . 5 62 6. The srdref element . . . . . . . . . . . . . . . . . . . . . 6 63 7. The title element . . . . . . . . . . . . . . . . . . . . . 6 64 8. The description element . . . . . . . . . . . . . . . . . . 7 65 9. The srdDate element . . . . . . . . . . . . . . . . . . . . 7 66 10. The core element . . . . . . . . . . . . . . . . . . . . . . 7 67 11. The extensions element . . . . . . . . . . . . . . . . . . . 7 68 12. The guidance element . . . . . . . . . . . . . . . . . . . . 8 69 13. The replaces element . . . . . . . . . . . . . . . . . . . . 8 70 14. The experimental element . . . . . . . . . . . . . . . . . . 8 71 15. The companion element . . . . . . . . . . . . . . . . . . . 8 72 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 73 17. Security Considerations . . . . . . . . . . . . . . . . . . 9 74 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 18.1 Normative References . . . . . . . . . . . . . . . . . . 9 76 18.2 Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 78 A. The SRD DTD . . . . . . . . . . . . . . . . . . . . . . . . 10 79 B. Example SRD XSLT . . . . . . . . . . . . . . . . . . . . . . 12 80 C. Example HTML output . . . . . . . . . . . . . . . . . . . . 18 81 Intellectual Property and Copyright Statements . . . . . . . 19 83 1. Introduction 85 It is becoming increasingly difficult to determine which RFCs are 86 necessary as references when implementing or using protocols. The 87 STD series defined in [RFC1311] is a guide, but often fails to list 88 all the necessary RFCs. The Maturity Levels defined in [RFC2026] are 89 increasingly confusing the picture by the need to update higher 90 maturity documents with lower maturity revisions. It is hoped that 91 by providing a coherent organization using sets of documents, along 92 with relevant inter-operational information contained within a 93 separate database, an easier-to-use alternative can be introduced. 94 If this SRD strategy proves untenable or unuseful, it can be dropped, 95 as it makes no other changes to current procedures. 97 This document proposes developing an Extensible Markup Language (XML) 98 structure to define a set of RFCs related to a specific endeavour. 99 The set SHOULD NOT encompass diverse applications which utilize a 100 broad range of separable functions. The intent of this document is 101 to provide an optimal means for locating relevant information made 102 increasingly difficult by a growing number or RFCs, updates, and 103 corrections. The eventual expectation might be that any RFC not 104 found within some SRD is not relevant to any current endeavour. 106 2. SRD Identification and References 108 This document proposes a new document series called Set of RFC 109 Documents ("SRD"). These documents contain Extensible Markup 110 Language [W3C.REC-xml-20040204] structures used for generating 111 outputs such as HTML, RSS, and plain-text outputs that link together 112 the related RFCs. The SRD documents would be managed under the 113 direction of the IESG, which may also establish procedures for 114 updating the relevant topical information stored in a database that 115 might also include overview of the RFC Editor's Errata database. 117 The SRD is identified by a combination of name and number in the form 118 of {srd-name.serial-number}. The name for each SRD is unique. Any 119 references to an SRD within an SRD MUST include the serial-number. 120 The initial SRD document serial-number starts at 0. As a general 121 rule, when an HTML or database link excludes the serial, version, or 122 iteration number, through the use of scripts, it will automatically 123 reference the current document. This auto-generated link is to 124 simplify link maintenance and to stabilize the SRD structures. 126 3. SRD Development 128 This document also proposes a version of the SRDs be used in the 129 initial development process, to allow an overview of Work-In-Progess, 130 WIP, which may involve an extended work and approval time period. 132 The WIP SRD is identified by a prefix added which does not interfere 133 with automatic linking. The prefix used for an SRD, while it is 134 being modified, would be: 136 {'X''-''-'} 138 The group-identifier is an alpha-numeric string that represents a 139 group identifier or possibly the name of an individual. If this 140 document was modifying {foobar.1} by the working group 'newtrk', the 141 first iteration would be: 143 X0-newtrk-foobar.1 145 When the document becomes accepted at some point, it would become 146 {foobar.2}. The group identifier permits simultaneous WIP SRD 147 documents to be pending for approval. 149 Normally, an SRD is not allowed to reference an Internet-Draft, but 150 there would be an exception made for a WIP SRD. The WIP SRD can not 151 receive approval until all referenced Internet-Drafts have also been 152 accepted and replaced as RFCs. 154 During the introduction of SRDs, inclusion of a WIP SRD with an I-D 155 submission is optional. The IESG should provide for a person to 156 review necessary changes to SRDs. By default, this might be the 157 appropriate Area Director. At some point, inclusion of the WIP SRD 158 could be mandated by the IESG. The Area Director would then ensure 159 the WIP version of all affected SRD documents accompany an Internet- 160 Draft submitted to the Area Director for IESG action. The WIP SRD 161 and the Internet-Draft would be considered together through all 162 review stages. Of course, all referenced Internet-Draft acceptance 163 MUST precede WIP SRD acceptance. 165 4. XML Conversion Considerations 167 XML and XSLT structures are used to create HTML, RSS, and Plain-Text 168 outputs for establishing stable hyper-link references. When there 169 are empty or missing elements within the SRD document, those elements 170 would be excluded from the HTML page as well. The intent is to 171 ensure a minimum amount of information is presented. To selectively 172 include the Errata Database links, the related pages would then need 173 to be regenerated when Errata is subsequently established for an RFC. 175 Writing an SRD document from scratch would follow a process similar 176 to that described in [RFC2629] for use of the XML-to-RFC tool. The 177 SRD XML declaration begins with a reference to the DTD, XSLT 178 [W3C.REC-xslt-19991116], processing options, and the "srd" element: 180 181 182 183 184 185 186 ... 187 189 The lines preceding the should be the same for all SRDs and 190 nothing should follow the ending "" tag. Make sure that all 191 elements are properly matched and nested. 193 5. The srd element 195 The "set" attribute included within the "" tag at the 196 beginning of the document determines the name and serial number of 197 the SRD output. If a "wip" attribute is included, this produces a 198 WIP SRD that may include references to Internet-Drafts. When this 199 "wip" attribute is removed and the serial number is advanced, a final 200 SRD document is then produced. Although SRD serial numbers start at 201 the value of 0, approved SRDs serial numbers will be 1 or greater. 203 Example of srd attributes declaring both base document and the group 204 making changes: 206 208 The "set" attribute MUST be present and indicates both the set name 209 and version. The "wip" attribute is optional, and specifies both the 210 WIP iteration and the name of the group or person making a change. 212 The srd information includes a sequence of elements being the title, 213 description, srdDate, core, extensions, guidance, replaces, 214 experimental, and companion. The topical information database may 215 provide a reference to an accountable entity for the SRD, where this 216 is not included within the srd itself. 218 Example of srd content: 220 Example SRD Title 221 XML structure for example SRDs. 222 2005-07-16 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 243 6. The srdref element 245 The srdref element is empty, but includes reference attributes that 246 take the form: 248 250 The Document Types are RFC, I-D, and SRD for RFCs, Internet-drafts 251 and SRDs respectively. 253 7. The title element 255 256 Title describes the entire RFC set. 257 259 The title element represents the title for the entire SRD set. This 260 supplements the simple label defined by the "set=" attribute which is 261 used as the set reference. This element MUST be present. 263 8. The description element 265 266 Description more fully describes the entire RFC set. 267 269 The description should be no more than a few sentences describing the 270 SRD. This element MUST be present. 272 9. The srdDate element 274 275 YYYY-MM-DD 276 278 The srdDate element provides the date when the SRD was published. 279 The format for the date is specified as a complete date as specified 280 in Date and Time Formats [W3C.NOTE-datetime-19980827]. The 'YYYY' 281 represents the year. The 'MM' represents the numeric month. The 282 'DD' represents the numeric day. This element MUST be present. 284 10. The core element 286 287 288 289 291 The core element contains srdref elements that reference RFCs or I-Ds 292 that encompass the definitions related to a specific endeavour. This 293 element MUST be present and MUST include srdref elements. For WIP 294 SRDs, a reference to an Internet-Draft would take the form: 296 298 11. The extensions element 300 301 302 304 The extensions element contains srdref elements that reference RFCs 305 or I-Ds that encompass the definitions of optional enhancements to 306 the basic definitions. Extension RFCs do not describe a separate 307 endeavour, but are not an essential component of the endeavour 308 encompassed by the SRD. This element should not be present unless 309 srdref elements are included. 311 12. The guidance element 313 314 315 317 The guidance element contains srdref elements that reference RFCs or 318 I-Ds that encompass the definitions of advice related to the 319 deployment of the RFCs within the set. This element should not be 320 present unless srdref elements are included. 322 13. The replaces element 324 325 326 328 The replaces element contains srdref elements that reference RFCs, 329 I-Ds, or SRDs that encompass the definitions that have been updated 330 or obsoleted and are no longer directly relevant except as a 331 reference to the prior definitions. This element should not be 332 present unless srdref elements are included. 334 14. The experimental element 336 337 338 340 The experimental element contains srdref elements that reference RFCs 341 or I-Ds that encompass the definitions which are deemed experimental 342 and relate to either core or extension RFCs. This element should not 343 be present unless srdref elements are included. 345 15. The companion element 347 348 349 351 The companion element contains srdref elements that reference SRDs 352 that encompass closely related endeavours, but which are not needed 353 by other elements of the SRD. The intent of the companion element is 354 to assist those attempting to locate definitions for a comprehensive 355 application which typically includes these closely related 356 endeavours. This element should not be present unless srdref 357 elements are included. 359 16. IANA Considerations 361 There are no IANA considerations in this draft. 363 17. Security Considerations 365 This document specifies an administrative procedure for the IETF and 366 hence does not raise any new issues about the security of the 367 Internet. However, the availability of the type of document 368 described here may provide a convenient mechanism and repository of 369 vulnerabilities and other issues that are discovered after RFCs are 370 issued, but that do not justify updating (or for which resources are 371 not available to update) the relevant RFC. Having an obvious place 372 to look for those notifications and discussions for relevant 373 documents might enhance overall security somewhat. 375 18. References 377 18.1 Normative References 379 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 380 June 1999. 382 [W3C.NOTE-datetime-19980827] 383 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C 384 NOTE NOTE-datetime-19980827, August 1998. 386 [W3C.REC-xml-20040204] 387 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 388 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 389 Edition)", W3C REC REC-xml-20040204, February 2004. 391 [W3C.REC-xslt-19991116] 392 Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C 393 REC REC-xslt-19991116, November 1999. 395 18.2 Informative References 397 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 398 March 1992. 400 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 401 3", BCP 9, RFC 2026, October 1996. 403 Authors' Addresses 405 Douglas Otis 406 Trend Micro 407 1737 North First Street, Suite 680 408 San Jose, CA 95112 409 USA 411 Phone: +1.408.453.6277 412 Email: doug_otis@trendmicro.com 414 John Leslie 415 JLC.net 416 10 Souhegan Street 417 Milford, NH 03055 418 USA 420 Phone: +1.603.673.6132 421 Email: john@jlc.net 423 Appendix A. The SRD DTD 425 427 432 442 443 444 446 456 458 463 464 465 466 467 472 473 474 475 476 477 479 Appendix B. Example SRD XSLT 481 484 488 490 491 492 493 body {color: #000000; font-family: helvetica, arial, 494 sans-serif; font-size: 12pt;} 495 h1 {color: #333333; font-size: 14pt; line-height: 21pt; 496 font-family: helvetica, arial, sans-serif; 497 page-break-after: avoid;} 498 h2 {color: #000000; font-size: 12pt; line-height: 15pt; 499 font-family: helvetica, arial, sans-serif; 500 page-break-after: avoid;} 501 p {margin-left: 2em; margin-right: 2em;} 502 .error {font-size: 14pt; background-color: red;} 503 .title {color: #990000; font-size: 18pt; line-height: 18pt; 504 font-weight: bold; text-align: left;} 505 .filename {color: #333333; font-weight: bold; font-size: 12pt; 506 line-height: 21pt; text-align: left;} 507 508 509 511 513 515 517 518 520 522 524 525 526 527 528 529 530 532 533 534 "' 535 536 540 541 544 545 546 547 548 549 <xsl:value-of select="$srd-title"/> 550 551 554 555 556

557 558
SRD:[ 561 562 563
SRD:[ 567 568

569

570 571

572 573 574 575 576 578 580 581 582 583 584 585 587 589 590 591 592 593 594 595 597 599 600 601 602 603 604 605 607 609 610 611 612 613 614 615 617 619 620 621 622 623 624 625 627 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 672 673 674 675

Core

676 677 678

Extensions

679 680 681

Guidance

682 683 684

Replaces

685 686 687

Experimental

688 689 690

Companion

691 692 693 694 695 697 699 701 702 703 [] 706 707 errata 709 710 712 714 715 716 717 718 719 [] 722 723 725 727 728 729 730 731 732 733 734 736 738 739 740 741 742 744 745 746 748 750 751 752 753 754 755

Invalid Document Type []

757 758 759
760 761 763 Appendix C. Example HTML output 765 Example SRD Title SRD:[example.1] 2005-07-16 766 XML structure for example SRDs. 768 Core 769 [RFC9875] errata Overview Core Example for SRD testing 770 [RFC9876] errata Primary Core Example for SRD testing 772 Extensions 773 [RFC9912] errata Extension Example for SRD testing 775 Guidance 776 [RFC9915] errata The Guidance Example for SRD testing 778 Replaces 779 [RFC9811] errata The replace Example for SRD testing 781 Experimental 782 [RFC9837] errata The Experimental Example for SRD testing 784 Companion 785 [SRDexample.1] The SRD Example for SRD testing 787 Intellectual Property Statement 789 The IETF takes no position regarding the validity or scope of any 790 Intellectual Property Rights or other rights that might be claimed to 791 pertain to the implementation or use of the technology described in 792 this document or the extent to which any license under such rights 793 might or might not be available; nor does it represent that it has 794 made any independent effort to identify any such rights. Information 795 on the procedures with respect to rights in RFC documents can be 796 found in BCP 78 and BCP 79. 798 Copies of IPR disclosures made to the IETF Secretariat and any 799 assurances of licenses to be made available, or the result of an 800 attempt made to obtain a general license or permission for the use of 801 such proprietary rights by implementers or users of this 802 specification can be obtained from the IETF on-line IPR repository at 803 http://www.ietf.org/ipr. 805 The IETF invites any interested party to bring to its attention any 806 copyrights, patents or patent applications, or other proprietary 807 rights that may cover technology that may be required to implement 808 this standard. Please address the information to the IETF at 809 ietf-ipr@ietf.org. 811 Disclaimer of Validity 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Copyright Statement 823 Copyright (C) The Internet Society (2005). This document is subject 824 to the rights, licenses and restrictions contained in BCP 78, and 825 except as set forth therein, the authors retain all their rights. 827 Acknowledgment 829 Funding for the RFC Editor function is currently provided by the 830 Internet Society.