Movatterモバイル変換

Independent Submission                                          E. WildeRequest for Comments: 6892                               EMC CorporationCategory: Informational                                       March 2013ISSN: 2070-1721The 'describes' Link Relation TypeAbstract   This specification defines the 'describes' link relation type that   allows resource representations to indicate that they are describing   another resource.  In contexts where applications want to associate   described resources and description resources, and want to build   services based on these associations, the 'describes' link relation   type provides the opposite direction of the 'describedby' link   relation type, which already is a registered link relation type.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 has chosen 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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6892.Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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.Wilde                         Informational                     [Page 1]

RFC 6892                  describes" Link Type                March 2013Table of Contents1. Introduction ....................................................22. Resource Descriptions ...........................................23. Use Case ........................................................34. IANA Considerations .............................................45. Security Considerations .........................................46. Acknowledgements ................................................47. References ......................................................57.1. Normative References .......................................57.2. Informative References .....................................51.  Introduction   Resources on the web can be identified by any (registered) URI scheme   and can be represented by any (registered) media type.  In many   cases, applications establish specific (i.e., typed) relations   between the resources they are concerned with, which can either be   under their control or controlled by another authority.  A common   usage pattern for associating resources is to have resources that are   descriptions of other resources.  This specification registers the   'describes' link relation, which allows applications to represent the   fact that one resource is a description of another resource.RFC 5988 [1] "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 registration request intends to augment the link   relation registry with a link relation that is the inverse of the   already registered 'describedby' relation, so that links between   described resources and describing resources can be represented in   both directions.2.  Resource Descriptions   Associating resources with descriptions of these resources is a   recurring pattern on the web.  The IANA "Link Relations" registry   established byRFC 5988 [1] currently contains a 'describedby' link   relation type, which has been registered by POWDER [2].  The   definition given in the reference document for that registration is   as follows: "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".Wilde                         Informational                     [Page 2]

RFC 6892                  describes" Link Type                March 2013   Since many scenarios using resource descriptions need to represent   the fact that some resource describes another resource (the opposite   of the 'describedby' relation), 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, without constraining in any way the identifiers   being used for A and B, and the media types for the representations   being provided when those identifiers are dereferenced.   Specifically, it is possible that identifiers A and/or B have no   associated interaction method (they could be URNs, for example), but   it still is valid to establish the A 'describes' B link.   Another design freedom is to use "chains" of 'describes' (or   'describedby') links, so that one resource is a description of   another resource, which in turn is a description of yet another   resource.  The "levels" of descriptions can go as deep as required by   an application and are not constrained by this specification.3.  Use Case   Beginning with the POWDER document [2], which specifies the   'describedby' link relation, the use case for the 'describedby' link   relation is that a described resource, such as an HTML web page, can   specify a link where clients can find a description of this resource.   While the 'describedby' link relation is defined to be independent of   specific formats and representations, within the context of POWDER,   the assumption is that the linked resources most often will provide a   description based on the Resource Description Framework (RDF), for   example, to provide metadata about a document's author and other   provenance information.   The 'describes' link relation allows servers hosting description   resources to associate those description resources with the resources   that they are describing.  In the RDF-oriented scenario of POWDER,   this means that a service managing description resources would use   'describes' links to represent the fact that the description   resources it exposes provide some description of the described   resource, very likely in some RDF representation.  However, since   link relations are independent of resource formats or   representations, such an association could also be made in other   formats such as XML or JavaScript Object Notation (JSON), allowing   servers to use a single and consistent link relation to associate   description resources with described resources.   Generally speaking, the idea of the 'describes' relation is the same   as the idea of the 'describedby' relation; to be independent of   specific formats and representations of both described resources and   description resources.  The 'describes' link relation (together withWilde                         Informational                     [Page 3]

RFC 6892                  describes" Link Type                March 2013   the already registered 'describedby' link relation) thus serves as a   general foundation of how described resources and description   resources can be associated.4.  IANA Considerations   The link relation type below has been registered by IANA perSection6.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   Resource descriptions should never be treated as authoritative or   exclusive without relying on additional mechanisms for trust and   security.  Resources can have many (possibly conflicting)   descriptions, and the 'describes' link relation type makes no claim   whatsoever about the authority of the party providing the association   between the two resources, or about the authority of the party   providing the description resource.  Before making any assumptions   about the authority of the description resource (both the accuracy of   the description contained in the description resource, and the   authority to provide a description of the described resource),   clients need a context that allows them to understand both the   authority of the description itself, and the authority to establish   the 'describes' relation.  Nobody can stop clients from providing   misleading unauthorized and/or descriptions, and clients need to have   both a security and trust framework to allow them to choose between   trusted and untrusted descriptions.6.  Acknowledgements   Thanks for comments and suggestions provided by Mark Nottingham.Wilde                         Informational                     [Page 4]

RFC 6892                  describes" Link Type                March 20137.  References7.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/Wilde                         Informational                     [Page 5]