idnits 2.17.1
draft-knielsen-mrn-urn-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 26, 2017) is 2616 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Nielsen
3 Internet-Draft Danish Maritime Authority
4 Intended status: Informational February 26, 2017
5 Expires: August 30, 2017
7 Maritime Resource Names (MRN)
8 draft-knielsen-mrn-urn-00
10 Abstract
12 This document describes a Uniform Resource Name (URN) namespace
13 intended for persistently and uniquely naming maritime resources.
14 published by the International Association of Lighthouse Authorities
15 (IALA AISM).
17 Status of This Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on August 30, 2017.
34 Copyright Notice
36 Copyright (c) 2017 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Specification Template . . . . . . . . . . . . . . . . . . . 2
53 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
54 4. Namespace Considerations . . . . . . . . . . . . . . . . . . 8
55 5. Community Considerations . . . . . . . . . . . . . . . . . . 8
56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
58 8. Normative References . . . . . . . . . . . . . . . . . . . . 9
59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
61 1. Introduction
63 IALA is a non-profit, international technical association founded in
64 1957. It gathers together marine aids to navigation authorities,
65 manufacturers, consultants, and, scientific and training institutes
66 from all parts of the world and offers them the opportunity to
67 exchange and compare their experiences and achievements.
69 Although a lot of standardized identifier schemes for vessels, buoys,
70 mariners and other maritime resources already exist in the maritime
71 world. There is no single system that allows people to specify such
72 an identifier in a uniform and unambiguous way. We believe that it
73 makes sense to introduce a naming scheme that can uniquely identify
74 any maritime resource on a global scale. By maritime resource we
75 more or less
76 mean anything that has an identity of some kind. This could be
77 organizations, employees, a person, a physical or a virtual object,
78 for instance an electronic document, a buoy, a ship, a mariner, a
79 nautical chart or an electronic service (e.g., "today's weather
80 report for the Oresund Strait"). Not all resources are "retrievable"
81 in an electronic sense; For example, human beings, corporations, and
82 buoys. However, they can still be considered a resource.
84 It is our opinion that having such a naming scheme will facilitate
85 innovation, integration, trade, safety, and security in the maritime
86 sector, by paving the way for new kind of maritime digital
87 information services.
89 This document defines such a standard naming system, based on Uniform
90 Resource Names (URNs).
92 2. Specification Template
94 Namespace ID
96 "mrn"
98 Registration Information
100 Registration version number: 1
102 Registration date: 2017-xx-xx
104 Declared Registrant of the Namespace
106 Registering organization:
108 International Association of Lighthouse Authorities (IALA)
110 10 rue des Gaudines
112 78100
114 St Germain en Laye
116 France
118 Email: contact@iala-aism.org
120 Designated Contact:
122 International Association of Lighthouse Authorities (IALA)
124 Email: info@mrnregistry.org
126
128 Declaration of structure:
130 The Namespace Specific String (NSS) of all URNs that use the
131 "mrn" NID shall have the following structure:
133 ::= "urn:mrn:" ":"
135 ::= 1*(ALPHA / DIGIT) ; Organizational ID
137 ::= ":" ; Organizational specific string
139 ::= 1*(ALPHA / DIGIT / "-")
140 ; Organizational specific namespace ID
142 ::= 1* ; Organizational specific namespace string
144 DIGIT ::= %x30-39 ; 0-9
146 ALPHA ::= %x61-7A ; a-z
148 Basics of the ABNF notation used :
150 " " literals (terminal character strings); terms not in quotes are
151 non-terminals
153 / alternatives
155 () indicates a sequence group, used as a single alternative or as a
156 single repeating group
158 * indicates that the following term or group can repeat at
159 least and at most times; default values are 0 and
160 infinity, respectively
162 ; comment
164 As defined in [@!RFC2141]
166 Relevant ancillary documentation:
168 The process for assigning unique organizational IDs is managed by
169 IALA. Details and application process can be found at
170 .
172 Identifier uniqueness considerations:
174 Guaranteeing uniqueness is a two-way process. First, IALA will
175 guarantee that each organization will be assigned a unique
176 organizational id that will never be reused. Second, each
177 organization must guarantee that they do not assign identical
178 organizational specific strings (OSS).
180 Identifier persistence considerations:
182 Each individual organization must guarantee that assigned URNs
183 will not be reused and will remain valid beyond the lifecycle of
184 the referenced resources. However, it should be noted that
185 although the URNs remain valid, the status of the referenced
186 resource may change.
188 Process of identifier assignment:
190 While the assignment of OIDs for each organization is managed by
191 IALA. The assignment of organization specific namespace ids and
192 strings are fully managed by each individual organization.
194 Process of identifier resolution:
196 There are no plans to provide a general available resolution
197 mechanism. However, organizations are free to setup resolution
198 servers for all or part of the URNs assigned under their
199 organizational id.
201 Rules for Lexical Equivalence:
203 The entire URN is case insensitive.
205 Conformity with URN syntax:
207 There are no additional characters reserved except as noted in the
208 ABNF above.
210 Validation mechanism:
212 In the case of each sub-namespace, there will be namespace-
213 specific rules for determining validity. There are no plans to
214 provide a central repository for these rules.
216 Scope:
218 Global.
220 3. Examples
222 All the examples provided in the following section are hypothetical
223 examples. Real world naming schemes will most likely look different.
225 Using the MRN identifier scheme a vessel with an IMO number of
226 9743368 could be identified as follows:
228 urn:mrn:imo:imo-number:9743368
230 The governing organization of how to assign IMO numbers is the
231 International Maritime Organization (IMO). IMO may have delegated
232 the actual assignment of numbers to another organization. But IMO is
233 still the organization who has determined that an IMO number is an
234 unique seven-digit number. Within the context of maritime resource
235 names the organizational id (OID) refers to the organization who
236 governs the syntax and rules of a particular resource type. In the
237 above case the organizational ID is "imo".
239 Each organization further divides the organizational specific string
240 (OSS), which is the part following "imo", into two parts. An
241 organizational specific namespace ID (OSNID) which is a unique
242 identifier within the governing organization for a particular type of
243 resource. In this example, we have used "imo-number" but it could
244 just as well have been "imonumber" or just "number".
246 The second part is the organizational specific namespace string
247 (OSNS). Which is the only part that differs for resources of the
248 same type, in this case it is "9743368". The organizational specific
249 namespace string is (as the name implies) specific for a combination
250 of a OID and OSNID. In this case the organizational specific
251 namespace string is always a 7 digit IMO number.
253 Another way to identify the same vessel might be to use its MMSI
254 number. Here the identifier could look like this:
256 urn:mrn:itu:mmsi:538070999
258 In this case ITU is the governing body because MMSI numbers are based
259 on recommendation M.585 from ITU. It might be that national bodies
260 does the actual assignment of MMSI numbers, but ITU is the governing
261 body for the standardization of MMSI numbers.
263 As can be seen from these two examples. The same vessel can be
264 identified by multiple different identifiers. This is no different
265 to a person who might be identified either by his driver license
266 number or his social security id. Multiple identities can identify
267 the same entity. Some parameters frequently used for identification,
268 such as 'names of people', do most of the time qualify as
269 identifiers, as they are not guaranteed to be unique. A single
270 identifier must refer to one and only one identity.
272 The concept of URNs can be taken from a very coarse grained level to
273 a very fine grained level. For example, a container ship might be
274 identified by one of the two previous URL's. The containers aboard
275 the ship might be identified with an URN adapting the ISO 6346
276 identifier scheme for container ids.
278 urn:mrn:bic:container-id:csqu3054383
280 Finally, individual items in a single container might be identified
281 by another URN scheme. It might even be possible to integrate with
282 URNs defined outside of the urn:mrn namespace. For example, all
283 items in a container might be identified by an electronic product
284 code ([RFC5134]). In other words, the usage of URNs as identifiers
285 are not limited to those defined within this document. In the future
286 other non-maritime sectors might even adopt similar naming schemes
287 based on URNs to facilitate easier integration across sector
288 boundaries.
290 An identifier does not need to be a physical object, but can be a
291 virtual item such as an electronic document. For example, IMO might
292 decide that all of their documents would use a "publications" prefix.
293 So
295 urn:mrn:imo:publications:if110s
297 would refer to the publication "IMO SOLAS Consolidated Spanish
298 Edition, 2014 IF110S"
300 On the other hand an organization such as IALA might decide that all
301 of their publications would follow another format where the category
302 of the publication is included in the identifier. For example, a
303 recommendation could be
305 urn:mrn:iala:publications:recommendation:e-nav-140
307 while the identifier of a guideline might be written as
309 urn:mrn:iala:publications:guideline:synchronisation-of-lights-1069
311 As can be seen from the previous example the Organizational specific
312 namespace string can be split into multiple hierarchies. It is all
313 up to the governing organization how they want to structure their
314 identifiers.
316 Another example of identifiers with multiple hierarchies could be an
317 identifier scheme for lights and buoys. Here IALA could choose to
318 let the OSNS consist of :. For
319 example
320 urn:mrn:iala:aton:us:1234x5
322 There are no requirements that organizations are permanent entities.
323 For example, the European STM Validation project could choose to use
324 "stm" as their organizational id. So, for example, a voyage id in
325 this project might look like
327 urn:mrn:stm:voyage:id:xcus231230
329 Internally in the project they can use xcus231230 to refer to a
330 voyage plan. But when working with external systems or other
331 projects the full URN can be used in case other projects uses another
332 type of identifier for a particular voyage.
334 As can be seen from all these examples. The scheme is highly
335 adaptable. Each organization can choose their own layout for a
336 specific type of identifiers. It is easy to fit existing identifiers
337 into the naming scheme. And it provides good context information
338 about the type of the identifier in comparison to something simple
339 like a random UUID.
341 4. Namespace Considerations
343 IALA traditionally addresses the maritime community, but its
344 resources are made available to all interested parties. While URN
345 namespaces may exist for which any generic naming system can be
346 encoded. Is is the goal of IALA to foster a community around
347 maritime resource names within the global maritime community.
348 Therefore, the possibility of binding to various other namespace
349 repositories have been deemed impractical.
351 5. Community Considerations
353 Members of the IALA community will benefit from persistent and
354 globally unique identifiers for use in software and in conformance
355 with protocols developed and used by IALA and third-party
356 collaborators.
358 While in general organizations will be free to structure their
359 organization specific namespace in any way they see fit (as long as
360 they guarantee uniqueness and persistence). It is our intention to
361 provide general guidelines and best practices in the future. For
362 example, encouraging that every organization use "publications" as
363 the organization specific namespace id for referring to official
364 publications from them. Or that every identifier that refers to a
365 country uses standards available in ISO 3166 for the representation
366 of names of countries and their subdivisions.
368 6. Security Considerations
370 There are no additional security considerations other than those
371 normally associated with the use and resolution of URNs in general,
372 which are described in [RFC1737], [RFC2141], and [RFC3406].
374 7. IANA Considerations
376 This document defines a URN NID registration that is to be entered
377 into the IANA registry of URN NIDs. It specifically requests the MRN
378 NID.
380 8. Normative References
382 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
383 Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737,
384 December 1994, .
386 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
387 May 1997, .
389 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
390 "Uniform Resource Names (URN) Namespace Definition
391 Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406,
392 October 2002, .
394 [RFC5134] Mealling, M., "A Uniform Resource Name Namespace for the
395 EPCglobal Electronic Product Code (EPC) and Related
396 Standards", RFC 5134, DOI 10.17487/RFC5134, January 2008,
397 .
399 Author's Address
401 Kasper Nielsen
402 Danish Maritime Authority
403 Carl Jacobsens Vej 31
404 2500 Valby
405 Denmark
407 Email: kasperni@gmail.com