RFC 6892

The 'describes' Link Relation Type

📅 published March 2013, from ietf

Okay bestie, first the vibe check. 💖 This is an Independent Submission by E. Wilde (that's Erik Wilde, from EMC Corporation 🦋). It's Informational, dated March 2013, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC. 🎀

Abstract

This spec defines the 'describes' link relation type 🌸, which lets a resource representation say that it's describing another resource. 🫶 When apps want to link described resources to their description resources and build services off those links, 'describes' is the opposite direction of the 'describedby' link relation type. And 'describedby' is already registered, so we're just adding its inverse. 🔥

Status of This Memo

Real talk, this is not an Internet Standards Track spec. 💅 It's published just for information. 🧚

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's valuable for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. (See Section 2 of RFC 5741 for that. 📚)

If you want the current status, any errata, or a way to give feedback, check http://www.rfc-editor.org/info/rfc6892. ✨

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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. 🙈

Table of Contents

1. Introduction ....................................................2
2. Resource Descriptions ...........................................2
3. Use Case ........................................................3
4. IANA Considerations .............................................4
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. References ......................................................5
   7.1. Normative References .......................................5
   7.2. Informative References .....................................5

1. Introduction 🌸

Okay so, resources on the web can be identified by any (registered) URI scheme and represented by any (registered) media type. ✨ Apps often set up specific, typed relations between the resources they care about, and those resources can be under their own control or under some other authority's. 💅 A super common pattern is having resources that are descriptions of other resources. This spec registers the 'describes' link relation, so apps can say "this resource is a description of that one." 🦋

RFC 5988 [1] is the framework here, and it's giving "typed links that aren't tied to a particular serialisation or application." 👑 Quote, unquote: "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". 💀 So this registration is basically adding the inverse of the already registered 'describedby' relation to the registry, so links between described and describing resources can go in both directions. 🔥

2. Resource Descriptions 💜

Linking resources to descriptions of them is a recurring pattern on the web, periodt. 🍓 The IANA "Link Relations" registry from RFC 5988 [1] already has a 'describedby' link relation type, which POWDER [2] registered. The definition in that reference document reads: "The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource".

Lots of scenarios with resource descriptions need to say that one resource describes another (the reverse of 'describedby'), so this document registers a 'describes' link relation type. 🎀 Establishing a link A 'describes' B asserts that the resource identified by A is a description of the resource identified by B. It doesn't constrain the identifiers used for A and B in any way, nor the media types of the representations you get when you dereference them. ✨ Specifically, A and/or B might have no associated interaction method (like they're URNs, for example), and it's still valid to establish the A 'describes' B link. 🧚

Another design freedom: you can chain 'describes' (or 'describedby') links, so one resource describes another, which describes yet another. ⭐ The "levels" of descriptions can go as deep as an application needs, and this spec doesn't limit them. 🌈

3. Use Case 🦋

Starting with the POWDER document [2], which specifies 'describedby', the use case is that a described resource, like an HTML web page, can point to a link where clients can find a description of it. 💖 'describedby' is defined to be independent of specific formats and representations, but in the POWDER context, the linked resources will most often provide a description based on the Resource Description Framework (RDF). Think metadata about a document's author and other provenance info. 🫶

The 'describes' link relation lets servers hosting description resources link those descriptions to the resources they describe. 🔥 In the RDF-flavoured POWDER scenario, a service managing description resources would use 'describes' links to say that the description resources it exposes give some description of the described resource, very likely in some RDF representation. 👑 But since link relations don't depend on resource formats or representations, the same association could be made in other formats too, like XML or JavaScript Object Notation (JSON). That way servers can use one consistent link relation to tie description resources to described ones. 💅

Basically, 'describes' is the same idea as 'describedby', just pointing the other way: independent of the specific formats and representations of both the described and the description resources. ✨ Together with the already registered 'describedby', 'describes' is the general foundation for associating described resources with description resources. 🌸

4. IANA Considerations 📚

The following link relation type was registered by IANA per Section 6.2.1 of RFC 5988 [1]:

   Relation Name: describes

   Description: The relationship A 'describes' B asserts that
   resource A provides a description of resource B.  There are no
   constraints on the format or representation of either A or B,
   neither are there any further constraints on either resource.

   Reference: [RFC6892]

   Notes: This link relation type is the inverse of the 'describedby'
   relation type.  While 'describedby' establishes a relation from
   the described resource back to the resource that describes it,
   'describes' established a relation from the describing resource to
   the resource it describes.  If B is 'describedby' A, then A
   'describes' B.

5. Security Considerations 🔥

⚠️ Serious moment, bestie. Resource descriptions should never be treated as authoritative or exclusive unless you're also relying on extra mechanisms for trust and security. ⚠️

Resources can have lots of descriptions, and they might conflict with each other. 💀 The 'describes' link relation type makes no claim whatsoever about the authority of whoever provides the association between the two resources, or about the authority of whoever provides the description resource. 😭 Before you assume anything about a description resource (both whether its description is accurate and whether that party is allowed to describe the described resource), clients need context that lets them understand both the authority of the description itself and the authority to establish the 'describes' relation. 🙈 Nobody can stop clients from being handed misleading unauthorized and/or descriptions, so clients need both a security and trust framework to pick between trusted and untrusted descriptions. 🛡️✨

6. Acknowledgements 🫶

Thanks to Mark Nottingham for comments and suggestions. 💜

7. References 📚

7.1. Normative References

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

7.2. Informative References

[2]  Archer, P., Smith, K., and A. Perego, "Protocol for Web
     Description Resources (POWDER): Description Resources", World
     Wide Web Consortium Recommendation REC-powder-dr-20090901,
     September 2009,
     <http://www.w3.org/TR/2009/REC-powder-dr-20090901/>.

Author's Address 🎀

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

Phone: +1-925-600-6244
EMail: erik.wilde@emc.com
URI:   http://dret.net/netdret/

That's the whole spec, bestie. 🌈✨ Now go link your descriptions both ways. 💅👑

📦 where this page comes from