RFC 7284

The Profile URI Registry

📅 published June 2014, from ietf

The Profile URI Registry 🎀

okay bestie, this is the RFC that says how we keep a central list of profile URIs. 💖 It's an Independent Submission by Markus Lanthaler ✨, filed as Informational 🦋 in June 2014. The ISSN is 2070-1721. It doesn't list anything it obsoletes or updates in its title block. 💅

Independent Submission                                      M. Lanthaler
Request for Comments: 7284
Category: Informational                                        June 2014
ISSN: 2070-1721

Abstract 🌸

okay so the whole doc is about making a registry for profile URIs 📋 that people can use when they write specs for profiles. 🫶

Status of This Memo 💜

Real talk first: this is not an Internet Standards Track spec 🙈. It's just published for info. 📚

It's a contribution to the RFC Series, and it's independent of any other RFC stream 🌈. The RFC Editor picked to publish it at their discretion, and they make zero statements about whether it's good to implement or deploy 💀. Docs the RFC Editor approves are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 📖.

For the current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7284 🔗.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, bestie, because they explain your rights and restrictions for this doc 📜.

Table of Contents 🍓

1. Introduction ....................................................2
2. Registration Process ............................................2
3. Example Registration Request ....................................2
4. IANA Considerations .............................................3
   4.1. Initial Registry Contents ..................................4
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. Normative References ............................................5

1. Introduction ✨

okay so profiles, as defined by [RFC6906] 🦋, can signal extra semantics like constraints, conventions, extensions, or anything else that doesn't change the basic media type semantics 🌈. Profiles get identified by a URI, so anyone can make one up without asking a central authority 💅.

Here's the thing though: like media types and link relation types, it's sometimes super beneficial to manage profile URIs centrally 🔥. This keeps interop solid and lowers the coupling between clients and servers 🫶. It lets clients and servers evolve on their own because they're both tied to these central contracts, instead of being tied to each other 💖. So this doc sets up an IANA registry for profile URIs 📋.

2. Registration Process 🎀

every entry in this registry needs a URI to get registered 🔗. The meaning of the profile URI should be documented in a permanent, readily available public spec, with enough detail that independent implementations can actually interoperate 🧚. (Check out the registration template in Section 4 for the deets 📝.)

You can find an example registration request in Section 3 ✨.

3. Example Registration Request 🌸

Here's an example registration request for the profile URI http://example.com/profiles/example 🍓.

This is basically a request to IANA to register the profile URI "http://example.com/profiles/example" in the "Profile URIs" registry according to [RFC7284] 💜.

o  Profile URI: http://example.com/profiles/example

o  Common Name: My Profile

o  Description: An exemplary profile URI registration.

o  Reference: [the relevant specification]

4. IANA Considerations 👑

This doc sets up the "Profile URIs" registry 🎀. New entries need a request shaped like the template below, and the registration procedure is "First Come First Served" per [RFC5226] 💅. If a registrant wants to request a profile URI registration, the instructions are in Section 2 🦋.

The underlying registry data (for example, the XML file) must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions [TRUST] 📜.

The registration template goes like this 💖:

  • Profile URI: The URI that identifies the registered profile.
  • Common Name: The name by which the profile being registered is generally known.
  • Description: A relatively short description of the profile. For simple profiles, this might be all the documentation that is required, and there might be no reference document. In those cases, be sure this description adequately documents the profile and is suitable for interoperable implementation.
  • Reference: Reference to the document that specifies the URI, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included. This is recommended but can be left blank if the "Description" field provides sufficient documentation.
  • Notes: [optional]

4.1. Initial Registry Contents 🧚

Here's what the "Profile URIs" registry starts out with 🌈:

o  Profile URI: urn:example:profile-uri
o  Common Name: Exemplary Profile
o  Description: A profile to be used in examples, in accordance with
   [RFC6963].
o  Reference: [RFC7284]

o  Profile URI: http://dublincore.org/documents/2008/08/04/dc-html/
o  Common Name: Dublin Core HTML metadata profile
o  Description: A set of conventions by which a Dublin Core metadata
   description set can be can be represented within an (X)HTML web
   page using (X)HTML elements and attributes.
o  Reference: [DC-HTML]

o  Profile URI: http://www.w3.org/ns/json-ld#expanded
o  Common Name: Expanded JSON-LD
o  Description: A profile URI to request or signal expanded JSON-LD
   document form.
o  Reference: [JSON-LD]

o  Profile URI: http://www.w3.org/ns/json-ld#compacted
o  Common Name: Compacted JSON-LD
o  Description: A profile URI to request or signal compacted JSON-LD
   document form.
o  Reference: [JSON-LD]

o  Profile URI: http://www.w3.org/ns/json-ld#flattened
o  Common Name: Flattened JSON-LD
o  Description: A profile URI to request or signal flattened JSON-LD
   document form.
o  Reference: [JSON-LD]

5. Security Considerations 🔥

Honestly, there are no extra security considerations beyond the ones already baked into using URIs 🙈. If you want the general security stuff for URIs, check out [RFC3986] 🔐.

6. Acknowledgements 💜

Huge thanks to Dave Cridland, Barry Leiba, Nevil Brownlee, and Peter Saint-Andre for their valuable comments and suggestions 🫶✨.

7. Normative References 📚

[DC-HTML]  Johnston, P. and A. Powell, "Expressing Dublin Core
           metadata using HTML/XHTML meta and link elements", Dublin
           Core Metadata Initiative Recommendation, August 2008,
           <http://dublincore.org/documents/2008/08/04/dc-html/>.

[JSON-LD]  Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0",
           World Wide Web Consortium Recommendation, January 2014,
           <http://www.w3.org/TR/json-ld/>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66, RFC
           3986, January 2005.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC6906]  Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
           March 2013.

[RFC6963]  Saint-Andre, P., "A Uniform Resource Name (URN) Namespace
           for Examples", BCP 183, RFC 6963, May 2013.

[TRUST]    IETF, "Trust Legal Provisions (TLP)",
           <http://trustee.ietf.org/license-info>.

Author's Address 🦋

Markus Lanthaler 💖

EMail: mail@markus-lanthaler.com
URI:   http://www.markus-lanthaler.com/
📦 where this page comes from