idnits 2.17.1 draft-hammer-hostmeta-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-nottingham-site-meta-03 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hammer-Lahav 3 Internet-Draft Yahoo! 4 Intended status: Informational October 19, 2009 5 Expires: April 22, 2010 7 Host-Meta: Web Host Metadata 8 draft-hammer-hostmeta-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo describes a method for locating host-specific metadata for 47 the Web using a "well-known location" XRD document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 53 3. Metadata Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Discovering host-meta Documents . . . . . . . . . . . . . . . . 4 55 5. Document Structure . . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. The host-meta Well-Known URI . . . . . . . . . . . . . . . 5 59 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5 60 Appendix B. Document History . . . . . . . . . . . . . . . . . . . 5 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 [[ The host-meta document was originally proposed in 67 [I-D.nottingham-site-meta]. That draft was changed from a single 68 document-based list of metadata links to a registry of well-known 69 locations documents under a fixed path prefix. This memo redefines 70 the purpose and syntax of the host-meta document. ]] 72 It is increasingly common for Web-based protocols to require the 73 discovery of policy or metadata before making a request. For 74 example, the Robots Exclusion Protocol specifies a way for automated 75 processes to obtain permission to access resources; likewise, the 76 Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user- 77 agents how to discover privacy policy beforehand. 79 While there are several ways to access per-resource metadata (e.g., 80 HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated 81 with them often precludes their use in these scenarios. In addition, 82 there is no URI or resource available to associate host metadata with 83 which lead some protocols use the root HTTP resource for this 84 purpose. 86 When this happens, it is common to designate a "well-known location" 87 for such metadata, so that it can be easily retrieved. 88 [I-D.nottingham-site-meta] defines a registry for such "well-known 89 locations" which addresses the issues associated with their use (i.e. 90 name collisions and violating the namespace authority of the domain 91 owner). 93 Web protocols have a wide range of metadata requirements. However, 94 it is common for Web protocols to define metadata that is concise, 95 does not require complex or custom syntax, and does not justifies the 96 registration and retrival of multiple protocol-specific "well-known 97 locations". This memo defines a simple, general-purpose metadata 98 document for an entire authority (as defined by [RFC3986]). 100 Please discuss this draft on the apps-discuss@ietf.org [1] mailing 101 list. 103 2. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Metadata Scope 111 The metadata returned by the host-meta resource is scoped to apply to 112 the entire authority (in the URI [RFC3986] sense) associated with it; 113 it does not apply to a subset, nor does it apply to other authorities 114 (e.g., using another port, or a different hostname in the same 115 domain). 117 Protocols MAY extend the scope of a given host-meta document. For 118 example, protocols can use the host-meta document served by the 119 default (port 80) HTTP server to describe resources other then HTTP 120 resources at that authority. 122 4. Discovering host-meta Documents 124 The metadata for a given authority can be discovered by dereferencing 125 the path '/.well-known/host-meta' on the same authority. For 126 example, for an HTTP URI [RFC2616], the following request would 127 obtain metadata for the authority "www.example.com:80": 129 GET /.well-known/host-meta HTTP/1.1 130 Host: www.example.com 132 The semantics of the protocol used for access to the resource apply. 133 Therefore, if the resource indicates the client should try a 134 different request (in HTTP, the 301, 302, 303 or 307 response status 135 code), the client SHOULD attempt to do so; note that this implies 136 that the host-meta document for one authority MAY be retrieved from a 137 different authority. Likewise, if the resource is not available or 138 exists (in HTTP, the 404 or 410 status code), the client SHOULD infer 139 that metadata is not available via this mechanism. 141 If a representation is successfully obtained, but is not in the 142 format described above, clients SHOULD infer that the authority is 143 using this URI for other purposes, and not process it as a host-meta 144 document. 146 To aid in this process, authorities using this mechanism SHOULD 147 correctly label host-meta responses with the "application/xrd+xml" 148 internet media type. 150 5. Document Structure 152 [[ TBD, pending normative reference to the XRD 1.0 specification. ]] 154 6. Security Considerations 156 The metadata returned by the host-meta resource is presumed to be 157 under the control of the appropriate authority and representative of 158 all resources contained by it. If this resource is compromised or 159 otherwise under the control of another party, it may represent a risk 160 to the security of the server and data served by it, depending on 161 what protocols use it. 163 Scoping metadata to a single authority is the default in host-meta. 164 Thus "http://example.com/", "https://example.com", and 165 "http://www.example.com/" all have different host-meta documents with 166 seperate and non-overlapping scopes of applicability. Protocols that 167 change the scope of metadata without careful consideration can incur 168 security risks. 170 7. IANA Considerations 172 7.1. The host-meta Well-Known URI 174 This memo registers the 'host-meta' well-knwon URI in the Well-Known 175 URI Registry as defined by [I-D.nottingham-site-meta]. 177 URI suffix: host-meta 179 Change controller: IETF 181 Specification document(s): [[ this document ]] 183 Related information: None 185 Appendix A. Acknowledgments 187 This memo is directly based on [I-D.nottingham-site-meta] and 188 incorporates prose written by Mark Nottingham. 190 The author would like to acknowledge the contributions of everyone 191 who provided feedback and use cases for this draft; in particular, 192 Dirk Balfanz, DeWitt Clinton, Blaine Cook, Breno de Medeiros, Brad 193 Fitzpatrick, Will Norris, John Panzer, and Drummond Reed. 195 Appendix B. Document History 197 [[ to be removed by the RFC editor before publication as an RFC ]] 198 -00 200 o Initial draft. 202 8. Normative References 204 [I-D.nottingham-site-meta] 205 Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 206 URIs", draft-nottingham-site-meta-03 (work in progress), 207 September 2009. 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, March 1997. 212 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 213 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 214 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 216 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 217 Resource Identifier (URI): Generic Syntax", STD 66, 218 RFC 3986, January 2005. 220 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 221 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 223 [W3C.REC-P3P-20020416] 224 Marchiori, M., "The Platform for Privacy Preferences 1.0 225 (P3P1.0) Specification", World Wide Web Consortium 226 Recommendation REC-P3P-20020416, April 2002, 227 . 229 [1] 231 Author's Address 233 Eran Hammer-Lahav 234 Yahoo! 236 Email: eran@hueniverse.com 237 URI: http://hueniverse.com