ASD S1000D URN: A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D
Permanent, location-independent names for aerospace and defense technical documentation resources.
Rushing, S., "A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D", RFC 4688, DOI 10.17487/RFC4688, October 2006, <https://www.rfc-editor.org/info/rfc4688>.
@misc{rfc4688,
series = {Request for Comments},
number = 4688,
howpublished = {RFC 4688},
publisher = {RFC Editor},
doi = {10.17487/RFC4688},
url = {https://www.rfc-editor.org/info/rfc4688},
author = {S. Rushing},
title = {{A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D}},
pagetotal = 8,
year = 2006,
month = oct,
} RFC text
Contents
Network Working Group S. Rushing
Request for Comments: 4688 Inmedius
Category: Informational October 2006
A Uniform Resource Name (URN) Namespace for
Aerospace and Defence Industries Association of Europe (ASD)
Specification 1000D
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a Uniform Resource Name (URN) namespace for
naming persistent resources defined by Aerospace and Defence
Industries Association of Europe (ASD) Specification 1000D.
Table of Contents
1. Introduction ....................................................2
2. Specification Template ..........................................2
3. Examples ........................................................5
4. Security Considerations .........................................6
5. Namespace Considerations and Community Considerations ...........6
6. IANA Considerations .............................................6
7. Normative References ............................................6
1. Introduction
Specification 1000D [1] (S1000D) is an international specification
for the procurement and production of technical publications. The
current issue of the specification has been jointly produced by the
Aerospace and Defence Industries Association of Europe (ASD;
previously AECMA, European Association of Aerospace Industries) and
the Aerospace Industries Association of America (AIA). The
specification is used worldwide by a variety of commercial and
government entities for the development of technical documentation.
The specification adopts ISO, Computer-Aided Acquisition and Life-
Cycle Support (CALS), and W3C standards to promote document
standardization in which information is generated in a neutral
format. Compliant documentation generated using the specification
can be processed on different, and often disparate, IT systems. It
is this feature, added to the concept of modularization, that makes
the specification acceptable to the wider international community.
Portions of S1000D define a resource coding system allowing resources
created under the specification to be uniquely identified in global
environment. To provide for the creation of a web-based resource
management system, ASD would like to assign URNs [2][3][4] to
resources created under the specification in order to retain unique,
permanent, location-independent names for these resources, in
addition to providing a framework for resolution of these resources.
For more information about ASD and S1000D, see http://www.s1000d.org.
This namespace specification is for a formal namespace.
2. Specification Template
Namespace ID:
To be assigned. Request the string "S1000D".
Registration information:
Version 2
Date: <2005-03-7, when submitted>
Declared registrant of the namespace:
Name:
ASD TPSMG Chairperson
Address:
Corporate Technical Services
Technical Documentation
Kentigern House
65 Brown Street
Glasgow G2 8EX
UK
Contact:
Mr. Dennis Hoyland
E-mail: adcts@techinfo.mod.uk
Declaration of structure:
The identifier has the following ABNF [5] structure.
;start ABNF notation
URN = "URN:" namespace NSS
namespace = "S1000D:"
NSS = dmc-nss / pmc-nss / csn-nss / icn-nss
com-nss / ddn-nss / dml-nss
;Define the subnamespace as an subnamespace identifier
;plus a subnamespace code string
dmc-nss = "DMC-" nss-code
pmc-nss = "PMC-" nss-code
csn-nss = "CSN-" nss-code
icn-nss = "ICN-" nss-code
com-nss = "COM-" nss-code
ddn-nss = "DDN-" nss-code
dml-nss = "DML-" nss-code
;Define the subnamespace code as a string encoded to the
;format specified by the namespace identifier and an
;optional extension string indicating the resource status.
nss-code = subcode subext
;The code strings are a groups of alpha and digit characters
;separated by the dash character. The specific code syntax
;for each subnamespace is described in ASD Specification 1000D.
subcode = 1*(DIGIT / ALPHA / "-")
;Define the encoding extension as an optional set of status
;indicators separated by the "_" character.
subext = [issue] [lang]
issue = "_I-" 3DIGIT
lang = "_L-" 2ALPHA
;ABNF core rules RFC 2234, listed for clarity
;ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
;DIGIT = %x30-39 ; 0-9
;end ABNF notation
The following subnamespaces are currently defined:
"DMC" - contains all Data Modules Codes
"PMC" - contains all Publication Module Codes
"CSN" - contains all Catalogue Sequence Numbers
"ICN" - contains all Illustration Control Numbers.
"COM" - contains all Comment Codes.
"DDN" - contains all Data Dispatch Notices.
"DML" - contains all Data Module Lists.
Example usage:
URN:S1000D:{subid}-{subcode}_{subext}
e.g., URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN
where:
{subid} = DMC, The code is a Data Module Code
{subcode} = AE-A-07-05-0000-00A-040A-A, String in DMC syntax
{subext} = _I-001_L-EN, the first issue in English.
Relevant ancillary documentation:
ASD S1000D, Issue 2.2
Reference: Chap 7.4.1.2, "IETP - Resource resolution"
url: http://www.s1000d.org
Identifier uniqueness considerations:
Identifier uniqueness is guaranteed through processes outlined
within ASD S1000D. All codes defined within the specification
must begin with a Model Identifier (MI) that will be registered
with the NATO Maintenance and Supply Agency (NAMSA) and is never
to be reused. All project-generated codes are prefixed by the
assigned MI and are required by the specification to be unique
within the scope of the project. Since all project codes are
prefixed by a globally unique MI, and since these codes must be
unique within the project, all generated identifiers will be
globally unique.
Identifier persistence considerations:
Persistence of identifiers is dependent upon suitable delegation
of resolution and the fact that generated identifiers are to be
persistent once published. Existing information objects can be
used in new projects by referencing them through their persistent
identifiers.
Process of identifier assignment:
Identifiers are assigned in the following manner. Projects are
assigned a Model Identifier by the NAMSA organization. Projects
then generate identifiers using the processes outlined in ASD
S1000D. The codes are prefixed with the encoding identifier and
possibly postfixed by the extension status identifiers.
Process for identifier resolution:
The project identified by the Model Identifier is responsible for
providing a method of resource resolution. A suggested method of
resolution is outlined in ASD S1000D.
Rules for Lexical Equivalence:
All generated identifiers are to be considered case-insensitive.
Conformance with URN syntax:
No special considerations.
Validation mechanism:
Identifiers must conform to ASD S1000D.
Scope:
Global.
3. Examples
The following examples are not guaranteed to be real and are provided
for illustrative purposes only.
URN:S1000D:DMC-AE-A-07-04-0101-00A-040A-A
URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN
URN:S1000D:ICN-AE-B-291101-M-C0419-00571-A-01-1
URN:S1000D:PMC-AE-F6117-00001-00
4. Security Considerations
There are no additional security considerations other than those
normally associated with the use and resolution of URNs in general.
5. Namespace Considerations and Community Considerations
Resources will be named and maintained in accordance with the
processes described in this document, in addition to the processes
described in S1000D. Any organization or individual can utilize the
specification to create resources described by S1000D. Resolution
and/or use of created resources is unrestricted by the specification
in order to promote widespread adoption of open ASD standards,
although organizations creating resources may control them as they
see fit.
6. IANA Considerations
This document describes a "S1000D" URN NID registration for the
S1000D organization and has been entered into the IANA registry of
URN NIDs (http://www.iana.org/assignments/urn-namespaces).
7. Normative References
[1] "ASD Specification 1000D", May 2005.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[4] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
Author's Address
Sean Rushing
Inmedius, Inc.
2710 South Kolb Road
Tucson, AZ 85730
USA
Phone: +01 520 747 3955
EMail: srushing@inmedius.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
AI ELI5
On this page
§1S1000D and Its Naming Challenge
S1000D (Specification 1000D) is an international standard for creating technical documentation, especially aircraft and aerospace maintenance manuals. It was developed jointly by the Aerospace and Defence Industries Association of Europe (ASD) and the Aerospace Industries Association of America (AIA).
The specification uses ISO and W3C standards and focuses on modular, reusable documentation components. A single aircraft manual might contain thousands of separate information modules—engine specifications, wiring diagrams, maintenance procedures—that can be assembled in different ways and reused across projects.
The challenge is naming these resources so they can be uniquely identified and found anywhere, whether they are stored on a web server, in a company database, or shared across organizations. A regular web URL would break if the file moved; an ISBN-like identifier would stay the same forever. This RFC creates such an identifier scheme using URNs.
Aircraft manuals are huge and divided into thousands of pieces—engine info, wiring diagrams, procedures. These pieces get reused. We need names for them that work the same way ISBN numbers work for books: they never change, no matter where the book sits on the shelf.
§2URNs and Namespaces
A Uniform Resource Name (URN) is a persistent identifier for a resource. Unlike a URL (which tells you where something is), a URN identifies what something is. An ISBN like 978-0-486-27557-8 is a URN for a book. It is location-independent: you can find that book at a library, a bookstore, or online; the ISBN stays the same.
URNs are organized into namespaces. The ISBN namespace holds book identifiers. The DOI namespace holds digital object identifiers. The S1000D namespace (defined by this RFC) holds identifiers for S1000D resources.
A URN has the format URN:namespace:namespace-specific-string. For S1000D, the format is URN:S1000D:resourcecode, where the resource code has a defined structure.
A URN is like a library catalog number: it says what something is, not where it is. The S1000D namespace is a special set of library numbers just for aerospace manuals.
§3The S1000D Resource Code Structure
Every S1000D URN has a resource type prefix, a resource code string, and optional issue and language tags.
The resource type prefixes are:
DMC(Data Module Code): an information module like a procedure or specification.PMC(Publication Module Code): a publication (a published document or manual).CSN(Catalogue Sequence Number): an entry in a catalog or index.ICN(Illustration Control Number): a diagram or illustration.COM(Comment Code): a comment or annotation on a resource.DDN(Data Dispatch Notice): a notice of changed or new resources.DML(Data Module List): a list grouping related modules.
The code string follows the syntax defined in the S1000D specification itself and includes dashes and alphanumeric characters (e.g., AE-A-07-05-0000-00A-040A-A).
Optional issue and language tags are appended with underscores: _I-001 means issue 001, and _L-EN means English. An example complete URN: URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN.
Every resource has a type ("this is a procedure" or "this is a diagram"), then a code (like a catalog number), then optionally which version and language ("issue 5, in Spanish").
§4Ensuring Global Uniqueness
S1000D ensures that all URNs are globally unique through a registration process. Each organization or project that creates S1000D resources is assigned a Model Identifier by the NATO Maintenance and Supply Agency (NAMSA). This Model Identifier is never reused.
All resource codes created by that project are prefixed with the project's Model Identifier, making every code globally unique within that project space. Since the Model Identifier itself is globally unique and unreused, the combination is unique worldwide.
This design means that if two different aerospace companies both create a data module with the same local code, the two URNs are still different because each company's codes begin with its unique Model Identifier.
Once a resource is published and assigned a URN, the identifier persists forever. This allows organizations to reference resources across projects and time, knowing the name will never change.
Every company gets a unique prefix ("Airbus gets AB, Boeing gets BX"). All their manuals start with that prefix. So two companies can both make a "procedure 001," but they get different URNs because of the prefix.