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 23, 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.

Table of Contents

1.  Introduction
2.  Notational Conventions
3.  Metadata Scope
4.  Discovering host-meta Documents
5.  Document Structure
6.  Security Considerations
7.  IANA Considerations
    7.1.  The host-meta Well-Known URI
Appendix A.  Acknowledgments
Appendix B.  Document History
8.  Normative References
§  Author's Address

1.  Introduction

[[ The host-meta document was originally proposed in [I‑D.nottingham‑site‑meta] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known URIs,” September 2009.). 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] (Marchiori, M., “The Platform for Privacy Preferences 1.0 (P3P1.0) Specification,” April 2002.) 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] (Dusseault, L., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV),” June 2007.)), 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] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known URIs,” September 2009.) 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] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)).

Please discuss this draft on the apps-discuss@ietf.org 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Metadata Scope

The metadata returned by the host-meta resource is scoped to apply to the entire authority (in the URI [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), 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. ]]

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] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known URIs,” September 2009.).

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] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known URIs,” September 2009.) 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 ]]

-00

• Initial draft.

8. Normative References

Author's Address