1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc6892.txt b/doc/rfc/rfc6892.txt
new file mode 100644
index 0000000..1992eaa
--- /dev/null
+++ b/doc/rfc/rfc6892.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Independent Submission                                          E. Wilde
+Request for Comments: 6892                               EMC Corporation
+Category: Informational                                       March 2013
+ISSN: 2070-1721
+
+
+                   The 'describes' Link Relation Type
+
+Abstract
+
+   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; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://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 to BCP 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 2013
+
+
+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
+
+   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 by RFC 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 with
+
+
+
+Wilde                         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 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
+
+   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 2013
+
+
+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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wilde                         Informational                     [Page 5]
+