RFC 4688

A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D

πŸ“… published October 2006, from ietf

RFC 4688: A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D πŸŽ€

okay bestie, let's get into this one πŸ’… Here's the title block:

  • Network Working Group 🌸
  • Author: Sean Rushing from Inmedius πŸ¦‹
  • Category: Informational (so it's info only, not a standard) πŸ“š
  • Date: October 2006 πŸ“
  • Obsoletes / Updates: The title block doesn't list any RFC this one obsoletes or updates, so nothing to track there ✨

Status of This Memo πŸ’œ

This memo is here to give info to the Internet community. It is not an Internet standard, no cap. Distribution is unlimited, so share it with everyone 🌈

Copyright (C) The Internet Society (2006).

Abstract ✨

okay so this document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by the Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. It's basically a naming system for stuff that needs to stick around 🫢

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 ✨

So S1000D [1] is an international spec for procuring and producing technical publications. It's giving "everyone uses this" energy πŸ’– The current issue was jointly made by the Aerospace and Defence Industries Association of Europe (ASD; formerly AECMA, the European Association of Aerospace Industries) and the Aerospace Industries Association of America (AIA). Lots of commercial and government orgs around the world use it to make technical documentation.

The spec leans on ISO, Computer-Aided Acquisition and Life-Cycle Support (CALS), and W3C standards to keep documents standardized, with information written in a neutral format. Documentation made with it can be processed on different, and often totally disparate, IT systems 🧚 That, plus the whole modularization thing, is what makes it work for the wider international community. Iconic πŸ‘‘

S1000D also defines a resource coding system so resources made under the spec can be uniquely identified in a global environment. To build a web-based resource management system, ASD wants to assign URNs [2][3][4] to resources made under the spec. The goal is names that stay unique, permanent, and location-independent, plus a framework for resolving those resources πŸ”₯

For more info about ASD and S1000D, check out http://www.s1000d.org.

This namespace spec 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. Let's look at the grammar, bestie πŸ€“

;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 spec 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 the spec requires them to be unique within the scope of the project. Since every project code starts with a globally unique MI, and those codes have to be unique within the project, all generated identifiers end up globally unique. That's the whole plan, and it's honestly so clean 😭

Identifier persistence considerations

Persistence of identifiers depends on suitable delegation of resolution, plus the fact that generated identifiers are meant 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 like this. Projects get a Model Identifier from the NAMSA organization. Then the projects generate identifiers using the processes outlined in ASD S1000D. The codes get prefixed with the encoding identifier and may be postfixed with 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. So dmc and DMC are the same vibe πŸ’…

Conformance with URN syntax

No special considerations.

Validation mechanism

Identifiers must conform to ASD S1000D.

Scope

Global 🌍

⏭️ to be continued in part 2, where we get into Section 3 (Examples) and everything after it!

Acknowledgement 🫢

okay bestie, last but not least πŸ’– the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) ✨ so big thank yous to IASA for covering that πŸŽ€ literally the reason this whole doc can exist, so it deserves a shoutout πŸ“£πŸ’…

πŸ“¦ where this page comes from