RFC 6906

The 'profile' Link Relation Type

📅 published March 2013, from ietf

okay bestie, here are the basics 💅

  • RFC number: 6906
  • Title: The 'profile' Link Relation Type
  • Author: E. Wilde, EMC Corporation
  • Category: Informational (published for information, not as an Internet Standard) 📚
  • Date: March 2013
  • Stream: Independent Submission
  • ISSN: 2070-1721
  • Obsoletes / Updates: neither is listed in the header, so this doc doesn't replace or update anything 🙅‍♀️

Abstract ✨

so this spec defines the 'profile' link relation type 🦋 which lets resource representations say "hey, I'm following one or more profiles" 💖 A profile is defined to not change the semantics of the representation itself. Instead it lets clients learn about extra semantics (constraints, conventions, extensions) tied to that representation, on top of what the media type and maybe other mechanisms already say 🧚

Status of This Memo 📝

This document is not an Internet Standards Track specification; it is published for informational purposes. 🌸

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor chose to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. 💅

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6906. 🔍

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 🫶

Table of Contents 🗂️

1. Introduction ....................................................2
2. Terminology .....................................................3
3. Profiles ........................................................3
   3.1. Profiles and Media Types ...................................4
   3.2. Profile Context ............................................5
4. IANA Considerations .............................................5
5. Examples ........................................................6
   5.1. hCard ......................................................6
   5.2. Dublin Core ................................................6
   5.3. Podcasts ...................................................7
6. Security Considerations .........................................7
7. Acknowledgements ................................................7
8. References ......................................................7
   8.1. Normative References .......................................7
   8.2. Informative References .....................................7

1. Introduction 🌷

okay so the foundation of the Internet and web is that resource representations (sent over stuff like SMTP or HTTP) get labeled with a 'media type' 🏷️ That's how a client knows at run time what kind of representation it's handling, which is so iconic. Sometimes though, it would be super useful for servers and clients to share extra info about what the resource is. A client that understands that extra info could react in a special way for that specialization. That specialization could be about constraints, conventions, extensions, or anything else that doesn't change the basic media type semantics 🎀

HTML 4 [HTML401] already has this built in as the 'profile' attribute of the 'head' element. The catch is that it only works for HTML, and as of writing it looked like HTML 5 was going to drop it completely 💀

RFC 5988 [RFC5988] "defines a framework for typed links that isn't specific to a particular serialisation or application. It does so by redefining the link relation registry established by Atom to have a broader domain, and adding to it the relations that are defined by HTML." ✨

This spec registers a 'profile' link relation type under the rules of RFC 5988 [RFC5988]. Links with this relation type can show up in representations that support typed links, and also in HTTP Link headers 🦋 The profile link relation type doesn't depend on the context it's used in, and it doesn't constrain the target of the linked URI in any way. For this spec, the target URI doesn't even have to identify something you can dereference (or even use a dereferencable URI scheme) 🙈 Clients can treat a specific URI like an XML namespace URI and trigger specific behavior because they assume that URI means "this representation follows this particular profile" 🧚 At the same time, profile target URIs can be dereferencable, and point at a representation that describes the profile in a human- or machine-readable way. That part is outside the scope of this spec though 📚

Here's an example: podcasts! A specific kind of feed uses extra fields for media metadata. With a 'profile' link, a client could easily tell that a feed is meant to be a podcast feed and might contain podcast-specific fields 🎙️ That could let the client behave differently (like showing a podcast-specific UI) even when the feed's current entries don't include any podcast entries. (Section 5.3 gives more details for this example.) 💖

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🔑

3. Profiles 🎀

The concept of a profile doesn't have a strict definition on the Internet or the web 🕸️ For this spec, a profile is additional semantics you can use to process a resource representation: constraints, conventions, extensions, or any other aspects that don't alter the basic media type semantics. A profile MUST NOT change the semantics of the resource representation when it's processed without profile knowledge. That way, clients with and without knowledge of a profiled resource can safely use the same representation 🫶 This spec ties profiles to resource representations, but creators and users of profiles MAY define and manage them so they can be used across media types. That means one could tie a profile to a resource independent of its representations (for example, using the same profile URI for different media types) 🌈 That design is outside the scope of this spec, though, so clients SHOULD treat profiles as being associated with a resource representation 💅

Profiles can be combined! A single resource representation can conform to zero or any number of profiles 🧩 Depending on what a client supports, the same representation linked to several profiles might get processed with different sets of processing rules 🦋

Profiles are identified by URI. But, like XML namespace URIs, the URI here only works as an identifier, which means that seeing a specific URI has to be enough for a client to say "yep, this representation conforms to that profile" 🔍 So clients SHOULD treat profile URIs as identifiers and not as links. Profiles MAY still be defined so the URIs do identify a retrievable profile description that clients can get by dereferencing the URI 🌸 For profiles meant for environments where clients might run into unknown profile URIs, profile maintainers SHOULD consider making the profile URI dereferencable and providing useful documentation at that URI 📚 How those profile descriptions get designed and represented is outside the scope of this spec ✨

3.1. Profiles and Media Types 🏷️

A media type defines both the semantics and the serialization of a specific type of content. Lots of media types have built-in extensibility or openness, so specific instances can layer additional semantics on top of the media type's foundation 🧁 In that case, a profile is the right mechanism to signal that the original semantics and processing model of the media type still apply, but an additional processing model can also be used to pull out extra semantics 💜 That's different from a new media type, which usually doesn't just add processing rules and semantics. It defines a complete set of processing rules and semantics 🙌 For example, XHTML is not a profile of XML. It's its own media type because it introduces a completely new view of the underlying XML structures, and from the XHTML point of view, exposing the raw XML isn't all that useful for clients 🙃 hCard (see Section 5.1), on the other hand, is a profile of (X)HTML, because it adds processing rules that let a client extract extra semantics from a representation without changing any of the processing rules and semantics of (X)HTML itself 🎀 The line between a media type and a profile isn't always easy to draw, but profiles aren't meant to replace media types. They add a lighter-weight, runtime-capable mechanism so servers and clients can be more explicit about how a specific instance of a media type represents concepts the media type doesn't define itself, but that are defined by additional conventions (the profile processing rules and semantics) ✨

