A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force
RFC 3349
Document | Type |
RFC - Best Current Practice
(August 2002; No errata)
Also known as BCP 59
Was draft-mrose-beep-transientid (individual in app area)
|
|
---|---|---|---|
Author | Marshall Rose | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3349 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Patrik Fältström | ||
IESG note | Responsible: Finished | ||
Send notices to | <mrose+mtr.ietf@dbc.mtview.ca.us> |
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.Show full document text