Skip to main content

Maritime Resource Names (MRN)
draft-knielsen-mrn-urn-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Kasper Nielsen
Last updated 2017-06-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-knielsen-mrn-urn-01
Network Working Group                                         K. Nielsen
Internet-Draft                                 Danish Maritime Authority
Intended status: Informational                             June 13, 2017
Expires: December 15, 2017

                     Maritime Resource Names (MRN)
                       draft-knielsen-mrn-urn-01

Abstract

   This document describes a Uniform Resource Name (URN) namespace
   intended for persistently and uniquely naming maritime resources.
   published by the International Association of Lighthouse Authorities
   (IALA AISM).

Status of This Memo

   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 December 15, 2017.

Copyright Notice

   Copyright (c) 2017 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.

Nielsen                 Expires December 15, 2017               [Page 1]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

Table of Contents

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

1.  Introduction

   IALA is a non-profit, international technical association founded in
   1957.  It gathers together marine aids to navigation authorities,
   manufacturers, consultants, and, scientific and training institutes
   from all parts of the world and offers them the opportunity to
   exchange and compare their experiences and achievements.

   Although a lot of standardized identifier schemes for vessels, buoys,
   mariners and other maritime resources already exist in the maritime
   world.  There is no single system that allows people to specify such
   an identifier in a uniform and unambiguous way.    We believe that it
   makes sense to introduce a naming scheme that can uniquely identify
   any maritime resource on a global scale.  By maritime resource we
   more or less
   mean anything that has an identity of some kind.  This could be
   organizations, employees, a person, a physical or a virtual object,
   for instance an electronic document, a buoy, a ship, a mariner, a
   nautical chart or an electronic service (e.g., "today's weather
   report for the Oresund Strait").  Not all resources are "retrievable"
   in an electronic sense; For example, human beings, corporations, and
   buoys.  However, they can still be considered a resource.

   It is our opinion that having such a naming scheme will facilitate
   innovation, integration, trade, safety, and security in the maritime
   sector, by paving the way for new kind of maritime digital
   information services.

   This document defines such a standard naming system, based on Uniform
   Resource Names (URNs).

2.  Specification Template

   Namespace ID

      "mrn"

Nielsen                 Expires December 15, 2017               [Page 2]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

   Registration Information

         Registration version number: 1

         Registration date: 2017-xx-xx

   Declared Registrant of the Namespace

      Registering organization:

         International Association of Lighthouse Authorities (IALA)

         10 rue des Gaudines

         78100

         St Germain en Laye

         France

         Email: contact@iala-aism.org

      Designated Contact:

         International Association of Lighthouse Authorities (IALA)

         Email: info@mrnregistry.org

         <http://www.mrnregistry.org/>

   Declaration of structure:

Nielsen                 Expires December 15, 2017               [Page 3]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

   The Namespace Specific String (NSS) of all URNs that use the
   "mrn" NID shall have the following structure:

   <URN>   ::= "urn:mrn:" <OID> ":" <OSS>

   <OID>   ::= 1*(ALPHA / DIGIT) ; Organizational ID

   <OSS>   ::= <OSNID> ":" <OSNS> ; Organizational specific string

   <OSNID> ::= 1*(ALPHA / DIGIT / "-")
               ; Organizational specific namespace ID

   <OSNS>  ::= 1*<URN chars> ; Organizational specific namespace string

   DIGIT   ::= %x30-39 ; 0-9

   ALPHA   ::= %x61-7A ; a-z

   Basics of the ABNF notation used :

    " " literals (terminal character strings); terms not in quotes are
        non-terminals

    /   alternatives

    ()  indicates a sequence group, used as a single alternative or as a
        single repeating group

    <a>*<b>  indicates that the following term or group can repeat at
             least <a> and at most <b> times; default values are 0 and
           infinity, respectively

    ;   comment

    <URN chars>  As defined in [@!RFC2141]

   Relevant ancillary documentation:

      The process for assigning unique organizational IDs is managed by
      IALA.  Details and application process can be found at
      <http://www.mrnregistry.org>.

   Identifier uniqueness considerations:

      Guaranteeing uniqueness is a two-way process.  First, IALA will
      guarantee that each organization will be assigned a unique
      organizational id that will never be reused.  Second, each

Nielsen                 Expires December 15, 2017               [Page 4]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

      organization must guarantee that they do not assign identical
      organizational specific strings (OSS).

   Identifier persistence considerations:

      Each individual organization must guarantee that assigned URNs
      will not be reused and will remain valid beyond the lifecycle of
      the referenced resources.  However, it should be noted that
      although the URNs remain valid, the status of the referenced
      resource may change.

   Process of identifier assignment:

      While the assignment of OIDs for each organization is managed by
      IALA.  The assignment of organization specific namespace ids and
      strings are fully managed by each individual organization.

   Process of identifier resolution:

      There are no plans to provide a general available resolution
      mechanism.  However, organizations are free to setup resolution
      servers for all or part of the URNs assigned under their
      organizational id.

   Rules for Lexical Equivalence:

      The entire URN is case insensitive.

   Conformity with URN syntax:

      There are no additional characters reserved except as noted in the
      ABNF above.

   Validation mechanism:

      In the case of each sub-namespace, there will be namespace-
      specific rules for determining validity.  There are no plans to
      provide a central repository for these rules.

   Scope:

      Global.

3.  Examples

   All the examples provided in the following section are hypothetical
   examples.  Real world naming schemes will most likely look different.

Nielsen                 Expires December 15, 2017               [Page 5]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

   Using the MRN identifier scheme a vessel with an IMO number of
   9743368 could be identified as follows:

      urn:mrn:imo:imo-number:9743368

   The governing organization of how to assign IMO numbers is the
   International Maritime Organization (IMO).  IMO may have delegated
   the actual assignment of numbers to another organization.  But IMO is
   still the organization who has determined that an IMO number is an
   unique seven-digit number.  Within the context of maritime resource
   names the organizational id (OID) refers to the organization who
   governs the syntax and rules of a particular resource type.  In the
   above case the organizational ID is "imo".

   Each organization further divides the organizational specific string
   (OSS), which is the part following "imo", into two parts.  An
   organizational specific namespace ID (OSNID) which is a unique
   identifier within the governing organization for a particular type of
   resource.  In this example, we have used "imo-number" but it could
   just as well have been "imonumber" or just "number".

   The second part is the organizational specific namespace string
   (OSNS).  Which is the only part that differs for resources of the
   same type, in this case it is "9743368".  The organizational specific
   namespace string is (as the name implies) specific for a combination
   of a OID and OSNID.  In this case the organizational specific
   namespace string is always a 7 digit IMO number.

   Another way to identify the same vessel might be to use its MMSI
   number.  Here the identifier could look like this:

      urn:mrn:itu:mmsi:538070999

   In this case ITU is the governing body because MMSI numbers are based
   on recommendation M.585 from ITU.  It might be that national bodies
   does the actual assignment of MMSI numbers, but ITU is the governing
   body for the standardization of MMSI numbers.

   As can be seen from these two examples.  The same vessel can be
   identified by multiple different identifiers.  This is no different
   to a person who might be identified either by his driver license
   number or his social security id.  Multiple identities can identify
   the same entity.  Some parameters frequently used for identification,
   such as 'names of people', do most of the time qualify as
   identifiers, as they are not guaranteed to be unique.  A single
   identifier must refer to one and only one identity.

Nielsen                 Expires December 15, 2017               [Page 6]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

   The concept of URNs can be taken from a very coarse grained level to
   a very fine grained level.  For example, a container ship might be
   identified by one of the two previous URL's.  The containers aboard
   the ship might be identified with an URN adapting the ISO 6346
   identifier scheme for container ids.

      urn:mrn:bic:container-id:csqu3054383

   Finally, individual items in a single container might be identified
   by another URN scheme.  It might even be possible to integrate with
   URNs defined outside of the urn:mrn namespace.  For example, all
   items in a container might be identified by an electronic product
   code ([RFC5134]).  In other words, the usage of URNs as identifiers
   are not limited to those defined within this document.  In the future
   other non-maritime sectors might even adopt similar naming schemes
   based on URNs to facilitate easier integration across sector
   boundaries.

   An identifier does not need to be a physical object, but can be a
   virtual item such as an electronic document.  For example, IMO might
   decide that all of their documents would use a "publications" prefix.
   So

      urn:mrn:imo:publications:if110s

   would refer to the publication "IMO SOLAS Consolidated Spanish
   Edition, 2014 IF110S"

   On the other hand an organization such as IALA might decide that all
   of their publications would follow another format where the category
   of the publication is included in the identifier.  For example, a
   recommendation could be

      urn:mrn:iala:publications:recommendation:e-nav-140

   while the identifier of a guideline might be written as

      urn:mrn:iala:publications:guideline:synchronisation-of-lights-1069

   As can be seen from the previous example the Organizational specific
   namespace string can be split into multiple hierarchies.  It is all
   up to the governing organization how they want to structure their
   identifiers.

   Another example of identifiers with multiple hierarchies could be an
   identifier scheme for lights and buoys.  Here IALA could choose to
   let the OSNS consist of <CountryCode>:<National Identifier>.  For
   example

Nielsen                 Expires December 15, 2017               [Page 7]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

      urn:mrn:iala:aton:us:1234x5

   There are no requirements that organizations are permanent entities.
   For example, the European STM Validation project could choose to use
   "stm" as their organizational id.  So, for example, a voyage id in
   this project might look like

      urn:mrn:stm:voyage:id:xcus231230

   Internally in the project they can use xcus231230 to refer to a
   voyage plan.  But when working with external systems or other
   projects the full URN can be used in case other projects uses another
   type of identifier for a particular voyage.

   As can be seen from all these examples.  The scheme is highly
   adaptable.  Each organization can choose their own layout for a
   specific type of identifiers.  It is easy to fit existing identifiers
   into the naming scheme.  And it provides good context information
   about the type of the identifier in comparison to something simple
   like a random UUID.

4.  Namespace Considerations

   IALA traditionally addresses the maritime community, but its
   resources are made available to all interested parties.  While URN
   namespaces may exist for which any generic naming system can be
   encoded.  Is is the goal of IALA to foster a community around
   maritime resource names within the global maritime community.
   Therefore, the possibility of binding to various other namespace
   repositories have been deemed impractical.

5.  Community Considerations

   Members of the IALA community will benefit from persistent and
   globally unique identifiers for use in software and in conformance
   with protocols developed and used by IALA and third-party
   collaborators.

   While in general organizations will be free to structure their
   organization specific namespace in any way they see fit (as long as
   they guarantee uniqueness and persistence).  It is our intention to
   provide general guidelines and best practices in the future.  For
   example, encouraging that every organization use "publications" as
   the organization specific namespace id for referring to official
   publications from them.  Or that every identifier that refers to a
   country uses standards available in ISO 3166 for the representation
   of names of countries and their subdivisions.

Nielsen                 Expires December 15, 2017               [Page 8]
Internet-Draft        Maritime Resource Names (MRN)            June 2017

6.  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].

7.  IANA Considerations

   This document defines a URN NID registration that is to be entered
   into the IANA registry of URN NIDs.  It specifically requests the MRN
   NID.

8.  Normative References

   [RFC1737]  Sollins, K. and L. Masinter, "Functional Requirements for
              Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737,
              December 1994, <http://www.rfc-editor.org/info/rfc1737>.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
              May 1997, <http://www.rfc-editor.org/info/rfc2141>.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
              <http://www.rfc-editor.org/info/rfc3406>.

   [RFC5134]  Mealling, M., "A Uniform Resource Name Namespace for the
              EPCglobal Electronic Product Code (EPC) and Related
              Standards", RFC 5134, DOI 10.17487/RFC5134, January 2008,
              <http://www.rfc-editor.org/info/rfc5134>.

Author's Address

   Kasper Nielsen
   Danish Maritime Authority
   Carl Jacobsens Vej 31
   2500 Valby
   Denmark

   Email: kasperni@gmail.com

Nielsen                 Expires December 15, 2017               [Page 9]