From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3349.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3349.txt (limited to 'doc/rfc/rfc3349.txt') diff --git a/doc/rfc/rfc3349.txt b/doc/rfc/rfc3349.txt new file mode 100644 index 0000000..da16612 --- /dev/null +++ b/doc/rfc/rfc3349.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 3349 Dover Beach Consulting, Inc. +BCP: 59 July 2002 +Category: Best Current Practice + + + A Transient Prefix for Identifying Profiles under Development by the + Working Groups of the Internet Engineering Task Force + +Status of this Memo + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + As a part of their deliverables, working groups of the IETF may + develop BEEP profiles. During the development process, it is + desirable to assign a transient identifier to each profile. If the + profile is subsequently published as an RFC, then a permanent + identifier is subsequently assigned by the IANA. + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Best Current Practice [Page 1] + +RFC 3349 Transient IDs for BEEP Profiles July 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + B. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Best Current Practice [Page 2] + +RFC 3349 Transient IDs for BEEP Profiles July 2002 + + +1. Introduction + + Each BEEP profile [1] is identified by a URI [2]. The BEEP + specification uses URIs to identify a BEEP profile both: + + o statically, when a profile is formally defined (RFC 3080's Section + 5.1); and, + + o dynamically, during channel management (RFC 3080's Section 2.3.1). + + If the BEEP profile appears on the standards-track [3], then the IANA + is responsible for assigning the URI associated with the BEEP + profile. Otherwise, the entity specifying the BEEP profile is free + to assign a URI under its administration to the profile. + + If a working group of the IETF is developing a BEEP profile, then, + during the development process, it is desirable to use a transient + identifier for the profile. Further, it is desirable that the + transient identifier be associated with the working group. + + This memo defines the practice for making such an assignment. Note + that this practice does not apply to activities outside of working + groups -- anyone able to assign a URL is capable of defining a URI + for the purposes of identifying the BEEP profiles that they develop. + +2. Practice + + When a working group is formed, the IETF secretariat assigns a brief + mnemonic prefix to the working group, e.g., "provreg" or "sacred". + + When a working group begins development of a document which specifies + a BEEP profile, the working group chair assigns a transient + identifier of the form "http://iana.org/beep/transient/XXX/YYY" where + "XXX" is the working group's mnemonic and "YYY" is a unique string. + Although the resulting URI must conform to the URI syntax, the "YYY" + portion is otherwise arbitrary. For example, it may contain a sub- + hierarchy (e.g., "epp/1.0"). + + For example, + + http://iana.org/beep/transient/provreg/epp/1.0 + http://iana.org/beep/transient/sacred/pdm + + might be assigned by the chairs of the "provreg" and "sacred" working + groups, respectively. + + Following this, the working group chair completes a BEEP profile + registration template, and submits this information to the IANA. + + + +Rose Best Current Practice [Page 3] + +RFC 3349 Transient IDs for BEEP Profiles July 2002 + + + Note that although the IETF hasn't established a practice with + respect to the use of capitalization in URLs employed for namespace + purposes, the W3C has a lowercase-only policy. Working group chairs + are encouraged to consider this when making assignments. + +3. Security Considerations + + This document describes an administrative convention and raises no + additional security considerations. Of course, each BEEP-based + protocol has its own set of security considerations, which should be + described in the relevant specification. + +References + + [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC + 3080, March 2001. + + [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [3] Hovey, R. and S. Bradner, "The Organizations Involved in the + IETF Standards Process", BCP 11, RFC 2028, October 1996. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Best Current Practice [Page 4] + +RFC 3349 Transient IDs for BEEP Profiles July 2002 + + +Appendix A. Acknowledgements + + The author gratefully acknowledges the contributions of: Dan Kohn and + Bob Wyman. + +Appendix B. IANA Considerations + + The IANA maintains a registry of transient identifiers used for BEEP + profiles under development in the IETF, using the profile + registration template defined in Section 5.1 of [1]. + + Note that unlike the registration procedures defined in Appendix B of + [1], the working group chair (instead of the IESG) is responsible for + authorizing the registration. + +Author's Address + + Marshall T. Rose + Dover Beach Consulting, Inc. + POB 255268 + Sacramento, CA 95865-5268 + US + + Phone: +1 916 483 8878 + EMail: mrose@dbc.mtview.ca.us + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Best Current Practice [Page 5] + +RFC 3349 Transient IDs for BEEP Profiles July 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rose Best Current Practice [Page 6] + -- cgit v1.2.3