idnits 2.17.1 draft-lanthaler-profile-registry-05.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 (January 21, 2014) is 3748 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lanthaler 3 Internet-Draft January 21, 2014 4 Intended status: Informational 5 Expires: July 25, 2014 7 The Profile URI Registry 8 draft-lanthaler-profile-registry-05 10 Abstract 12 This document defines a registry for profile URIs to be used in 13 specifications standardizing profiles. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 25, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Registration Process . . . . . . . . . . . . . . . . . . . . . 3 51 3. Example Registration Request . . . . . . . . . . . . . . . . . 3 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. Initial Registry Contents . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6.1. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . . 5 57 6.2. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . . 5 58 6.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 6 59 6.4. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 6 60 6.5. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 Profiles, as defined by [RFC6906], can be used to signal support for 68 additional semantics, such as constraints, conventions, extensions, 69 or any other aspects that do not alter the basic media type 70 semantics. Profiles are identified by a URI and can thus be created 71 without central coordination. 73 Similarly to media types and link relation types it is, in some 74 cases, beneficial to centrally manage profile URIs to ensure 75 interoperability and decrease the coupling between clients and 76 servers. This allows the independent evolution of clients and 77 servers as both are coupled to these central contracts instead of 78 being coupled to each other. Therefore, this document establishes an 79 IANA registry for profile URIs. 81 2. Registration Process 83 All elements in this registry require a URI in order to be 84 registered. The meaning of the profile URI should be documented in a 85 permanent and readily available public specification in sufficient 86 detail so that interoperability between independent implementations 87 is possible (see the registration template in Section 4). 89 An exemplary registration request can be found in Section 3. 91 3. Example Registration Request 93 The following is an example registration request for the profile URI 94 http://example.com/profiles/example. 96 This is a request to IANA to please register the profile URI 97 "http://example.com/profiles/example" in the Profile URI Registry 98 according [this document]. 100 o Profile URI: http://example.com/profiles/example 102 o Common Name: Exemplary Profile URI 104 o Description: An exemplary profile URI registration. 106 o Specification Document: [this document] 108 4. IANA Considerations 110 This document establishes the Profile URI registry. The registration 111 procedure for new entries requires a request in the form of the 112 following template and is "First Come First Served" per [RFC5226]. 113 Instructions for a registrant to request the registration of a 114 profile URI are in Section 2. 116 The underlying registry data (e.g., the XML file) must include 117 Simplified BSD License text as described in Section 4.e of the Trust 118 Legal Provisions (). 120 The registration template is: 122 o Profile URI: The URI that identifies the registered profile. 124 o Common Name: The name by which the profile being registered is 125 generally known. 127 o Description: A relatively short description of the profile. For 128 simple profiles, this might be all the documentation that is 129 required and there might be no reference document. In those 130 cases, be sure this description adequately documents the profile 131 and is suitable for interoperable implementation. 133 o Specification Document: Reference to the document that specifies 134 the URI, preferably including a URI that can be used to retrieve a 135 copy of the document. An indication of the relevant sections may 136 also be included. This is recommended, but can be left blank if 137 the "Description" field provides sufficient documentation. 139 o Notes: [optional] 141 4.1. Initial Registry Contents 143 The Profile URI registry's initial contents are: 145 o Profile URI: urn:example:profile-uri 146 o Common Name: Exemplary Profile 147 o Description: A profile to be used in examples. 148 o Specification Document: [this document] 150 o Profile URI: http://dublincore.org/documents/2008/08/04/dc-html/ 151 o Common Name: Dublin Core HTML meta data profile 152 o Description: A set of conventions by which a Dublin Core metadata 153 description set can be can be represented within an (X)HTML Web 154 page using (X)HTML elements and attributes. 156 o Specification Document: [DC-HTML] 158 o Profile URI: http://www.w3.org/ns/json-ld#expanded 159 o Common Name: Expanded JSON-LD 160 o Description: A profile URI to request or signal expanded JSON-LD 161 document form. 162 o Specification Document: [JSON-LD] 164 o Profile URI: http://www.w3.org/ns/json-ld#compacted 165 o Common Name: Compacted JSON-LD 166 o Description: A profile URI to request or signal compacted JSON-LD 167 document form. 168 o Specification Document: [JSON-LD] 170 o Profile URI: http://www.w3.org/ns/json-ld#flattened 171 o Common Name: Flattened JSON-LD 172 o Description: A profile URI to request or signal flattened JSON-LD 173 document form. 174 o Specification Document: [JSON-LD] 176 5. Security Considerations 178 There are no additional security considerations beyond those already 179 inherent to using URIs. Security considerations for URIs in general 180 can be found in [RFC3986]. 182 6. Change Log 184 Note to RFC Editor: Please remove this section before publication. 186 6.1. From -04 to -05 188 o Change registration process from "Specification Required" to 189 "First Come First Served". 191 o Update JSON-LD reference. 193 o Update acknowledgements. 195 6.2. From -03 to -04 197 o Change title from "The IETF Profile URI Registry" to just "The 198 Profile URI Registry". 200 o Update JSON-LD reference. 202 6.3. From -02 to -03 204 o Seed registry with the profile URIs defined in [DC-HTML] and 205 [JSON-LD]. 207 6.4. From -01 to -02 209 o Do not establish a new IETF URN Sub-namespace anymore. 211 6.5. From -00 to -01 213 o Use HTTP URI instead of URN in example registration request to 214 make it clearer that not only URNs can be registered. 216 o Move security considerations to the end. 218 7. Acknowledgements 220 Thanks to Dave Cridland, Barry Leiba, and Nevil Brownlee for valuable 221 comments and suggestions. 223 8. Normative References 225 [DC-HTML] Johnston, P. and A. Powell, "Expressing Dublin Core 226 metadata using HTML/XHTML meta and link elements", Dublin 227 Core Metadata Initiative Recommendation, August 2008, 228 . 230 [JSON-LD] Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", 231 World Wide Web Consortium Recommendation, January 2014, 232 . 234 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 235 Resource Identifier (URI): Generic Syntax", STD 66, 236 RFC 3986, January 2005. 238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 240 May 2008. 242 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, 243 March 2013. 245 Author's Address 247 Markus Lanthaler 249 Email: mail@markus-lanthaler.com 250 URI: http://www.markus-lanthaler.com/