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, . [1] Author's Address Eran Hammer-Lahav Yahoo! Email: eran@hueniverse.com URI: http://hueniverse.com Hammer-Lahav Expires April 22, 2010 [Page 6]