| Network Working Group | M. Blanchet |
| Internet-Draft | A. Schiltknecht |
| Intended status: Informational | Viagenie/SANA |
| Expires: April 17, 2016 | P. Shames |
| Jet Propulsion Laboratory, NASA | |
| October 15, 2015 |
A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)
draft-blanchet-ccsds-urn-01.txt
This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2016.
Copyright (c) 2015 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.
The Consultative Committee for Space Data Systems (CCSDS) was formed in 1982 by the major space agencies of the world to provide a forum for discussion of common problems in the development and operation of space data systems. At the time of publication of this document, it is composed of eleven member agencies, twenty-eight observer agencies, and over 100 industrial associates. Since its establishment, CCSDS has been actively developing Recommendations for data- and information-systems standards, intended to promote interoperability and cross support among cooperating space agencies.
CCSDS has a permanent secretariat reporting to the CCSDS Engineering Steering Group, which maintains documents for the CCSDS protocols. CCSDS also has its Naming Authority under the Space Assigned Number Authority (SANA) that manages its registries and namespaces.
CCSDS produces protocol standards documents requiring a permanent and unique namespace. CCSDS also uses Extensible Markup Language (XML) schemas to define XML messaging in its various protocols recommendations. These schemas require a persistent, unique and location-independent namespace for identification purposes.
This namespace specification is for a formal namespace identifier (NID), as per [RFC3406].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Registering organization:
Designated Contact:
The formal syntax definitions below are given in ABNF [RFC5234].
The namespace-specific string (NSS) in the urn:ccsds names hierarchy begins with a subnamespace identifier (SNID), followed by a delimiter and a subnamespace-dependent string
CCCSDS-URN = "urn:ccsds:" SNID ":" SUBNAMESPACE-SPECIFIC-STRING
where <SNID> is a unique subnamespace identifier for the specification, and <SUBNAMESPACE-SPECIFIC-STRING> is a unique identifier within the subnamespace identifier scope.
<SNID> has the same syntax as a <NID> as defined in [RFC2141].
The Space Assigned Numbers Authority (SANA) assigns SNIDs.
The syntax of <SUBNAMESPACE-SPECIFIC-STRING> is dependent on the <SNID> and MUST be defined by a CCSDS Document. This document does not pose any additional restrictions to the <SUBNAMESPACE-SPECIFIC-STRING> other than what is defined in the NSS syntax as defined by [RFC2141]:
SUBNAMESPACE-SPECIFIC-STRING = 1*<URN chars>
<URN chars> is defined in Section 2.2 of [RFC2141].
SANA keeps the "urn:ccsds" namespace as a registry. Procedures to register a subnamespace identifier are described in the header of the registry.
SANA is the authority responsible for uniqueness of identifiers by the recommendations of CCSDS. SANA will assign unique identifiers and keep a public registry.
CCSDS is committed to guarantee the accessibility and persistence of all the resources that are assigned URNs.
Assignment of identifiers is limited to CCSDS and those authorities explicitly designated by CCSDS. CCSDS is committed to assign URN identifiers only in accord to the rules specified in this document or in future updates to this document, either published as IETF RFC documents or as CCSDS recommendations.
The CCSDS namespace is not currently listed with a Resolution Discovery System (RDS), but nothing about the namespace prohibits the future definition of appropriate resolution methods or listing with an RDS.
The <SNID> part of URNs in the CCSDS hierarchy is case insensitive. Thus, the <SNID> MUST be case normalized before comparison.
The intention of this document is to only restrict the syntax of the <SNID>. The syntax of the <SUBNAMESPACE-SPECIFIC-STRING> follows the general syntax of a URN:
SUBNAMESPACE-SPECIFIC-STRING = 1*<URN chars>
Documents defining a subnamespace identifier SHOULD specify further syntactic restrictions in <SUBNAMESPACE-SPECIFIC-STRING>. It is RECOMMENDED that these documents forbid the assignment of URNs containing characters in the <reserved> set ("%", "/", "?", and "#") as defined in [RFC2141]. This is in accordance with Section 2.2 of [RFC3986].
The validation mechanism of URNs in the hierarchy is specific for each SNID and SHOULD be defined when an SNID is assigned.
URNs in the hierarchy without an assigned SNID are considered to be invalid.
Global URNs are relevant for the space agencies networks both in space and on Earth.
URNs in this section are not guaranteed to be real, and are listed here only for illustration purposes. The following are examples of valid URNs for the "document" and "schema" categories:
CCSDS is an international standards development organization in the field of space and Earth communications. The use of this URN hierarchy is expected to be broad, including but not limited to usage for:
The CCSDS documents and registries are available openly.
Usage of the URN namespace has been requested within the CCSDS community for various projects.
The CCCSDS Management Council approved this document in its DATE meeting.
No additional security considerations are relevant, other than those normally related with the general use and resolution of URNs.
IANA is requested to register the "ccsds" NID within the IANA registry of URN NIDs in the "Formal URN Namespaces" sub-registry.
This document is based on previous versions authored by Martin A. Soto and Louis Reich. This document was reviewed by the XML Steering Group(XSG) of the Systems Engineering and Architecture Area(SEA) in CCSDS.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2141] | Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997. |
| [RFC3406] | Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008. |