Network Working Group C. ReedInternet-DraftRequest for Comments: 5165 Open Geospatial ConsortiumExpires: April 15,Category: Informational March 2008October 16, 2007A Uniform Resource Name (URN)namespaceNamespace for the Open Geospatial Consortium (OGC)draft-creed-ogc-urn-03.txtStatus ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007).this memo is unlimited. Abstract This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". 1. Introduction The Open Geospatial Consortium (OGC) is a voluntary consensus standards organization. Founded in 1994, the OGC produces many kinds of technical documents, including: standards, working drafts, technical reports, discussion papers, and XML schemas. The OGC wishes to provide persistent, location-independent Identifiers for these resources. Further, a number of OGC standards and application schemas of OGC standards are now used and/or referenced by standards specifications from other standards organizations, including OASIS, the IETF, IEEE, ISO, and OMA. The OGC core mission is to develop spatial interface and encoding specifications that are openly available and royalty free. Products and services that conform to OGC interface specifications enable users to freely exchange and process spatial information across networks, computing platforms, and products. Interoperability in such an environment is facilitated by the use of a system of persistent identifiers that are global in scope. The OGC is the only standards organization whose mission is specifically focused in interfaces and encodings for geospatial content and services. Motivated by these concerns, the OGC would like to assign formal URNs to published resources in order to provide persistent,location-independentlocation- independent identifiers for them. The process for registering a namespace identifier is documented in RFC 3406 [2]. The official IANA registry of URN namespaces is available online: <http://www.iana.org/assignments/urn-namespaces>. 2. URN Specification for "ogc" NID Namespace ID:The NID "ogc" is requested.ogc Registration Information: Registration Version Number: 1 Registration Date: 2007-08-16 Declared registrant of the namespace: Open Geospatial Consortium, Inc. (Headquarters) 35 Main Street, Suite 5 Wayland, MA 01778-5037, USA c/o Carl Reed (creed@opengeospatial.org) Declaration of syntactic structure: The Namespace Specific String (NSS) of all URNs that use the "ogc" NID will have the following structure: urn:ogc:{OGCresource}:{ResourceSpecificString} where the "OGCresource" is a US-ASCII string that conforms to the URN syntax requirements[RFC2141][1] and defines a specific class of resource type. Each resource type has a specific labeling scheme that is covered by "ResourceSpecificString", which also conforms to the naming requirements of[RFC2141].[1]. The only exception is that the character ":" shall not be used as part of the"OGCResource""OGCresource" string. This is to avoid possible confusion. Further,"OGCResource"OGCresource" is case sensitive. The OGC maintains a naming authority, the OGC Naming Authority (ONA), that will manage the assignment of "OGCresources" and the specific registration values assigned for each resourceclassclass. Relevant ancillary documentation: The OGC Naming Authority (ONA) provides information on the registered resources and the registrations for each. More information aboutONA andONA, the registrationactivitiesactivities, and procedures to be followed are available at:https://portal.opengeospatial.org/wiki/twiki/bin/view/Member/OGCUrnIntrohttps://portal.opengeospatial.org/wiki/twiki/bin/view/ Member/OGCUrnIntro An operational OGC URN "resolver" is available at http://urn.opengis.net/. The resolver provides a registry of the currently member approved OGC URN's used in currently approved and implemented OGC standards. The OGC Naming Authority is a permanent OGC resource. The documents and related OGC URN resources, such as the URN resolver,willhave stable URLs. The ONA reference is http://www.opengeospatial.org/ogcna. There are a number of OGC Best Practice and Standards documents that define member agreements on the definitions forOGCresource"OGCresource" and ResourceSpecificString. Identifier uniqueness considerations: The ONA manages resources using the "ogc" NID and will be the authority for managing the resources and subsequent strings associated. In the associated procedures, ONA will ensure the uniqueness of the strings themselves or shall permit secondary responsibility for the management of well-defined sub-trees. The OGC may permit the use of experimental type values that will not be registered. As a consequence, multiple users may end up using the same value for separate uses. As experimental usage is only intended for testing purposes, this should not be a real issue. Identifier persistence considerations: The OGC provides clear documentation on a number of the registered uses of the "ogc" NID. Additional uses developed by the OGC membership in the future will be first approved by the ONA and then by the entire OGC voting membership. This is the normal process for all OGC documents that become OGC standards or other permanent resources for use by the community. The OGC Naming Authority maintains a permanent registry of approved uses. This resource is structured such that eachOGCresource"OGCresource" has a separate description and registration table. The registration tables and information are published and maintained by the ONA on the OGC web site. Process of identifier assignment: The ONA uses the approved OGC standards policies and procedures for discussion,approvalapproval, and registration of each type of resource maintained [3]. Each such resource may have three types of registration activities: 1) Registered values associated with OGC specs or services 2) Registration of values or sub-trees to other entities 3) Name models for use in experimental purposes Process for identifier resolution: The namespace is not listed with a Resolution Discovery System (RDS); this is not relevant. Rules for Lexical Equivalence: No special considerations except as noted in the declaration of syntactic structure; the rules for lexical equivalence of[RFC 2141][1] apply. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. URN assignment will be handled by procedures implemented in support of ONA activities. Scope: Global 3. Examples The following examples are representativeurnsURNs that have been assigned by the ONA. urn:ogc:specification:gml:doc-is(02-023r4):3.0.0 Defines theurnURN to be used to identify version 3.0.0 of an OGC specification document for the Geography Markup Language in the OGC document archives. urn:ogc:serviceType:CatalogueService:2.0.2:HTTP Defines theurnURN to be used for an application to specify the specific service type for an OGC Catalogue service. urn:ogc:def:crs:EPSG:6.3:26986IsThis is the URNdefinedliteral to reference the definition of the Coordinate Reference System (CRS) with code 26986 that is specified in version 6.3 of the EPSG database [4].44. NamespaceConsiderations:Considerations There is currently no available namespace that will allow the OGC to uniquely specify and access resources, such as schemas and registries, that are required by organizations implementing OGC standards. There is also a need for other standards organizations, such as OASIS and the IETF, to be able to access OGC specific resources. The geospatial and location services industry will benefit from the publication of this namespace by having more permanent and reliable names for the XML namespaces, schema locations, standards document reference, and other document artifacts required for implementation of an OGC standard. The OGC members considered the use of other existing NIDs, such as those for OASIS and OMA. However, the semantics for geospatial content and services have a number of unique characteristics, such as the expression of coordinate reference systems. The URN syntax used by OASIS and OMA do not support the necessary elements to express the full semantics used in and by the geospatial community.55. Community Considerations Both the traditional geospatial and location services industry as well as the broader IT community will benefit from the publication of this namespace by providing permanent and reliable names for the XML namespaces, schema locations, catalogues registries, and other document artifacts required for implementation of an OGC standard. We desire these resources to be freely and openly available as a set of community resources. Not only can OGC members identify and submit new proposals for additionalresources. So canresources, but any individual or organization can make a contribution by submitting a proposal to the OGC for consideration by the ONA. Normal OGC standards discussion and approval processes will be used to process any new community contribution. Since 2003, the OGC membership has been developing expertise in using the OGC URN. The knowledge and experience gained through implementation experiments and a variety of operational test beds contributed to the current OGC URN specification. The knowledge is documented in OGC documents (above) as well as an operational OGC URN resolver. Work is also underway on a publicly accessible OGC URN registry. These resources are necessary for a number of reasons, including the fact that numerous agencies andorganization,organizations, such as NATO and NGA, have mandated a procurement policy thatrequiringrequires OGC standards and their related OGC URNs. 6. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. 7. IANA Considerations This document defines a URN NID registration of "ogc", which has been entered into the IANA registry located at <http://www.iana.org/assignments/urn-namespaces>. 8. Normative References [1] Moats, R., "URN Syntax", RFC 2141, May 1997.Available [online]: <http://www.ietf.org/rfc/rfc2141.txt>[2] Daigle,L. et al.,L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.Available [online]: http://www.ietf.org/rfc/rfc3406.txt[3] OGC Technical Committee Policies and Procedures, Version 3, October 1, 2007. Available[online]:(online): https://portal.opengeospatial.org/files/?artifact_id=12586 [4] "Definition identifier URNs in OGC namespace" Version 1.1 Arliss Whiteside, An OGC Best Practices, August 2006. Available[online]:(online): http://portal.opengeospatial.org/files/?artifact_id=16339 Author Address Carl Reed, PhD Chief Technology Officer Open Geospatial Consortium, Inc. 35 Main Street, Suite 5 Wayland, MA 01778-5037, USAEmail:EMail: creed@opengeospatial.org Full Copyright Statement Copyright (C) The IETF Trust(2007).(2008). 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. 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, THE IETF TRUST 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 ORFITNNESSFITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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.Acknowledgement(s) Thanks to Jon Peterson, Leslie Daigle, Allison Mankin, Simon Cox, Clemens Portele, Doug Nebert, Steven Keens, Josh Lieberman and Arliss Whiteside for their review and comments. Thanks to Ted Hardie Brian Rosen, Allison Mankin, and Lisa Dusseault for helping me with the IETF document process. Thanks to Peter Saint-Andre, Stefan Santesson, Alfred Hines, and Joel Halpern for their reviews of the document.