Network Working Group E. Hammer-Lahav
Internet-Draft Yahoo!
Intended status: Informational October 19, 2009
Expires: April 22, 2010
Host-Meta: Web Host Metadata
draft-hammer-hostmeta-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo describes a method for locating host-specific metadata for
the Web using a "well-known location" XRD document.
Hammer-Lahav Expires April 22, 2010 [Page 1]
Internet-Draft Host-Meta: Web Host Metadata October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Metadata Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discovering host-meta Documents . . . . . . . . . . . . . . . . 4
5. Document Structure . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.1. The host-meta Well-Known URI . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5
Appendix B. Document History . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Hammer-Lahav Expires April 22, 2010 [Page 2]
Internet-Draft Host-Meta: Web Host Metadata October 2009
1. Introduction
[[ The host-meta document was originally proposed in
[I-D.nottingham-site-meta]. That draft was changed from a single
document-based list of metadata links to a registry of well-known
locations documents under a fixed path prefix. This memo redefines
the purpose and syntax of the host-meta document. ]]
It is increasingly common for Web-based protocols to require the
discovery of policy or metadata before making a request. For
example, the Robots Exclusion Protocol specifies a way for automated
processes to obtain permission to access resources; likewise, the
Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-
agents how to discover privacy policy beforehand.
While there are several ways to access per-resource metadata (e.g.,
HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated
with them often precludes their use in these scenarios. In addition,
there is no URI or resource available to associate host metadata with
which lead some protocols use the root HTTP resource for this
purpose.
When this happens, it is common to designate a "well-known location"
for such metadata, so that it can be easily retrieved.
[I-D.nottingham-site-meta] defines a registry for such "well-known
locations" which addresses the issues associated with their use (i.e.
name collisions and violating the namespace authority of the domain
owner).
Web protocols have a wide range of metadata requirements. However,
it is common for Web protocols to define metadata that is concise,
does not require complex or custom syntax, and does not justifies the
registration and retrival of multiple protocol-specific "well-known
locations". This memo defines a simple, general-purpose metadata
document for an entire authority (as defined by [RFC3986]).
Please discuss this draft on the apps-discuss@ietf.org [1] mailing
list.
2. Notational Conventions
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 [RFC2119].
Hammer-Lahav Expires April 22, 2010 [Page 3]
Internet-Draft Host-Meta: Web Host Metadata October 2009
3. Metadata Scope
The metadata returned by the host-meta resource is scoped to apply to
the entire authority (in the URI [RFC3986] sense) associated with it;
it does not apply to a subset, nor does it apply to other authorities
(e.g., using another port, or a different hostname in the same
domain).
Protocols MAY extend the scope of a given host-meta document. For
example, protocols can use the host-meta document served by the
default (port 80) HTTP server to describe resources other then HTTP
resources at that authority.
4. Discovering host-meta Documents
The metadata for a given authority can be discovered by dereferencing
the path '/.well-known/host-meta' on the same authority. For
example, for an HTTP URI [RFC2616], the following request would
obtain metadata for the authority "www.example.com:80":
GET /.well-known/host-meta HTTP/1.1
Host: www.example.com
The semantics of the protocol used for access to the resource apply.
Therefore, if the resource indicates the client should try a
different request (in HTTP, the 301, 302, 303 or 307 response status
code), the client SHOULD attempt to do so; note that this implies
that the host-meta document for one authority MAY be retrieved from a
different authority. Likewise, if the resource is not available or
exists (in HTTP, the 404 or 410 status code), the client SHOULD infer
that metadata is not available via this mechanism.
If a representation is successfully obtained, but is not in the
format described above, clients SHOULD infer that the authority is
using this URI for other purposes, and not process it as a host-meta
document.
To aid in this process, authorities using this mechanism SHOULD
correctly label host-meta responses with the "application/xrd+xml"
internet media type.
5. Document Structure
[[ TBD, pending normative reference to the XRD 1.0 specification. ]]
Hammer-Lahav Expires April 22, 2010 [Page 4]
Internet-Draft Host-Meta: Web Host Metadata October 2009
6. Security Considerations
The metadata returned by the host-meta resource is presumed to be
under the control of the appropriate authority and representative of
all resources contained 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
what protocols use it.
Scoping metadata to a single authority is the default in host-meta.
Thus "http://example.com/", "https://example.com", and
"http://www.example.com/" all have different host-meta documents with
seperate and non-overlapping scopes of applicability. Protocols that
change the scope of metadata without careful consideration can incur
security risks.
7. IANA Considerations
7.1. The host-meta Well-Known URI
This memo registers the 'host-meta' well-knwon URI in the Well-Known
URI Registry as defined by [I-D.nottingham-site-meta].
URI suffix: host-meta
Change controller: IETF
Specification document(s): [[ this document ]]
Related information: None
Appendix A. Acknowledgments
This memo is directly based on [I-D.nottingham-site-meta] and
incorporates prose written by Mark Nottingham.
The author would like to acknowledge the contributions of everyone
who provided feedback and use cases for this draft; in particular,
Dirk Balfanz, DeWitt Clinton, Blaine Cook, Breno de Medeiros, Brad
Fitzpatrick, Will Norris, John Panzer, and Drummond Reed.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]]
Hammer-Lahav Expires April 22, 2010 [Page 5]
Internet-Draft Host-Meta: Web Host Metadata October 2009
-00
o Initial draft.
8. Normative References
[I-D.nottingham-site-meta]
Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
URIs", draft-nottingham-site-meta-03 (work in progress),
September 2009.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[W3C.REC-P3P-20020416]
Marchiori, M., "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", World Wide Web Consortium
Recommendation REC-P3P-20020416, April 2002,
<http://www.w3.org/TR/2002/REC-P3P-20020416>.
[1] <https://www.ietf.org/mailman/listinfo/apps-discuss>
Author's Address
Eran Hammer-Lahav
Yahoo!
Email: eran@hueniverse.com
URI: http://hueniverse.com
Hammer-Lahav Expires April 22, 2010 [Page 6]
