[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 6415

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/