doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

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]
+