One document matched: draft-hammer-discovery-05.xml
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category='info' ipr='trust200902' docName='draft-hammer-discovery-05'>
<?rfc strict='yes' ?>
<?rfc toc='yes' ?>
<?rfc tocdepth='3' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<front>
<title abbrev='LRDD'>LRDD: Link-based Resource Descriptor Discovery</title>
<author initials='E' surname='Hammer-Lahav' fullname='Eran Hammer-Lahav'>
<organization>
Yahoo!
</organization>
<address>
<email>eran@hueniverse.com</email>
<uri>http://hueniverse.com</uri>
</address>
</author>
<date year='2010'/>
<abstract>
<t>
LRDD (pronounced 'lard') provides a process for obtaining information about a resource
identified by a Uniform Resource Identifier (URI). The 'information about a resource' - a
resource descriptor - provides machine-readable information that aims to increase
interoperability and enhance interactions with the resource. LRDD provides a narrow and
well-defined set of rules for obtaining and processing link-based descriptors (found in
multiple sources such as HTTP headers, document markup, and resource descriptors) which
are often required for security and consistent client behavior.
</t>
</abstract>
<note title='Editorial Note (to be removed by RFC Editor)'>
<t>
Please discuss this draft on the
<eref target='https://www.ietf.org/mailman/listinfo/apps-discuss'>apps-discuss@ietf.org</eref>
mailing list.
</t>
</note>
</front>
<middle>
<section title='Introduction'>
<t>
LRDD defines a simple process for locating resource descriptors for URI-identified
resources. Resource descriptors are machine-readable documents that provide information
about resources (resource metadata) for the purpose of promoting interoperability and
assist in interacting with unknown resources that support known interfaces.
</t>
<t>
For example, a web page about an upcoming meeting can provide in its descriptor the
location of the meeting organizer's free/busy information to potentially negotiate a
different time. A social network profile page descriptor can identify the location of the
user's address book as well as accounts on other sites. A web service implementing an API
with optional components can advertise which of these are supported.
</t>
<t>
Given the wide range of metadata needs, no single descriptor format or retrieval method can
adequately accommodate every use case. While there are many methods for obtaining resource
descriptors (e.g., links, HTTP headers, WebDAV's PROPFIND <xref target='RFC4918' />,
HTTP OPTIONS, URIQA's MGET <xref target='URIQA' />), LRDD utilizes the Web Linking
framework defined in <xref target='I-D.nottingham-http-link-header'/>. LRDD defines a
narrow profile of Web Linking for obtaining and processing link-based descriptors to
accommodate the common discovery needs of many Web protocols.
</t>
<t>
In LRDD, the resource descriptor is not a single document but the aggregation of links
obtained from three link sources (when applicable and available). The resource descriptor
is constructed by determining the order in which to process the three link sources and
aggregating the links and metadata contained in each source:
<list style='symbols'>
<t>
host-meta document - links generated by applying the resource URI to the link templates
provided by the host's host-meta document as defined in
<xref target='I-D.hammer-hostmeta' />.
</t>
<t>
HTTP response header - links included in the HTTP response header to an
<xref target='RFC2616'>HTTP</xref> <spanx style='verb'>HEAD</spanx> or
<spanx style='verb'>GET</spanx> resource representation request using the
<spanx style='verb'>Link</spanx> header field defined in
<xref target='I-D.nottingham-http-link-header'/>.
</t>
<t>
Document markup - links included in the resource representation markup using the
<LINK> element.
</t>
</list>
</t>
<t>
The resource descriptor also includes additional links and metadata obtained from LRDD
documents - <xref target='OASIS.XRD-1.0'>XRD</xref> documents linked to from one of the
same three sources using the <spanx style='verb'>lrdd</spanx> relation type.
</t>
<t>
The client usually looks for a link with a specific relation type or other metadata. In
such cases, the client does not need to construct the entire resource descriptor, but
instead, process the various sources in their prescribed order until the desired
information is found. While the process described in <xref target='construction' /> is meant
to construct the entire resource descriptor, the client MAY stop processing as soon as it
finds the desired information.
</t>
<section title='Example' anchor='example'>
<t>
In this example, an article published by a website allows readers to post comments and
provide the web address of their own blog. The article page includes an avatar (a photo
of the reader) when displaying comments. The photo is obtained by performing discovery on
the web address provided by the reader, if supported by the reader's blog.
</t>
<t>
After receiving a comment from Jane which has her own blog at
<spanx style='verb'>http://jane.example.com/blog</spanx>, the website performs LRDD
discovery to try and obtain Jane's photo.
</t>
<figure anchor='Figure 1'>
<preamble>
First, the website determines the source priority order - the order in which it looks
for links in the various sources - for Jane's blog by fetching its host-meta document
from <spanx style='verb'>https://jane.example.com/.well-known/host-meta</spanx>:
</preamble>
<artwork>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:hm='http://host-meta.net/ns/1.0'>
<hm:Host>jane.example.com</hm:Host>
<Property type='http://lrdd.net/priority/resource' />
<Link rel='lrdd' template='http://jane.example.com?lrdd={uri}' />
<Link rel='contents' template='http://example.com?c={uri}' />
</XRD>
]]>
</artwork>
<postamble>
which indicates the blog is using Resource-priority (giving higher priority to links
provided by the resource itself over those defined by the global host policy). Since
Jane's blog uses Resource-priority, the website looks for
<spanx style='verb'>avatar</spanx> type links in this order: <LINK> elements in
the blog document's markup, HTTP Link headers in the blog document HTTP response, and
last in the host-meta document using link templates. Note that the
<spanx style='verb'>avatar</spanx> relation type is used for illustration purposes only
and at this time is not a registered relation type.
</postamble>
</figure>
<figure>
<preamble>
To obtain a markup representation of Jane's blog, the website makes an HTTP
<spanx style='verb'>GET</spanx> request to <spanx style='verb'>http://jane.example.com/blog</spanx>:
</preamble>
<artwork>
<![CDATA[
GET /blog HTTP/1.1
Host: jane.example.com
Accept: text/html
]]>
</artwork>
</figure>
<figure>
<preamble>
And receives back (HTML schema simplified for display purposes):
</preamble>
<artwork>
<![CDATA[
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Link: <http://jane.example.com/author>; rel='author'
<HTML>
<HEAD>
<LINK href='http://jane.example.com/image' rel='avatar' />
</HEAD>
<BODY>
<H1>Jane's Blog</H1>
</BODY>
</HTML>
]]>
</artwork>
</figure>
<t>
The document's HTML markup includes the desired link. The website can fetch Jane's photo
from <spanx style='verb'>http://jane.example.com/image</spanx>.
</t>
<t>
After obtaining Jane's photo, the website looks for a short description of Jane to
include with her comment. It performs another LRDD discovery, this time looking for an
<spanx style='verb'>author</spanx> link.
</t>
<t>
Repeating the same process, the website looks for qualified <LINK> elements in
Jane's blog HTML markup and finds none. It then looks for a LRDD document - a descriptor
document containing additional information about the resource - which uses the
<spanx style='verb'>lrdd</spanx> link relation. It finds none in the HTML document.
</t>
<t>
In Resource-priority, the next source is the HTTP header included in the resource
representation response. The HTTP header (shown above with the HTML response) includes a
qualified link to Jane's author page.
</t>
<figure>
<artwork>
<![CDATA[
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Link: <http://jane.example.com/author>; rel='author'
]]>
</artwork>
</figure>
<t>
Before the website can display Jane's photo and description, it needs to find the copyright
license used by Jane's blog. It performs another LRDD discovery looking for a link with
a <spanx style='verb'>copyright</spanx> relation type. It fails to find such link in the
HTML markup as well as a markup link to a LRDD document. It tries and fails to find a
<spanx style='verb'>copyright</spanx> link in the HTTP response header or a link to a LRDD
document.
</t>
<t>
After exhausting the first two sources, the website proceeds to the host-meta source
(<xref target='Figure 1' />), and looks for link templates. It fails to find a link to a
copyright statement, but it does find a link to a LRDD document:
</t>
<figure>
<artwork>
<![CDATA[
<Link rel='lrdd' template='http://jane.example.com?lrdd={uri}' />
]]>
</artwork>
</figure>
<t>
The website obtains the LRDD document for Jane's blog by applying the blog's URI to the template:
</t>
<figure>
<artwork>
<![CDATA[
http://jane.example.com?lrdd=http%3A%2F%2Fjane.example.com%2Fblog
]]>
</artwork>
</figure>
<figure>
<preamble>
and obtains the LRDD document for Jane's blog:
</preamble>
<artwork>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://jane.example.com/blog</Subject>
<Property type='http://example.com/version'>2.0</Property>
<Link rel='copyright' href='http://jane.example.com/copyright' />
</XRD>
]]>
</artwork>
</figure>
<t>
The LRDD document provided by the host-meta link template includes a link to the
copyright statement. The website now has all the information it needs to display Jane's
comment along with her photo and description on the article page.
</t>
</section>
<section title='Notational Conventions'>
<t>
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT',
'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in
<xref target='RFC2119' />.
</t>
</section>
</section>
<section title='Link Source Priority Order' anchor='order'>
<t>
The client MUST first determine the host source priority order. To ensure consistent client
behavior and to enable hosts to set their own security policy with regard to metadata
authority, LRDD provides two processing profiles:
<list style='symbols'>
<t>
Host priority - priority is given to links set by the host policy (via
host-meta and HTTP response headers) over those set by each individual resources (via
the document markup). The client MUST process the three sources in the following order:
host-meta document, HTTP response header, and document markup.
</t>
<t>
Resource priority - priority is given to the individual resource over the policies of
the host. The client MUST process the three sources in the following order: document
markup, HTTP response header, and host-meta document.
</t>
</list>
</t>
<t>
Host priority is the default source priority order. Hosts that wish to use
resource priority MUST declare it by setting the LRDD priority property in their
host-meta document: <spanx style='verb'>http://lrdd.net/priority/resource</spanx>. The
priority property element does not have a value.
</t>
<figure>
<preamble>
For example:
</preamble>
<artwork>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
xmlns:hm='http://host-meta.net/ns/1.0'>
<hm:Host>example.com</hm:Host>
<Property type='http://lrdd.net/priority/resource' />
</XRD>
]]>
</artwork>
</figure>
</section>
<section title='Resource Descriptor Construction' anchor='construction'>
<t>
To construct the resource descriptor, the client determines the source priority order as
described in <xref target='order' />, and processes each of the three
<xref target='sources'>sources</xref> as follows:
<list style='numbers'>
<t>
Obtain and processes the source to produce an ordered list of links as described for
each source in <xref target='sources' />.
</t>
<t>
Add any link found to the resource descriptor links list in order, except for any link
using the <spanx style='verb'>lrdd</spanx> relation type.
</t>
<t>
For each link using the <spanx style='verb'>lrdd</spanx> relation type and
<spanx style='verb'>application/xrd+xml</spanx> media type (if present):
<list style='letters'>
<t>
Obtain the LRDD document by following the scheme-specific rules for the LRDD
document URI. If the document URI scheme is <spanx style='verb'>http</spanx> or
<spanx style='verb'>https</spanx>, the document is obtained via an HTTP
<spanx style='verb'>GET</spanx> 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. If a redirection response
results in another 301, 302, or 307 response, the client SHOULD repeat the request
with the provided location as many times as reasonable, making sure not to enter
into a loop if a location URI repeats itself. The client MUST only process the
document if it was received with an HTTP 200 (OK) status code and is a valid XRD
document per <xref target='OASIS.XRD-1.0' />.
</t>
<t>
Add any link found in the LRDD document to the resource descriptor links list in
order, except for any link using the <spanx style='verb'>lrdd</spanx> relation
type. When adding links, the client SHOULD retain any extension attributes and
child elements if present (e.g. <Property> or <Title> elements).
</t>
<t>
Add any resource properties found in the LRDD document to the resource descriptor
metadata list in order (e.g. <Alias< or <Property> child elements of
the <XRD> root element).
</t>
</list>
</t>
</list>
</t>
<figure>
<preamble>
For example, the resource descriptor of Jane's blog as described in
<xref target='example' /> and expressed as an XRD document (for illustration purposes
only) is:
</preamble>
<artwork>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://jane.example.com/blog</Subject>
<Property type='http://example.com/version'>2.0</Property>
<Link rel='avatar' href='http://jane.example.com/image' />
<Link rel='author' href='http://jane.example.com/author' />
<Link rel='contents'
href='http://example.com?c=http%3A%2F%2Fjane.example.com%2Fblog' />
<Link rel='copyright' href='http://jane.example.com/copyright' />
</XRD>
]]>
</artwork>
</figure>
<figure>
<preamble>
Using the same example, if Jane's host-meta used host priority instead of resource
priority, the resource descriptor of Jane's blog would be:
</preamble>
<artwork>
<![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Subject>http://jane.example.com/blog</Subject>
<Property type='http://example.com/version'>2.0</Property>
<Link rel='contents'
href='http://example.com?c=http%3A%2F%2Fjane.example.com%2Fblog' />
<Link rel='copyright' href='http://jane.example.com/copyright' />
<Link rel='author' href='http://jane.example.com/author' />
<Link rel='avatar' href='http://jane.example.com/image' />
</XRD>
]]>
</artwork>
</figure>
</section>
<section title='Link Sources' anchor='sources'>
<t>
Each of the link sources supported by LRDD presents a different set of requirements and
benefits. The criteria used to determine which sources a server supports are based on a
combination of factors:
<list style='symbols'>
<t>
The ability to offer and obtain a representation of the resource by dereferencing its
URI.
</t>
<t>
The availability of a markup document representation supporting <LINK> elements
compatible with <xref target='I-D.nottingham-http-link-header' />.
</t>
<t>
The availability of an HTTP representation of the resource and the ability to provide
and access link information in its response header.
</t>
<t>
The ability to offer and process a host-meta document.
</t>
</list>
</t>
<section title='host-meta Document'>
<t>
The host-meta document source is available for any resource identified by a URI
with an authority that supports the host-meta document as defined in
<xref target='I-D.hammer-hostmeta' />. This method does not require obtaining any
representation of the resource, and operates solely using the resource URI.
</t>
<t>
Links between the resource URI and other resources are expressed using link templates
as defined by <xref target='I-D.hammer-hostmeta' /> section 3.2. By applying the
host-wide templates to an individual resource URI, a resource-specific link is
generated which can be used to express links without the need to access or provide a
representation for the resource.
</t>
<t>
The client processes the host-meta document, searches for link templates and applies the
resource URI to produce a set of links. The client MUST retain the order of links as
present in the host-meta document. Any links contained in the host-meta document not
using the <spanx style='verb'>template</spanx> attribute MUST be ignored and excluded
from the resource descriptor (they are still valid for other purposes).
</t>
<figure>
<preamble>
For example, the resource URI <spanx style='verb'>http://example.com/x</spanx> and the
following host-meta link template:
</preamble>
<artwork>
<![CDATA[
<Link rel='author' template='http://example.com?author={uri}' />
]]>
</artwork>
<postamble>
generate an <spanx style='verb'>author</spanx> link between
<spanx style='verb'>http://example.com/x</spanx> and
<spanx style='verb'>http://example.com?author=http%3A%2F%2Fexample.com%2Fx</spanx>.
</postamble>
</figure>
</section>
<section title='HTTP Response Headers'>
<t>
The HTTP response header source is limited to resources for which an HTTP
<spanx style='verb'>GET</spanx> or <spanx style='verb'>HEAD</spanx> request returns
a valid representation of the resource. This source uses the
<spanx style='verb'>Link</spanx> header field defined in
<xref target='I-D.nottingham-http-link-header' /> and requires the retrieval of a
resource representation header.
</t>
<figure>
<preamble>
For example:
</preamble>
<artwork>
<![CDATA[
Link: <http://example.com?author=http%3A%2F%2Fexample.com%2Fx>;
rel='author'
]]>
</artwork>
</figure>
<t>
The client obtains the HTTP response header links by making an HTTP (or HTTPS)
<spanx style='verb'>GET</spanx> or <spanx style='verb'>HEAD</spanx> request to the
resource URI.
</t>
<t>
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. If a redirection
response results in another 301, 302, or 307 response, the client SHOULD repeat the
request with the provided location as many times as reasonable, making sure not to enter
into a loop if a location URI repeats itself.
</t>
<t>
The client MUST only process the header if the HTTP response includes a 200, 204, 206, or
304 status code. The client processes the response header and searches for
<spanx style='verb'>Link</spanx> header fields. The client MUST retain the order of links
as present in the response header.
</t>
<t>
Link headers can include multiple relation types in a single
<spanx style='verb'>rel</spanx> attribute (for example
<spanx style='verb'>rel="license copyright"</spanx>). The client MUST properly process such
multiple relation types <spanx style='verb'>rel</spanx> attributes as defined by
<xref target='I-D.nottingham-http-link-header' />.
</t>
</section>
<section title='Document Markup'>
<t>
The document markup source is limited to resources with an available markup
representation that supports typed relations using the <LINK> element, such as
HTML <xref target='W3C.REC-html401-19991224' />, XHTML
<xref target='W3C.REC-xhtml1-20020801' />, and Atom <xref target='RFC4287' />. Other
markup formats are permitted as long as the semantics of their <LINK> elements are
fully compatible with the link framework defined in
<xref target='I-D.nottingham-http-link-header' />.
</t>
<figure>
<preamble>
For example:
</preamble>
<artwork>
<![CDATA[
<LINK href='http://example.com?author=http%3A%2F%2Fexample.com%2Fx'
rel='author'>
]]>
</artwork>
</figure>
<t>
The client obtains the document markup by retrieving a representation of the resource
using the applicable transport for that resource URI. When using HTTP (or HTTPS), the
client obtains the document markup by making a <spanx style='verb'>GET</spanx> request to
the resource URI.
</t>
<t>
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. If a redirection
response results in another 301, 302, or 307 response, the client SHOULD repeat the
request with the provided location as many times as reasonable, making sure not to enter
into a loop if a location URI repeats itself.
</t>
<t>
The client MUST only process the document markup if the HTTP response includes a 200 (OK)
status code. The client processes the document markup and searches for
<spanx style='verb'>LINK</spanx> elements. The client MUST retain the order of links as
present in the document markup.
</t>
<t>
The client MUST obey the document markup schema and ignore any invalid elements (such
as <LINK> elements outside the <HEAD> section of an HTML document). This is
done to avoid unintentional markup from other parts of the document to be used for
discovery purposes, which can have vast impact on usability and security.
</t>
<t>
Some <LINK> elements allow multiple relation types in a single
<spanx style='verb'>rel</spanx> attribute (for example
<spanx style='verb'>rel='license copyright'</spanx>). The client MUST properly process
such multiple relation <spanx style='verb'>rel</spanx> attributes as defined by the
format specification.
</t>
</section>
</section>
<section anchor='Security' title='Security Considerations'>
<t>
The methods used to perform discovery are not secure, private or integrity-guaranteed, and
due caution should be exercised when using them. Applications that perform LRDD SHOULD
consider the attack vectors opened by automatically following, trusting, or otherwise using
links gathered from document markups, HTTP response headers, or host-meta documents.
</t>
</section>
<section title='IANA Considerations'>
<section title="The 'lrdd' Relation Type">
<t>
This specification registers the <spanx style='verb'>lrdd</spanx> relation type in the
Link Relation Type Registry defined by <xref target='I-D.nottingham-http-link-header' />:
<list style='hanging'>
<t hangText='Relation Name:'>
lrdd
</t>
<t hangText='Description:'>
Identifies a resource descriptor for the link's context used by the LRDD protocol.
</t>
<t hangText='Reference:'>
[[ This specification ]]
</t>
</list>
</t>
</section>
</section>
<appendix title='Acknowledgments'>
<t>
Inspiration for this memo derived from previous work on a descriptor format called XRDS-Simple,
which in turn derived from another descriptor format, XRDS. Previous discovery workflows
include Yadis which is currently used by the OpenID community. While suffering from
significant shortcomings, Yadis was a breakthrough approach to performing discovery using
extremely restricted hosting environments, and this memo has strived to preserve as much of
that spirit as possible.
</t>
<t>
The author wishes to thanks the OASIS XRI TC and WebFinger communities for their support,
encouragement, and enthusiasm for this work. Special thanks go to Phil Archer, Lisa Dusseault,
Joseph Holsten, Mark Nottingham, John Panzer, Drummond Reed, and Jonathan Rees for their
invaluable feedback.
</t>
</appendix>
<appendix title='Document History'>
<t>
[[ to be removed by the RFC editor before publication as an RFC ]]
</t>
<t>
-05
<list style='symbols'>
<t>
Many editorial changes, cleanup.
</t>
<t>
Changed the processing flow to focus on a aggregation. Clients can always stop when
they find what they need.
</t>
<t>
Clarified redirections and HTTP status codes for valid document markups and response
headers.
</t>
<t>
Removed restrictions on multiple LRDD documents.
</t>
</list>
</t>
<t>
-04
<list style='symbols'>
<t>
Changed focus to a narrow and well-defined discovery process.
</t>
<t>
Removed analysis appendix and discussion of discovery types and removed
informative references.
</t>
<t>
Expanded the descriptor definition to include links as well as LRDD documents, moving
away from the single-document approach.
</t>
<t>
Moved the Link-Pattern field and template syntax to new host-meta draft.
</t>
<t>
Updated references.
</t>
<t>
Added example.
</t>
</list>
</t>
<t>
-03
<list style='symbols'>
<t>
Added protocol name LRDD (pronounced 'lard').
</t>
<t>
Fixed Link-Pattern examples to include missing semicolons.
</t>
</list>
</t>
<t>
-02
<list style='symbols'>
<t>
Changed focus from an HTTP-based process to Link-based process.
</t>
<t>
Completely revised and restructured document for better clarity.
</t>
<t>
Realigned the methods to produce consistent results and changed the way
redirections and client-errors are handled.
</t>
<t>
Updated to use newer version of site-meta, now called host-meta, including
a new plaintext-based format to replace the previous XML format.
</t>
<t>
Renamed Link-Template to Link-Pattern to avoid future conflict with a previously
proposed Link-Template HTTP header.
</t>
<t>
Removed support for the 'scheme' Link-Template parameter.
</t>
<t>
Replaced restrictions with interoperability recommendations.
</t>
<t>
Added IANA considerations per new host-meta registry requirements.
</t>
</list>
</t>
<t>
-01
<list style='symbols'>
<t>
Rename 'resource discovery' to 'descriptor discovery'.
</t>
<t>
Added informative reference to Metalink.
</t>
<t>
Clarified that the resource descriptor URI can use any URI scheme, not just 'http' or 'https'.
</t>
<t>
Removed comment regarding redirects when using <LINK> Elements.
</t>
<t>
Clarified that HTTPS must be used with 'https' URIs for both Link headers and host-meta retrieval.
</t>
<t>
Removed DNS verification step for host-meta with schemes other then 'http' and 'https'. Replaced with
a general discussion of authority and a security consideration comment.
</t>
<t>
Organized host-meta section into another sub-section level.
</t>
<t>
Enlarged the template vocabulary from a single 'uri' variable to include smaller URI components.
</t>
<t>
Added informative reference to RFC 2295 in analysis appendix.
</t>
</list>
</t>
<t>
-00
<list style='symbols'>
<t>
Initial draft.
</t>
</list>
</t>
</appendix>
</middle>
<back>
<references title='Normative References'>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xhtml1-20020801.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-http-link-header-08.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hammer-hostmeta-05.xml'?>
</references>
<references title='Informative References'>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'?>
<reference anchor='OASIS.XRD-1.0' target='http://www.oasis-open.org/committees/download.php/36542/xrd-1.0-wd15.html'>
<front>
<title>Extensible Resource Descriptor (XRD) Version 1.0 (work in progress)</title>
<author initials='E.H' surname='Hammer-Lahav' fullname='Eran'>
<organization />
</author>
<author initials='W.N' surname='Norris' fullname='Will Norris'>
<organization />
</author>
</front>
<format type='HTML' target='http://www.oasis-open.org/committees/download.php/36542/xrd-1.0-wd15.html' />
</reference>
<reference anchor='URIQA' target='http://sw.nokia.com/uriqa/URIQA.html'>
<front>
<title>The URI Query Agent Model</title>
<author initials='' surname='' fullname=''>
<organization>Nokia</organization>
</author>
</front>
<format type='HTML' target='http://sw.nokia.com/uriqa/URIQA.html' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:24:50 |