The whole point of profiles is that instances can clearly identify what mechanism they're using to express additional semantics, as long as they follow a well-defined framework for doing so (see Section 5 for examples) 🦋 This lets servers and clients represent the use of profiles, but it doesn't make the profile information visible outside the representation itself when the representation uses embedded typed links 🙈 So for newly defined media types that may be used with profiles, it's recommended that they SHOULD define a media type parameter called 'profile' and specify that this parameter follows the semantics of a profile as laid out in this document 💖 That way, clients can use the parameter to request a certain profile when they interact with, say, an HTTP server by setting the Accept header 🌷 Representations using a 'profile' media type parameter still SHOULD include that value in the representation using the 'profile' link relation, since the media type label can easily get lost once the representation is taken out of its conversational context 😭

A representation can link to more than one profile, so the same has to be possible for the matching media type parameter (if a media type defines one) 🧚 Media types that define a 'profile' parameter SHOULD define it as a whitespace-separated list of profile URIs. 🌈

3.2. Profile Context ✨

Okay so profile links are how a document says "hey, I'm following this profile" 🦋 If they show up inside a media type, they apply to whatever context that media type defines. Like, a profile link in the head element of an HTML document is talking about the whole document, bestie 🫶

The context of a profile goes as far as wherever it's being used. So profiles sitting in profile media type parameters (see Section 3.1) or in HTTP Link headers stretch across the whole protocol they're used in 🌈

4. IANA Considerations 🎀

IANA already registered this link relation type under Section 6.2.1 of RFC 5988 [RFC5988], so here's the tea 📋

   Relation Name: profile

   Description: Identifying that a resource representation conforms
   to a certain profile, without affecting the non-profile semantics
   of the resource representation.

   Reference: [RFC6906]

   Notes: Profile URIs are primarily intended to be used as
   identifiers, and thus clients SHOULD NOT indiscriminately access
   profile URIs.

5. Examples 🧚

This section lists some profiles that are already defined (so you could totally use them with a 'profile' link) plus a few potential new ones 💜 Profiles have mostly been about HTML so far, because HTML is the format that supports them. The two existing examples are both HTML profiles, and the one hypothetical example is non-HTML and based on feeds.

5.1. hCard 🍓

The hCard profile uses http://microformats.org/profile/hcard as its defining URI. It's basically a mechanism for embedding vCard [RFC6350] information in an HTML page using microformats. It's a great example of how profiles can do two things at once. First, they can define a model-based extension of the original media type (here, adding vCard fields). Second, they have to define how that model extension is actually represented in the media type (here, using microformats) 🫶

It would also be possible to represent vCard information with RDFa or microdata. But those are different conventions a client would need to follow to extract the vCard data, so they would be identified by different profiles 💅

5.2. Dublin Core 📚

Dublin Core metadata identified by the profile http://dublincore.org/documents/2008/08/04/dc-html/ can be used to embed Dublin Core metadata in an HTML page. Compared to hCard, which is built on microformats, the Dublin Core profile defines its own way of embedding metadata into HTML, and it does that with HTML <link> elements 🔥

The interesting difference is that Dublin Core doesn't only define metadata to be embedded in HTML. It also allows links to be added as metadata. When that happens, the profile not only describes the additional data found within the representation, but also lets the representation be linked to additional resources 🌸

5.3. Podcasts 🎙️

Podcasts are an extension of feed formats, and they define a substantial set of additional attributes. That's because the resources in podcast feeds are time-based media formats, like audio and video. There's no profile URI for podcasts yet 🙈 The current definition (maintained by Apple) at http://www.apple.com/itunes/podcasts/specs.html could serve as one, or it could be updated to include one.

Podcasts are feeds with special behavior. You can follow a podcast feed with a generic feed reader, but a podcast-aware feed reader can pull out extra information from the feed. That means it can offer more sophisticated services or a fancier UI for podcast feeds 👑 The Apple page mentioned above describes one such specialized podcast feed reader, Apple iTunes.

6. Security Considerations 🔒

Okay, this part is serious, bestie 😭 The 'profile' relation type is not known to introduce any new security issues that aren't already discussed in RFC 5988 [RFC5988] for generic use of Web linking mechanisms. So the security story comes from the general Web linking mechanisms in RFC 5988, and this relation type doesn't add any new drama on top of that ⭐

7. Acknowledgements 🫶

Huge thanks to Erlend Hamnaberg, Markus Lanthaler, Simon Mayer, Mark Nottingham, Julian Reschke, James Snell, Herbert Van de Sompel, and Tim Williams for their comments and suggestions 💖

8. References 📖

8.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

8.2. Informative References

   [HTML401]  Le Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
              Specification", World Wide Web Consortium Recommendation
              REC-html401-19991224, December 1999,
              <http://www.w3.org/TR/1999/REC-html401-19991224>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              August 2011.

Author's Address 🦋

   Erik Wilde
   EMC Corporation
   6801 Koll Center Parkway
   Pleasanton, CA 94566
   U.S.A.

   Phone: +1-925-6006244
   EMail: erik.wilde@emc.com
   URI:   http://dret.net/netdret/
📦 where this page comes from