A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D
draft-rushing-s1000d-urn-00

Network Working Group                                         S. Rushing
Internet-Draft                                                  Inmedius
Expires: May 1, 2006                                    November 1, 2005

              A URN Namespace for ASD Specification 1000D
                    draft-rushing-s1000d-urn-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 1, 2006      .

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a Uniform Resource Name (URN) namespace for
   naming persistent resources defined by ASD Specification 1000D.

Rushing                  Expires May 1, 2006                    [Page 1]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Specification Template . . . . . . . . . . . . . . . . . . . . 3
   3.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 7
   5.   Namespace Considerations and Community Considerations  . . . . 7
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
   7.   Normative References . . . . . . . . . . . . . . . . . . . . . 7
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
        Intellectual Property and Copyright Statements . . . . . . . . 9

Rushing                  Expires May 1, 2006                    [Page 2]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

1.  Introduction

   Specification 1000D (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, 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,
   which makes the specification acceptable to the wider international
   community.

   Portions of S1000D define a resource coding system to allow 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 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

Rushing                  Expires May 1, 2006                    [Page 3]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

                      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 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 identifer
      ;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 decribed 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

Rushing                  Expires May 1, 2006                    [Page 4]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

      ;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:

Rushing                  Expires May 1, 2006                    [Page 5]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

      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 are 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

Rushing                  Expires May 1, 2006                    [Page 6]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

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 will need to be entered into the IANA
   registry of URN NIDs upon approval.
   (http://www.iana.org/assignments/urn-namespaces).

7.  Normative References

   [1]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [3]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
        BCP 66, RFC 3406, October 2002.

   [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [5]  "ASD Specification 1000D", May 2005.

Rushing                  Expires May 1, 2006                    [Page 7]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 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

Rushing                  Expires May 1, 2006                    [Page 8]
Internet-Draft   A URN Namespace for ASD Specification 1000D August 2005

Intellectual Property Statement

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Rushing                  Expires May 1, 2006                    [Page 9]