idnits 2.17.1 draft-wilde-describes-link-00.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 (April 3, 2012) is 4406 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 April 3, 2012 5 Expires: October 5, 2012 7 The 'describes' Link Relation Type 8 draft-wilde-describes-link-00 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 October 5, 2012. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Resources on the Web can be identified by an (registered) URI scheme 69 and can be represented by any (registered) media type. In many 70 cases, applications establish specific (i.e., typed) relations 71 between the resources they are concerned with, which can be under 72 their control or controlled by another authority. A common pattern 73 for associating resources is to have resources which are descriptions 74 of other resources. This specification registers the 'describes' 75 link relation which allows applications to represent the fact that 76 one resource is a description of another resource. 78 RFC 5988 [1] "defines a framework for typed links that isn't specific 79 to a particular serialisation or application. It does so by 80 redefining the link relation registry established by Atom to have a 81 broader domain, and adding to it the relations that are defined by 82 HTML." 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [2]. 90 3. Resource Descriptions 92 Associating resources with descriptions of these resources is a 93 recurring pattern on the Web. The IANA link relation registry 94 established by RFC 5988 [1] currently contains a 'describedby' link 95 relation type, which has been registered by POWDER [3]. The 96 definition given in that registration is as follows: "The 97 relationship A 'describedby' B asserts that resource B provides a 98 description of resource A. There are no constraints on the format or 99 representation of either A or B, neither are there any further 100 constraints on either resource." 102 Since many scenarios using resource descriptions need to represent 103 the fact that some resource describes a resource (the opposite of the 104 'describedby' relation), this document registers a 'describes' link 105 relation type. Establishing a link A 'describes' B asserts that the 106 resource identified by A is a description of the resource identified 107 by B, without constraining in any way the identifiers being used for 108 A and B, and the media types for the representations being provided, 109 when those identifiers are dereferenced. Specifically, it is 110 possible that identifiers A and/or B have no associated interaction 111 method (they could be URNs, for example), but it still is valid to 112 establish the A 'describes' B link. 114 Another design freedom is to use "chains" of 'describes' (or 115 'describedby') links, so that one resource is a description of 116 another resource, which in turn is a description of yet another 117 resource. The "levels" of descriptions can go as deep as required by 118 an application, and are not constrained by this specification. 120 4. IANA Considerations 122 The link relation type below has been registered by IANA per Section 123 6.2.1 of RFC 5988 [1]: 125 Relation Name: describes 127 Description: Identifying that a resource describes another 128 resource, without making additional claims of the described or 129 description resource. 131 Reference: RFC xxxx (this draft's eventual RFC number) 133 Notes: This link relation type is intended to be the inverse of 134 the already 'describedby' relation type, thus allowing links to be 135 established in both directions. 137 5. Security Considerations 139 Resource descriptions SHOULD never be treated as authoritative or 140 exclusive without relying on additional mechanisms for trust and 141 security. Resources can have many (possible conflicting) 142 descriptions, and the 'describes' link relation type makes no claim 143 whatsoever about the authority of the party providing the association 144 between the two resources, or about the authority of the party 145 providing the description resource. 147 6. Change Log 149 Note to RFC Editor: Please remove this section before publication. 151 7. References 152 7.1. Normative References 154 [1] Nottingham, M., "Web Linking", RFC 5988, October 2010. 156 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 157 Levels", RFC 2119, March 1997. 159 7.2. Informative References 161 [3] Archer, P., Smith, K., and A. Perego, "Protocol for Web 162 Description Resources (POWDER): Description Resources", World 163 Wide Web Consortium Recommendation REC-powder-dr-20090901, 164 September 2009, 165 . 167 Appendix A. Acknowledgements 169 Thanks for comments and suggestions provided by ... 171 Author's Address 173 Erik Wilde 174 EMC Corporation 175 6801 Koll Center Parkway 176 Pleasanton, CA 94566 177 U.S.A. 179 Phone: +1-925-6006244 180 Email: erik.wilde@emc.com 181 URI: http://dret.net/netdret/