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