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)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html 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