doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc6415.txt b/doc/rfc/rfc6415.txt
new file mode 100644
index 0000000..1f009c8
--- /dev/null
+++ b/doc/rfc/rfc6415.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)              E. Hammer-Lahav, Ed.
+Request for Comments: 6415                                       B. Cook
+Category: Standards Track                                   October 2011
+ISSN: 2070-1721
+
+
+                           Web Host Metadata
+
+Abstract
+
+   This specification describes a method for locating host metadata as
+   well as information about individual resources controlled by the
+   host.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in 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/rfc6415.
+
+Copyright Notice
+
+   Copyright (c) 2011 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 1]
+
+RFC 6415                        host-meta                   October 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Example ....................................................3
+           1.1.1. Processing Resource-Specific Information ............4
+      1.2. Notational Conventions .....................................5
+   2. Obtaining host-meta Documents ...................................6
+   3. The host-meta Document ..........................................6
+      3.1. XML Document Format ........................................7
+           3.1.1. The "Link" Element ..................................7
+   4. Processing host-meta Documents ..................................8
+      4.1. Host-Wide Information ......................................9
+      4.2. Resource-Specific Information ..............................9
+   5. Security Considerations ........................................10
+   6. IANA Considerations ............................................11
+      6.1. The "host-meta" Well-Known URI ............................11
+      6.2. The "host-meta.json" Well-Known URI .......................11
+      6.3. The "lrdd" Relation Type ..................................11
+   Appendix A. JRD Document Format ...................................12
+   Appendix B. Acknowledgments .......................................15
+   Normative References ..............................................15
+
+1.  Introduction
+
+   Web-based protocols often require the discovery of host policy or
+   metadata, where "host" is not a single resource but the entity
+   controlling the collection of resources identified by Uniform
+   Resource Identifiers (URIs) with a common URI host [RFC3986], which
+   can be served by one or more servers.
+
+   While web protocols have a wide range of metadata needs, they often
+   use metadata that is concise, has simple syntax requirements, and can
+   benefit from storing their metadata in a common location used by
+   other related protocols.
+
+   Because there is no URI or representation available to describe a
+   host, many of the methods used for associating per-resource metadata
+   (such as HTTP headers) are not available.  This often leads to the
+   overloading of the root HTTP resource (e.g., 'http://example.com/')
+   with host metadata that is not specific or relevant to the root
+   resource itself.
+
+   This document defines a lightweight metadata document format for
+   describing hosts (thus the name "host-meta"), intended for use by
+   web-based protocols.  This document also registers the well-known URI
+   suffix "host-meta" in the Well-Known URI Registry established by
+   [RFC5785].
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 2]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   In addition, there are times when a host-wide scope for policy or
+   metadata is too coarse-grained. host-meta provides two mechanisms for
+   providing resource-specific information:
+
+   o  Link Templates - links using a URI template instead of a fixed
+      target URI, providing a way to define generic rules for generating
+      resource-specific links by applying the individual resource URI to
+      the template.
+
+   o  Link-based Resource Descriptor Documents (LRDD, pronounced 'lard')
+      - descriptor documents providing resource-specific information,
+      typically information that cannot be expressed using link
+      templates.  LRDD documents are linked to resources or host-meta
+      documents using link templates with the "lrdd" relation type.
+
+1.1.  Example
+
+   The following is a simple host-meta document including both host-wide
+   and resource-specific information for the 'example.com' host:
+
+   <?xml version='1.0' encoding='UTF-8'?>
+   <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
+
+     <!-- Host-Wide Information -->
+
+     <Property type='http://protocol.example.net/version'>1.0</Property>
+
+     <Link rel='copyright'
+      href='http://example.com/copyright' />
+
+     <!-- Resource-specific Information -->
+
+     <Link rel='hub'
+      template='http://example.com/hub' />
+
+     <Link rel='lrdd'
+      type='application/xrd+xml'
+      template='http://example.com/lrdd?uri={uri}' />
+
+     <Link rel='author'
+      template='http://example.com/author?q={uri}' />
+
+   </XRD>
+
+
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 3]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   The host-wide information that applies to the host in its entirety
+   provided by the document includes:
+
+   o  An "http://protocol.example.net/version" host property with a
+      value of "1.0".
+
+   o  A link to the host's copyright policy ("copyright").
+
+   The resource-specific information provided by the document includes:
+
+   o  A link template for receiving real-time updates ("hub") about
+      individual resources.  Since the template does not include a
+      template variable, the target URI is identical for all resources.
+
+   o  A LRDD document link template ("lrdd") for obtaining additional
+      resource-specific information contained in a separate document for
+      each individual resource.
+
+   o  A link template for finding information about the author of
+      individual resources ("author").
+
+1.1.1.  Processing Resource-Specific Information
+
+   When looking for information about an individual resource -- for
+   example, the resource identified by 'http://example.com/xy' -- the
+   resource URI is applied to the templates found, producing the
+   following links:
+
+    <Link rel='hub'
+     href='http://example.com/hub' />
+
+    <Link rel='lrdd'
+     type='application/xrd+xml'
+     href='http://example.com/lrdd?uri=http%3A%2F%2Fexample.com%2Fxy' />
+
+    <Link rel='author'
+     href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
+
+   The LRDD document for 'http://example.com/xy' (obtained via an HTTP
+   "GET" request):
+
+     <?xml version='1.0' encoding='UTF-8'?>
+     <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
+
+       <Subject>http://example.com/xy</Subject>
+
+       <Property type='http://spec.example.net/color'>red</Property>
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 4]
+
+RFC 6415                        host-meta                   October 2011
+
+
+       <Link rel='hub'
+        href='http://example.com/another/hub' />
+
+       <Link rel='author'
+        href='http://example.com/john' />
+     </XRD>
+
+   Together, the information available about the individual resource
+   (presented as an Extensible Resource Descriptor (XRD) document for
+   illustration purposes) is:
+
+   <?xml version='1.0' encoding='UTF-8'?>
+   <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
+
+    <Subject>http://example.com/xy</Subject>
+
+    <Property type='http://spec.example.net/color'>red</Property>
+
+    <Link rel='hub'
+     href='http://example.com/hub' />
+
+    <Link rel='hub'
+     href='http://example.com/another/hub' />
+
+    <Link rel='author'
+     href='http://example.com/john' />
+
+    <Link rel='author'
+     href='http://example.com/author?q=http%3A%2F%2Fexample.com%2Fxy' />
+
+   </XRD>
+
+   Note that the order of links matters and is based on their original
+   order in the host-meta and LRDD documents.  For example, the "hub"
+   link obtained from the host-meta link template has a higher priority
+   than the link found in the LRDD document because the host-meta link
+   appears before the "lrdd" link.
+
+   On the other hand, the "author" link found in the LRDD document has a
+   higher priority than the link found in the host-meta document because
+   it appears after the "lrdd" link.
+
+1.2.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 5]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   This document uses the Augmented Backus-Naur Form (ABNF) notation of
+   [RFC5234].  Additionally, the following rules are included from
+   [RFC3986]: reserved, unreserved, and pct-encoded.
+
+2.  Obtaining host-meta Documents
+
+   The client obtains the host-meta document for a given host by sending
+   an HTTP [RFC2616] or an HTTPS [RFC2818] GET request to the host for
+   the "/.well-known/host-meta" path, using the default ports defined
+   for each protocol (e.g., port 80 for HTTP and port 443 for HTTPS).
+   The scope and meaning of host-meta documents obtained via other
+   protocols or ports is undefined.
+
+   The server MUST support at least one protocol but MAY support both.
+   If both protocols are supported, they MUST produce the same document.
+
+   The decision as to which protocol is used to obtain the host-meta
+   document has significant security ramifications, as described in
+   Section 5.
+
+   For example, the following request is used to obtain the host-meta
+   document for the 'example.com' host:
+
+     GET /.well-known/host-meta HTTP/1.1
+     Host: example.com
+
+   If the server response indicates that the host-meta resource is
+   located elsewhere (a 301, 302, or 307 response status code), the
+   client SHOULD try to obtain the resource from the location provided
+   in the response.  This means that the host-meta document for one host
+   MAY be retrieved from another host.  Likewise, if the resource is not
+   available or does not exist (e.g., a 404 or 410 response status
+   code), the client SHOULD infer that metadata is not available via
+   this mechanism.
+
+   The host-meta document SHOULD be served with the
+   "application/xrd+xml" media type.
+
+3.  The host-meta Document
+
+   The host-meta document uses the XRD 1.0 document format as defined by
+   [OASIS.XRD-1.0], which provides a simple and extensible XML-based
+   schema for describing resources.  This specification defines
+   additional processing rules needed to describe hosts.  Documents MAY
+   include any elements included in the XRD 1.0 schema that are not
+   explicitly excluded by this specification.
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 6]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   The server MAY offer alternative representations of any XRD document
+   it serves (host-meta, LRDD, or other XRD-based documents).  The
+   client MAY request a particular representation using the HTTP
+   "Accept" request header field.  If no "Accept" request header field
+   is included with the request, or if the client requests an
+   "application/xrd+xml" representation, the server MUST respond using
+   the REQUIRED XRD 1.0 XML representation described in Section 3.1.
+
+   Applications using the host-meta document MAY require the server to
+   provide a specific alternative representation in addition to the
+   XRD 1.0 XML representation when explicitly requested by the client.
+
+   A JavaScript Object Notation (JSON) Resource Descriptor, known as
+   JRD, is described in Appendix A.  It is RECOMMENDED that servers
+   offer the JRD representation in addition to the XRD representation.
+
+3.1.  XML Document Format
+
+   The host-meta document root MUST be an "XRD" element.  The document
+   SHOULD NOT include a "Subject" element, as at this time no URI is
+   available to identify hosts.  The use of the "Alias" element in
+   host-meta is undefined and NOT RECOMMENDED.
+
+   The subject (or "context IRI", as defined by [RFC5988]) of the XRD
+   "Property" and "Link" elements is the host described by the host-meta
+   document.  However, the subject of "Link" elements with a "template"
+   attribute is the individual resource whose URI is applied to the link
+   template, as described in Section 3.1.1.
+
+3.1.1.  The "Link" Element
+
+   The XRD "Link" element, when used with the "href" attribute, conveys
+   a link relation between the host described by the document and a
+   common target URI.
+
+   For example, the following link declares a common copyright license
+   for the entire scope:
+
+     <Link rel='copyright' href='http://example.com/copyright' />
+
+   However, a "Link" element with a "template" attribute conveys a
+   relation whose context is an individual resource within the host-meta
+   document scope, and whose target is constructed by applying the
+   context resource URI to the template.  The template string MAY
+   contain a URI string without any variables to represent a resource-
+   level relation that is identical for every individual resource.
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 7]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   For example, a blog with multiple authors can provide information
+   about each article's author by providing an endpoint with a parameter
+   set to the URI of each article.  Each article has a unique author,
+   but all share the same pattern of where that information is located:
+
+     <Link rel='author'
+      template='http://example.com/author?article={uri}' />
+
+3.1.1.1.  Template Syntax
+
+   This specification defines a simple template syntax for URI
+   transformation.  A template is a string containing brace-enclosed
+   ("{}") variable names marking the parts of the string that are to be
+   substituted by the corresponding variable values.
+
+   Before substituting template variables, values MUST be encoded using
+   UTF-8, and any character other than unreserved (as defined by
+   [RFC3986]) MUST be percent-encoded per [RFC3986].
+
+   This specification defines a single variable -- "uri" -- as the
+   entire context resource URI.  Protocols MAY define additional
+   relation-specific variables and syntax rules, but SHOULD only do so
+   for protocol-specific relation types, and MUST NOT change the meaning
+   of the "uri" variable.  If a client is unable to successfully process
+   a template (e.g., unknown variable names, unknown or incompatible
+   syntax), the parent "Link" element SHOULD be ignored.
+
+   The template syntax ABNF follows:
+
+    URI-Template =  *( uri-char / variable )
+    variable     =  "{" var-name "}"
+    uri-char     =  ( reserved / unreserved / pct-encoded )
+    var-name     =  %x75.72.69 / ( 1*var-char ) ; "uri" or other names
+    var-char     =  ALPHA / DIGIT / "." / "_"
+
+   For example:
+
+    Input:    http://example.com/r?f=1
+    Template: http://example.org/?q={uri}
+    Output:   http://example.org/?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1
+
+4.  Processing host-meta Documents
+
+   Once the host-meta document has been obtained, the client processes
+   its content based on the type of information desired: host-wide or
+   resource-specific.
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 8]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   Clients usually look for a link with a specific relation type or
+   other attributes.  In such cases, the client does not need to process
+   the entire host-meta document and all linked LRDD documents, but
+   instead process the various documents in their prescribed order until
+   the desired information is found.
+
+   Protocols using host-meta must indicate whether the information they
+   seek is host-wide or resource-specific -- for example, "obtain the
+   first host-meta resource-specific link using the 'author' relation
+   type".  If both types are used for the same purpose (e.g., first look
+   for resource-specific, then look for host-wide), the protocol must
+   specify the processing order.
+
+4.1.  Host-Wide Information
+
+   When looking for host-wide information, the client MUST ignore any
+   "Link" elements with a "template" attribute, as well as any link
+   using the "lrdd" relation type.  All other elements are scoped as
+   host-wide.
+
+4.2.  Resource-Specific Information
+
+   Unlike host-wide information, which is contained solely within the
+   host-meta document, resource-specific information is obtained from
+   host-meta link templates, as well as from linked LRDD documents.
+
+   When looking for resource-specific information, the client constructs
+   a resource descriptor by collecting and processing all the host-meta
+   link templates.  For each link template:
+
+   1.  The client applies the URI of the desired resource to the
+       template, producing a resource-specific link.
+
+   2.  If the link's relation type is other than "lrdd", the client adds
+       the link to the resource descriptor in order.
+
+   3.  If the link's relation type is "lrdd":
+
+       3.1.  The client obtains the LRDD document by following the
+             scheme-specific rules for the LRDD document URI.  If the
+             document URI scheme is "http" or "https", the document is
+             obtained via an HTTP "GET" request to the identified URI.
+             If the HTTP response status code is 301, 302, or 307, the
+             client MUST follow the redirection response and repeat the
+             request with the provided location.
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                    [Page 9]
+
+RFC 6415                        host-meta                   October 2011
+
+
+       3.2.  The client adds any links found in the LRDD document to the
+             resource descriptor in order, except for any link using the
+             "lrdd" relation type (processing is limited to a single
+             level of inclusion).  When adding links, the client SHOULD
+             retain any extension attributes and child elements if
+             present (e.g., <Property> or <Title> elements).
+
+       3.3.  The client adds any resource properties found in the LRDD
+             document to the resource descriptor in order (e.g., <Alias>
+             or <Property> child elements of the LRDD document <XRD>
+             root element).
+
+5.  Security Considerations
+
+   The host-meta document is designed to be used by other applications
+   explicitly "opting-in" to use the facility.  Therefore, any such
+   application MUST review the specific security implications of using
+   host-meta documents.  By itself, this specification does not provide
+   any protections or guarantees that any given host-meta document is
+   under the control of the appropriate entity as required by each
+   application.
+
+   The metadata returned by the host-meta resource is presumed to be
+   under the control of the appropriate authority and representative of
+   all the resources described by it.  If this resource is compromised
+   or otherwise under the control of another party, it may represent a
+   risk to the security of the server and data served by it, depending
+   on the applications using it.
+
+   Applications utilizing the host-meta document where the authenticity
+   of the information is necessary MUST require the use of the HTTPS
+   protocol and MUST NOT produce a host-meta document using other means.
+   In addition, such applications MUST require that any redirection
+   leading to the retrieval of a host-meta document also utilize the
+   HTTPS protocol.
+
+   Since the host-meta document is authoritative for the entire host,
+   not just the authority (combination of scheme, host, and port) of the
+   host-meta document server, applications MUST ensure that using a
+   host-meta document for another URI authority does not represent a
+   potential security exploit.
+
+   Protocols using host-meta templates must evaluate the construction of
+   their templates as well as any protocol-specific variables or syntax
+   to ensure that the templates cannot be abused by an attacker.  For
+   example, a client can be tricked into following a malicious link due
+   to a poorly constructed template that produces unexpected results
+   when its variable values contain unexpected characters.
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 10]
+
+RFC 6415                        host-meta                   October 2011
+
+
+6.  IANA Considerations
+
+6.1.  The "host-meta" Well-Known URI
+
+   This specification registers the "host-meta" well-known URI in the
+   Well-Known URI Registry as defined by [RFC5785].
+
+   URI suffix:  host-meta
+
+   Change controller:  IETF
+
+   Specification document(s):  RFC 6415
+
+   Related information:  The "host-meta" documents obtained from the
+      same host using the HTTP and HTTPS protocols (using default ports)
+      MUST be identical.
+
+6.2.  The "host-meta.json" Well-Known URI
+
+   This specification registers the "host-meta.json" well-known URI in
+   the Well-Known URI Registry as defined by [RFC5785].
+
+   URI suffix:  host-meta.json
+
+   Change controller:  IETF
+
+   Specification document(s):  RFC 6415
+
+   Related information:  The "host-meta.json" documents obtained from
+      the same host using the HTTP and HTTPS protocols (using default
+      ports) MUST be identical.
+
+6.3.  The "lrdd" Relation Type
+
+   This specification registers the "lrdd" relation type in the Link
+   Relation Type Registry defined by [RFC5988]:
+
+   Relation Name:  lrdd
+
+   Description:  Refers to further information about the link's context,
+      expressed as a LRDD ("Link-based Resource Descriptor Document")
+      resource.  See RFC 6415 for information about processing this
+      relation type in host-meta documents.  When used elsewhere, it
+      refers to additional links and other metadata.  Multiple instances
+      indicate additional LRDD resources.  LRDD resources MUST have an
+      "application/xrd+xml" representation, and MAY have others.
+
+   Reference:  RFC 6415
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 11]
+
+RFC 6415                        host-meta                   October 2011
+
+
+Appendix A.  JRD Document Format
+
+   The JRD document format -- a general-purpose XRD 1.0 representation
+   -- uses the JavaScript Object Notation (JSON) format defined in
+   [RFC4627].  JRD uses the same elements and processing rules described
+   in Section 3.1.  The JRD format is designed to include the same base
+   functionality provided by the XML format, with the exception of
+   extensibility, as extensibility is beyond the scope of this
+   specification.
+
+   The client MAY request a JRD representation using the HTTP "Accept"
+   request header field with a value of "application/json".  The server
+   MUST include the HTTP "Content-Type" response header field with a
+   value of "application/json".  Any other "Content-Type" value (or lack
+   thereof) indicates that the server does not support the JRD format.
+
+   Alternatively, the client MAY request a JRD representation by
+   requesting the "host-meta.json" well-known document, by making a GET
+   request for "/.well-known/host-meta.json", following the same process
+   used for "/.well-known/host-meta".  If the server does not support
+   serving a JRD representation at this location, the server MUST
+   respond with an HTTP 404 (Not Found) status code.
+
+   XRD elements are serialized into a JSON object as follows:
+
+   o  The XML document declaration and "XRD" element are discarded.
+
+   o  The "Subject" element is included as a name/value pair with the
+      name 'subject', and value included as a string.
+
+   o  The "Expires" element is included as a name/value pair with the
+      name 'expires', and value included as a string.
+
+   o  "Alias" elements are included as a single name/value pair with the
+      name 'aliases', and value a string array containing the values of
+      each element in order.
+
+   o  "Property" elements are included as a single name/value pair with
+      the name 'properties', and value an object with each element
+      included as a name/value pair with the value of the "type"
+      attribute as name, and element value included as a string value.
+      The values of properties with empty values (i.e., using the
+      REQUIRED "xsi:nil='true'" attribute) are included as null.  If
+      more than one "Property" element is present with the same "type"
+      attribute, only the last instance is included.
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 12]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   o  "Link" elements are included as a single name/value pair with the
+      name 'links', and value an array with each element included as an
+      object.  Each attribute is included as a name/value pair with the
+      attribute name as name, and value included as a string.
+
+   o  "Link" child "Property" elements are included using the same
+      method as XRD-level "Property" elements using a name/value pair
+      inside the link object.
+
+   o  "Link" child "Title" elements are included as a single object with
+      the name 'titles', and value an object with each element included
+      as a name/value pair with the value of the "xml:lang" attribute as
+      name, and element value included as a string value.  The names of
+      elements without an "xml:lang" attribute are added with the name
+      'default'.  If more than one "Title" element is present with the
+      same (or no) "xml:lang" attribute, only the last instance is
+      included.
+
+   o  The conversion of any other element is left undefined.
+
+   For example, the following XRD document...
+
+    <?xml version='1.0' encoding='UTF-8'?>
+    <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
+         xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
+
+      <Subject>http://blog.example.com/article/id/314</Subject>
+      <Expires>2010-01-30T09:30:00Z</Expires>
+
+      <Alias>http://blog.example.com/cool_new_thing</Alias>
+      <Alias>http://blog.example.com/steve/article/7</Alias>
+
+      <Property type='http://blgx.example.net/ns/version'>1.2</Property>
+      <Property type='http://blgx.example.net/ns/version'>1.3</Property>
+      <Property type='http://blgx.example.net/ns/ext' xsi:nil='true' />
+
+      <Link rel='author' type='text/html'
+            href='http://blog.example.com/author/steve'>
+        <Title>About the Author</Title>
+        <Title xml:lang='en-us'>Author Information</Title>
+        <Property type='http://example.com/role'>editor</Property>
+      </Link>
+
+      <Link rel='author' href='http://example.com/author/john'>
+        <Title>The other guy</Title>
+        <Title>The other author</Title>
+      </Link>
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 13]
+
+RFC 6415                        host-meta                   October 2011
+
+
+      <Link rel='copyright'
+            template='http://example.com/copyright?id={uri}' />
+    </XRD>
+
+   ...is represented by the following JRD document:
+
+    {
+      "subject":"http://blog.example.com/article/id/314",
+      "expires":"2010-01-30T09:30:00Z",
+
+      "aliases":[
+        "http://blog.example.com/cool_new_thing",
+        "http://blog.example.com/steve/article/7"],
+
+      "properties":{
+        "http://blgx.example.net/ns/version":"1.3",
+        "http://blgx.example.net/ns/ext":null
+      },
+
+      "links":[
+        {
+          "rel":"author",
+          "type":"text/html",
+          "href":"http://blog.example.com/author/steve",
+          "titles":{
+            "default":"About the Author",
+            "en-us":"Author Information"
+          },
+          "properties":{
+            "http://example.com/role":"editor"
+          }
+        },
+        {
+          "rel":"author",
+          "href":"http://example.com/author/john",
+          "titles":{
+            "default":"The other author"
+          }
+        },
+        {
+          "rel":"copyright",
+          "template":"http://example.com/copyright?id={uri}"
+        }
+      ]
+    }
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 14]
+
+RFC 6415                        host-meta                   October 2011
+
+
+   Note that the "Subject" and "Alias" elements are NOT RECOMMENDED in
+   the context of host-meta documents, and are included in the example
+   for completeness only.
+
+Appendix B.  Acknowledgments
+
+   The authors would like to acknowledge the contributions of everyone
+   who provided feedback and use cases for this specification -- in
+   particular, Dirk Balfanz, DeWitt Clinton, Eve Maler, Breno de
+   Medeiros, Brad Fitzpatrick, James Manger, Will Norris, Mark
+   Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.
+
+Normative References
+
+   [OASIS.XRD-1.0]
+              Hammer-Lahav, E., Ed., and W. Norris, Ed., "Extensible
+              Resource Descriptor (XRD) Version 1.0", November 2010,
+              <http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, January 2005.
+
+   [RFC4627]  Crockford, D., "The application/json Media Type for
+              JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              January 2008.
+
+   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+              Uniform Resource Identifiers (URIs)", RFC 5785,
+              April 2010.
+
+   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.
+
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 15]
+
+RFC 6415                        host-meta                   October 2011
+
+
+Authors' Addresses
+
+   Eran Hammer-Lahav (editor)
+
+   EMail: eran@hueniverse.com
+   URI:   http://hueniverse.com
+
+
+   Blaine Cook
+
+   EMail: romeda@gmail.com
+   URI:   http://romeda.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hammer-Lahav & Cook          Standards Track                   [Page 16]
+