CableLabs URN: A Uniform Resource Name (URN) Namespace for CableLabs
A namespace for identifying cable industry specifications and resources.
Cardona, E., Channabasappa, S., and J-F. Mule, "A Uniform Resource Name (URN) Namespace for CableLabs", RFC 6289, DOI 10.17487/RFC6289, June 2011, <https://www.rfc-editor.org/info/rfc6289>.
@misc{rfc6289,
series = {Request for Comments},
number = 6289,
howpublished = {RFC 6289},
publisher = {RFC Editor},
doi = {10.17487/RFC6289},
url = {https://www.rfc-editor.org/info/rfc6289},
author = {E. Cardona and S. Channabasappa and J-F. Mule},
title = {{A Uniform Resource Name (URN) Namespace for CableLabs}},
pagetotal = 7,
year = 2011,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) E. Cardona
Request for Comments: 6289 S. Channabasappa
Category: Informational J-F. Mule
ISSN: 2070-1721 CableLabs
June 2011
A Uniform Resource Name (URN) Namespace for CableLabs
Abstract
This document describes the Namespace Identifier (NID) 'cablelabs'
for Uniform Resource Names (URNs) used to identify resources
published by Cable Television Laboratories, Inc. (CableLabs).
CableLabs specifies and manages resources that utilize this URN
identification model. Management activities for these and other
resource types are handled by the manager of the CableLabs' Assigned
Names and Numbers registry.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6289.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. URN Specification for CableLabs . . . . . . . . . . . . . . . . 3
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Namespace Considerations . . . . . . . . . . . . . . . . . . . 5
5. Community Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction
CableLabs is a non-profit research and development consortium that is
dedicated to pursuing new cable telecommunications technologies and
to helping its cable operator members integrate those technical
advancements into their business objectives. Within CableLabs,
specification activities are organized into projects such as
DOCSIS(R), PacketCable(TM), and OpenCable(TM), and technical work is
conducted within focus teams. Product vendors, manufacturers, and
cable operator members are invited to join the focus teams that
create technical specifications.
Occasionally, CableLabs specification efforts require identifiers in
a managed namespace so that they are unique and persistent. To
ensure that the uniqueness is absolute, the registration of a
specific Uniform Resource Name (URN) [RFC2141] Namespace Identifier
(NID) for use by CableLabs is being specified in this document, in
full conformance with the NID registration process specified in
[RFC3406].
2. URN Specification for CableLabs
Namespace ID:
cablelabs
Registration information:
registration version number: 1
registration date: 2011-04-18
Declared registrant of the namespace:
Registering organization
Name: Cable Television Laboratories, Inc.
Address: 858 Coal Creek Circle, Louisville, CO 80027, USA
Designated contact
Role: Manager, Standards
Email: ietf_standards@cablelabs.com
Declaration of syntactic structure:
The Namespace Specific String (NSS) of all URNs that use the
"cablelabs" NID will have the following structure:
{CLclass}:{CLClassSpecificString}
The "CLclass" is a US-ASCII string that conforms to the URN
syntax requirements specified in [RFC2141] and defines a
specific class of resource type. Each class will have a
specific labeling scheme that is covered by
"CLClassSpecificString", which also conforms to the naming
requirements of [RFC2141].
CableLabs maintains the CableLabs' Assigned Names and Numbers
[CANN] specification that will contain the assignment of
CableLabs' resource classes and the specific registration values
assigned for each resource class.
Relevant ancillary documentation:
CableLabs publishes information regarding the registered
resources in the CableLabs' Assigned Names and Numbers
specification ([CANN]).
Identifier uniqueness considerations:
CableLabs will manage resource classes using the "cablelabs" NID
and will be the authority for managing resources and associated
subsequent strings. CableLabs is expected to guarantee the
uniqueness of the strings themselves, or it may permit secondary
responsibility for certain defined resources.
CableLabs could allow the use of experimental type values for
testing purposes only. Note that using experimental types may
create collisions as multiple users may use the same values for
resources and specific strings.
Identifier persistence considerations:
CableLabs will update the CableLabs' Assigned Names and Numbers
specification ([CANN]) to document the registered resources that
use the "cablelabs" NID.
Process of identifier assignment:
CableLabs will provide procedures for registration of each type
of resource that it maintains. Each such resource may have
three types of registration activities:
1. Registered values associated with CableLabs documents or
services
2. Registration of values or sub-trees to other entities
3. Name models for use in experimental purposes
Process for identifier resolution:
The namespace is not listed with a resolution discovery system;
this is not applicable for this URN registration.
Rules for lexical equivalence:
No special considerations; the rules for lexical equivalence of
[RFC2141] apply.
Conformance with URN syntax:
No special considerations.
Validation mechanism:
None specified. URN assignment will be handled by procedures
implemented in support of CableLabs activities.
Scope:
Global
3. Example
The following example represents a hypothetical URN that could be
assigned by CableLabs.
urn:cablelabs:packetcable-example:ue:rst-sample
This example defines the URN to be used for User Equipment (UE)
conforming to the sample Residential SIP Telephony (RST) application
specified within CableLabs' PacketCable RST specification suite.
4. Namespace Considerations
CableLabs develops specifications that may require the use of data
models. URN Namespaces are key constructs to manage the definitions
of those data models reliably with persistence and uniqueness.
The use of URNs should also help specification authors to maintain
different versions of URNs and dependencies between URNs across
different versions of CableLabs specifications if they so wish.
5. Community Considerations
Participants involved in the development and usage of CableLabs
specifications and cable industry deployments will benefit from the
publication of this namespace by providing consistent and reliable
names for the XML namespaces, schema locations, and similar
identifiers of physical data models published within CableLabs
specifications.
The CableLabs specifications are publicly available and are licensed
to manufacturers on a nondiscriminatory basis. CableLabs will
maintain the allocation of resources for the "cablelabs" NID within
the following specification: "CableLabs' Assigned Names and Numbers"
[CANN], which will be publicly available for viewing. CableLabs will
also maintain the corresponding specifications where the registered
resources are referenced or used.
6. IANA Considerations
This document adds a new entry ("cablelabs") in the urn-namespaces
registry. This is the defining document. The entry can be found in
the "Uniform Resource Names (URN) Namespaces" registry available from
the IANA site (http://www.iana.org) and any associated mirrors.
7. Security Considerations
There are no additional security considerations other than those
normally associated with the use and resolution of URNs in general,
which are described in [RFC1737], [RFC2141], and [RFC3406].
8. Acknowledgements
The authors wish to thank Alfred Hoenes, Ted Hardie, and Peter Saint-
Andre for their useful comments and suggestions. The authors also
acknowledge that the text from [RFC4358] formed the basis for the
initial version of this document.
9. References
9.1. Normative References
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
9.2. Informative References
[CANN] Cable Television Laboratories Inc., "CableLabs' Assigned
Names and Numbers", 2011,
<http://www.cablelabs.com/specifications/cpSpecs.html>.
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC4358] Smith, D., "A Uniform Resource Name (URN) Namespace for
the Open Mobile Alliance (OMA)", RFC 4358, January 2006.
Authors' Addresses
Eduardo Cardona
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Phone: +1 303 661 3375
EMail: e.cardona@cablelabs.com
Sumanth Channabasappa
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Phone: +1 303 661 3307
EMail: sumanth@cablelabs.com
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Phone: +1 303 661 9100
EMail: jf.mule@cablelabs.com
AI ELI5
On this page
§1CableLabs and the Need for Standard Names
Cable Television Laboratories, Inc. is a non-profit research consortium dedicated to developing cable telecommunications technologies. Its members include product vendors, manufacturers, and cable operator companies. CableLabs organizes work into projects like DOCSIS (Data Over Cable Service Interface Specification), PacketCable for voice services, and OpenCable for set-top boxes, with technical specifications developed collaboratively.
As CableLabs creates data models and specifications, different systems and vendors need to reference the same concepts unambiguously. For example, a cable modem manufacturer needs to know exactly what packet structure a specification refers to, and later versions of that specification need to reference previous versions reliably. URNs provide this stable, persistent naming.
CableLabs decided to register a formal URN namespace with IANA to manage these identifiers centrally rather than allowing each specification to create its own naming scheme.
CableLabs is a group that makes the technical rules for cable TV systems so that all the different makers' equipment works together. They need official names for all the different parts and settings.
§2The CableLabs URN Structure
The registered namespace identifier is cablelabs. All URNs in this namespace use a two-part structure:
urn:cablelabs:{CLclass}:{CLClassSpecificString}
The CLclass (CableLabs class) identifies a category of resources—such as a specification project, data type, or service definition. Each class has its own naming rules and registration procedures documented in CableLabs standards.
The CLClassSpecificString is the specific identifier within that class. For instance, a hypothetical URN for a user equipment type in the PacketCable Residential SIP Telephony application might be:
urn:cablelabs:packetcable-example:ue:rst-sample
This names both the specification project (PacketCable) and the specific component (user equipment for Residential SIP Telephony).
Each CableLabs name has a general category—like 'DOCSIS' or 'PacketCable'—and then a specific name within that category. That way different equipment makers know exactly which specification they are implementing.
§3Registry and Community Support
CableLabs maintains the CableLabs' Assigned Names and Numbers (CANN) registry, which documents all registered resource classes and the values assigned within each. This registry is publicly available, ensuring that manufacturers and developers can reference it when implementing CableLabs specifications.
CableLabs specs are licensed to manufacturers on a non-discriminatory basis, and the company provides public access to its registry so that any vendor implementing PacketCable, DOCSIS, or OpenCable equipment can use the same URN identifiers as any other vendor.
The namespace also supports experimental values for testing purposes, though these are not registered permanently. CableLabs may permit sub-registries for certain resource types, allowing secondary entities to manage portions of the namespace under CableLabs oversight.
CableLabs publishes a list of all the official names so that any company making cable equipment can look them up and use the right names. Everyone gets to see the list and follow the same rules.
§4Why CableLabs Needs Persistent Names
Cable specifications often evolve over time and reference earlier versions. Developers implementing a cable modem or set-top box need to know which versions of which data structures they are supporting. If a specification document says 'implement the configuration structure defined at urn:cablelabs:docsis:config:v3', anyone reading that years later knows exactly which version is meant, even if the specification has been updated.
URNs are location-independent: they identify the resource itself, not a specific file or website. This makes them ideal for long-term technical references that must survive organizational changes, server migrations, and document updates.
The CANN registry works like the IANA number registries that manage IP addresses and port numbers: it is the single source of truth that prevents conflicts and ensures every manufacturer can reliably reference the same specifications.
If a company building a cable box wants to know 'what does this specification mean?', they look up the official name in the registry and find the right definition. Everyone uses the same names, so equipment from different companies all works together.