idnits 2.17.1 draft-wilde-describes-link-01.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 (September 22, 2012) is 4234 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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: Standards Track September 22, 2012 5 Expires: March 26, 2013 7 The 'describes' Link Relation Type 8 draft-wilde-describes-link-01 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 March 26, 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 -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Resources on the Web can be identified by any (registered) URI scheme 71 and can be represented by any (registered) media type. In many 72 cases, applications establish specific (i.e., typed) relations 73 between the resources they are concerned with, which can either be 74 under their control, or controlled by another authority. A common 75 usage pattern for associating resources is to have resources which 76 are descriptions of other resources. This specification registers 77 the 'describes' link relation, which allows applications to represent 78 the fact that one resource is a description of another resource. 80 RFC 5988 [1] "defines a framework for typed links that isn't specific 81 to a particular serialisation or application. It does so by 82 redefining the link relation registry established by Atom to have a 83 broader domain, and adding to it the relations that are defined by 84 HTML." This registration request intends to augment the link 85 relation registry with a link relation that is the inverse of the 86 already registered 'describedby' relation, so that links between 87 described resources and describing resources can be represented in 88 both directions. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [2]. 96 3. Resource Descriptions 98 Associating resources with descriptions of these resources is a 99 recurring pattern on the Web. The IANA link relation registry 100 established by RFC 5988 [1] currently contains a 'describedby' link 101 relation type, which has been registered by POWDER [3]. The 102 definition given in that registration is as follows: "The 103 relationship A 'describedby' B asserts that resource B provides a 104 description of resource A. There are no constraints on the format or 105 representation of either A or B, neither are there any further 106 constraints on either resource." 108 Since many scenarios using resource descriptions need to represent 109 the fact that some resource describes a resource (the opposite of the 110 'describedby' relation), this document registers a 'describes' link 111 relation type. Establishing a link A 'describes' B asserts that the 112 resource identified by A is a description of the resource identified 113 by B, without constraining in any way the identifiers being used for 114 A and B, and the media types for the representations being provided, 115 when those identifiers are dereferenced. Specifically, it is 116 possible that identifiers A and/or B have no associated interaction 117 method (they could be URNs, for example), but it still is valid to 118 establish the A 'describes' B link. 120 Another design freedom is to use "chains" of 'describes' (or 121 'describedby') links, so that one resource is a description of 122 another resource, which in turn is a description of yet another 123 resource. The "levels" of descriptions can go as deep as required by 124 an application, and are not constrained by this specification. 126 4. Use Case 128 Starting from the POWDER document specifying the 'describedby' link 129 relation [3], the use case for the 'describedby' link relation is 130 that a described resource, such as a HTML Web page, can specify a 131 link where clients can find a description of this resource. While 132 the 'describedby' link relation is defined to be independent of 133 specific formats and representations, within the context of POWDER, 134 the assumption is that the linked resources most often will provide 135 an RDF-based description, for example providing metadata about a 136 document's author and other provenance information. 138 The 'describes' link relation allows servers hosting description 139 resources to associate those description resources with the resources 140 that they are describing. In the RDF-oriented scenario of POWDER, 141 this means that a service managing description resources would use 142 'describes' links to represent the fact that the description 143 resources it exposes provide some description of the described 144 resource, very likely in some RDF representation. However, since 145 link relations are independent of resource formats or 146 representations, such an association could also be made in other 147 formats such as XML or JSON, allowing servers to use a single and 148 consistent link relation to associate description resources with 149 described resources. 151 Generally speaking, the idea of the 'describes' relation is the same 152 as the idea of the 'describedby' relation: to be independent of 153 specific formats and representations of both described resources and 154 description resources. The 'describes' link relation (together with 155 the already registered 'describedby' link relation) thus serves as a 156 general foundation of how described resources and description 157 resources can be associated. 159 5. IANA Considerations 161 The link relation type below has been registered by IANA per Section 162 6.2.1 of RFC 5988 [1]: 164 Relation Name: describes 166 Description: The relationship A 'describes' B asserts that 167 resource A provides a description of resource B. There are no 168 constraints on the format or representation of either A or B, 169 neither are there any further constraints on either resource. 171 Reference: [[ This document ]] 173 Notes: This link relation type is intended to be the inverse of 174 the already existing 'describedby' relation type, thus allowing 175 links to be established from the describing resource to the 176 described resource. 178 6. Security Considerations 180 Resource descriptions SHOULD never be treated as authoritative or 181 exclusive without relying on additional mechanisms for trust and 182 security. Resources can have many (possible conflicting) 183 descriptions, and the 'describes' link relation type makes no claim 184 whatsoever about the authority of the party providing the association 185 between the two resources, or about the authority of the party 186 providing the description resource. Before making any assumptions 187 about the authority of the description resource (both the accuracy of 188 the description contained in the description resource, and the 189 authority to provide a description of the described resource), 190 clients need a context that allows them to understand both the 191 authority of the description itself, and the authority to establish 192 the 'describes' relation. Nobody can stop clients from providing 193 misleading unauthorized and/or descriptions, and clients need to have 194 both a security and trust framework to allow them to choose between 195 trusted and untrusted descriptions. 197 7. Change Log 199 Note to RFC Editor: Please remove this section before publication. 201 7.1. From -00 to -01 202 o Added "Use Case" section (Section 4). 204 o Improved Security Considerations 206 o Minor textual improvements 208 8. References 210 8.1. Normative References 212 [1] Nottingham, M., "Web Linking", RFC 5988, October 2010. 214 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 215 Levels", RFC 2119, March 1997. 217 8.2. Informative References 219 [3] Archer, P., Smith, K., and A. Perego, "Protocol for Web 220 Description Resources (POWDER): Description Resources", World 221 Wide Web Consortium Recommendation REC-powder-dr-20090901, 222 September 2009, 223 . 225 Appendix A. Acknowledgements 227 Thanks for comments and suggestions provided by Mark Nottingham. 229 Author's Address 231 Erik Wilde 232 EMC Corporation 233 6801 Koll Center Parkway 234 Pleasanton, CA 94566 235 U.S.A. 237 Phone: +1-925-6006244 238 Email: erik.wilde@emc.com 239 URI: http://dret.net/netdret/