idnits 2.17.1 draft-wilde-describes-link-02.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 (October 17, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (ref. '1') (Obsoleted by RFC 8288) 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 E. Wilde 3 Internet-Draft EMC Corporation 4 Intended status: Informational October 17, 2012 5 Expires: April 20, 2013 7 The 'describes' Link Relation Type 8 draft-wilde-describes-link-02 10 Abstract 12 This specification defines the 'describes' link relation type that 13 allows resource representations to indicate that they are describing 14 another resource. In contexts where applications want to associate 15 described resources and description resources, and want to build 16 services based on these associations, the 'describes' link relation 17 type provides the opposite direction of the 'describedby' link 18 relation type, which already is a registered link relation type. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 20, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Resource Descriptions . . . . . . . . . . . . . . . . . . . . . 3 57 4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 5 62 7.2. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Resources on the Web can be identified by any (registered) URI scheme 72 and can be represented by any (registered) media type. In many 73 cases, applications establish specific (i.e., typed) relations 74 between the resources they are concerned with, which can either be 75 under their control, or controlled by another authority. A common 76 usage pattern for associating resources is to have resources which 77 are descriptions of other resources. This specification registers 78 the 'describes' link relation, which allows applications to represent 79 the fact that one resource is a description of another resource. 81 RFC 5988 [1] "defines a framework for typed links that isn't specific 82 to a particular serialisation or application. It does so by 83 redefining the link relation registry established by Atom to have a 84 broader domain, and adding to it the relations that are defined by 85 HTML." This registration request intends to augment the link 86 relation registry with a link relation that is the inverse of the 87 already registered 'describedby' relation, so that links between 88 described resources and describing resources can be represented in 89 both directions. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [2]. 97 3. Resource Descriptions 99 Associating resources with descriptions of these resources is a 100 recurring pattern on the Web. The IANA link relation registry 101 established by RFC 5988 [1] currently contains a 'describedby' link 102 relation type, which has been registered by POWDER [3]. The 103 definition given in that registration is as follows: "The 104 relationship A 'describedby' B asserts that resource B provides a 105 description of resource A. There are no constraints on the format or 106 representation of either A or B, neither are there any further 107 constraints on either resource." 109 Since many scenarios using resource descriptions need to represent 110 the fact that some resource describes a resource (the opposite of the 111 'describedby' relation), this document registers a 'describes' link 112 relation type. Establishing a link A 'describes' B asserts that the 113 resource identified by A is a description of the resource identified 114 by B, without constraining in any way the identifiers being used for 115 A and B, and the media types for the representations being provided, 116 when those identifiers are dereferenced. Specifically, it is 117 possible that identifiers A and/or B have no associated interaction 118 method (they could be URNs, for example), but it still is valid to 119 establish the A 'describes' B link. 121 Another design freedom is to use "chains" of 'describes' (or 122 'describedby') links, so that one resource is a description of 123 another resource, which in turn is a description of yet another 124 resource. The "levels" of descriptions can go as deep as required by 125 an application, and are not constrained by this specification. 127 4. Use Case 129 Starting from the POWDER document specifying the 'describedby' link 130 relation [3], the use case for the 'describedby' link relation is 131 that a described resource, such as a HTML Web page, can specify a 132 link where clients can find a description of this resource. While 133 the 'describedby' link relation is defined to be independent of 134 specific formats and representations, within the context of POWDER, 135 the assumption is that the linked resources most often will provide 136 an RDF-based description, for example providing metadata about a 137 document's author and other provenance information. 139 The 'describes' link relation allows servers hosting description 140 resources to associate those description resources with the resources 141 that they are describing. In the RDF-oriented scenario of POWDER, 142 this means that a service managing description resources would use 143 'describes' links to represent the fact that the description 144 resources it exposes provide some description of the described 145 resource, very likely in some RDF representation. However, since 146 link relations are independent of resource formats or 147 representations, such an association could also be made in other 148 formats such as XML or JSON, allowing servers to use a single and 149 consistent link relation to associate description resources with 150 described resources. 152 Generally speaking, the idea of the 'describes' relation is the same 153 as the idea of the 'describedby' relation: to be independent of 154 specific formats and representations of both described resources and 155 description resources. The 'describes' link relation (together with 156 the already registered 'describedby' link relation) thus serves as a 157 general foundation of how described resources and description 158 resources can be associated. 160 5. IANA Considerations 162 The link relation type below has been registered by IANA per Section 163 6.2.1 of RFC 5988 [1]: 165 Relation Name: describes 167 Description: The relationship A 'describes' B asserts that 168 resource A provides a description of resource B. There are no 169 constraints on the format or representation of either A or B, 170 neither are there any further constraints on either resource. 172 Reference: [[ This document ]] 174 Notes: This link relation type is intended to be the inverse of 175 the already existing 'describedby' relation type, thus allowing 176 links to be established from the describing resource to the 177 described resource. 179 6. Security Considerations 181 Resource descriptions SHOULD never be treated as authoritative or 182 exclusive without relying on additional mechanisms for trust and 183 security. Resources can have many (possible conflicting) 184 descriptions, and the 'describes' link relation type makes no claim 185 whatsoever about the authority of the party providing the association 186 between the two resources, or about the authority of the party 187 providing the description resource. Before making any assumptions 188 about the authority of the description resource (both the accuracy of 189 the description contained in the description resource, and the 190 authority to provide a description of the described resource), 191 clients need a context that allows them to understand both the 192 authority of the description itself, and the authority to establish 193 the 'describes' relation. Nobody can stop clients from providing 194 misleading unauthorized and/or descriptions, and clients need to have 195 both a security and trust framework to allow them to choose between 196 trusted and untrusted descriptions. 198 7. Change Log 200 Note to RFC Editor: Please remove this section before publication. 202 7.1. From -01 to -02 203 o Changed category from "Standard" to "Informational". 205 o Minor textual changes. 207 7.2. From -00 to -01 209 o Added "Use Case" section (Section 4). 211 o Improved Security Considerations. 213 o Minor textual improvements. 215 8. References 217 8.1. Normative References 219 [1] Nottingham, M., "Web Linking", RFC 5988, October 2010. 221 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", RFC 2119, March 1997. 224 8.2. Informative References 226 [3] Archer, P., Smith, K., and A. Perego, "Protocol for Web 227 Description Resources (POWDER): Description Resources", World 228 Wide Web Consortium Recommendation REC-powder-dr-20090901, 229 September 2009, 230 . 232 Appendix A. Acknowledgements 234 Thanks for comments and suggestions provided by Mark Nottingham. 236 Author's Address 238 Erik Wilde 239 EMC Corporation 240 6801 Koll Center Parkway 241 Pleasanton, CA 94566 242 U.S.A. 244 Phone: +1-925-6006244 245 Email: erik.wilde@emc.com 246 URI: http://dret.net/netdret/