BEEP transient prefix: A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force
How IETF working groups name BEEP profiles while they are still drafts, before IANA hands out a permanent identifier.
Rose, M., "A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force", BCP 59, RFC 3349, DOI 10.17487/RFC3349, August 2002, <https://www.rfc-editor.org/info/rfc3349>.
@misc{rfc3349,
series = {Request for Comments},
number = 3349,
howpublished = {RFC 3349},
publisher = {RFC Editor},
doi = {10.17487/RFC3349},
url = {https://www.rfc-editor.org/info/rfc3349},
author = {M. Rose},
title = {{A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force}},
pagetotal = 6,
year = 2002,
month = aug,
} RFC text
Contents
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.
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
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.
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.
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
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.
AI ELI5
On this page
§1Why Profiles Need Identifiers
Each BEEP profile (defined in RFC 3080) is identified by a URI. BEEP uses that URI in two places: statically, when a profile is formally defined, and dynamically, during channel management.
If a profile is on the standards track, IANA is responsible for assigning its URI. Otherwise, whoever specifies the profile is free to assign a URI under their own administration.
A working group that is still developing a profile has a gap: the permanent IANA URI does not exist yet. The RFC says a transient identifier is desirable during development, and that it should be associated with the working group.
Every game needs a name so players can ask for it. A game that is still being invented needs a temporary name until the real one is chosen.
§1.1Who the Practice Applies To
The practice applies only to IETF working groups. The RFC notes that it does not apply to activities outside of working groups: anyone able to assign a URL can define a URI to identify the BEEP profiles they develop.
So this is a narrow administrative convention, not a general rule for naming every BEEP profile.
This rule is only for the club's own projects. Anyone outside the club can name their own projects however they like.
§2How a Transient Identifier Is Assigned
When a working group is formed, the IETF secretariat assigns it a brief mnemonic prefix, for example provreg or sacred.
When the working group starts a document that specifies a BEEP profile, the working group chair assigns an identifier of the form http://iana.org/beep/transient/XXX/YYY. XXX is the working group's mnemonic and YYY is a unique string. The result must conform to the URI syntax, but the YYY part is otherwise arbitrary and may contain a sub-hierarchy such as epp/1.0.
The chair then completes a BEEP profile registration template and submits it to IANA.
The club gives each team a short nickname. The team captain writes a temporary label that starts with that nickname and sends it to the office that keeps the list.
http://iana.org/beep/transient/provreg/epp/1.0
http://iana.org/beep/transient/sacred/pdm§2.1Examples and Capitalization
The RFC gives two examples of identifiers the chairs of the provreg and sacred working groups might assign: http://iana.org/beep/transient/provreg/epp/1.0 and http://iana.org/beep/transient/sacred/pdm.
On capitalization, the RFC notes that the IETF has no established practice for URLs used as namespace names, while the W3C has a lowercase-only policy. Working group chairs are encouraged to consider this.
The examples show what a finished temporary label looks like. The advice is to write the label in small letters so nobody mixes up big and small ones.
§5IANA Registry and Authorization
IANA maintains a registry of the transient identifiers used for BEEP profiles under development in the IETF. It uses the profile registration template from Section 5.1 of RFC 3080.
One difference from the normal procedure: the working group chair, rather than the IESG, authorizes the registration.
Security considerations: the RFC describes an administrative convention that raises no additional security considerations. Each BEEP-based protocol has its own, described in its own specification.
The office keeps a list of all temporary labels. The team captain, not the big boss, is the one who says yes to adding a label.