Network Working Group M. Nottingham
Internet-Draft E. Hammer-Lahav
Intended status: Informational October 16, 2008
Expires: April 19, 2009
draft-nottingham-site-meta-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 19, 2009.
Abstract
This memo describes a method for locating site-wide metadata for Web
sites.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 1]
Internet-Draft Site-Wide Metadata for the Web October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. the site-meta File Format . . . . . . . . . . . . . . . . . . 3
3.1. Site Metadata Entries . . . . . . . . . . . . . . . . . . 4
4. Discovering site-meta Files . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6.1. application/site-meta+xml media type registration . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 7
B.1. Is this mechanism appropriate for all kinds of
metadata? . . . . . . . . . . . . . . . . . . . . . . . . 7
B.2. Why not use OPTIONS * with content negotiation to
discover different types of metadata directly? . . . . . . 7
B.3. Why not use a META tag or microformat in the root
resource? . . . . . . . . . . . . . . . . . . . . . . . . 7
B.4. Why not use response headers on the root resource, and
have clients use HEAD? . . . . . . . . . . . . . . . . . . 7
B.5. Why scope metadata to be site-wide? . . . . . . . . . . . 8
B.6. Why /site-meta? . . . . . . . . . . . . . . . . . . . . . 8
B.7. Aren't you concerned about pre-empting an authority's
URI namespace? . . . . . . . . . . . . . . . . . . . . . . 8
B.8. Why use link relations instead of media types to
identify kinds of metadata? . . . . . . . . . . . . . . . 8
B.9. What impact does this have on existing mechanisms,
such as P3P and robots.txt? . . . . . . . . . . . . . . . 8
B.10. Why not (insert existing similar mechanism here)? . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 2]
Internet-Draft Site-Wide Metadata for the Web October 2008
1. Introduction
It is increasingly common for Web-based protocols to require the
discovery of policy or metadata about a site before communicating
with it. 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.
When this happens, it is common to designate a "well-known location"
for site metadata, so that it can be easily located. However, this
approach has the drawback of risking collisions, both with other such
designated "well-known locations" and with pre-existing resources.
To address this, this memo proposes a single (and hopefully last)
"well-known location", /site-meta, which acts as a directory to the
interesting metadata about that site. Future mechanisms that require
site-wide metadata can easily include an entry in the site-meta
directory, thereby making their metadata cheaply available (indeed,
because the site directory can be cached, the more mechanisms that
use it, the more efficient it becomes) without impinging on sites'
URI space.
The directory format allows different types of site metadata to be
referenced by URI or included inline.
Please discuss this draft on the www-talk@w3.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 RFC 2119 [RFC2119].
3. the site-meta File Format
The site-meta file format is an extremely simple XML-based language
[W3C.REC-xml] that allows an authority (in the URI sense) to indicate
where metadata about its resources is located.
The root element is the "metadata" element, which may contain any
number of "meta" elements.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 3]
Internet-Draft Site-Wide Metadata for the Web October 2008
<metadata>
<meta href="/robots.txt" rel="robots"/>
<meta rel="privacy" type="application/p3p.xml" href="/w3c/p3p.xml"/>
<meta type="application/example+xml" rel="http://example.com/rel"
href="http://other.example.net/example">
<example-root xmlns="http://www.example.com">
<!-- some metadata here -->
</example-root>
</meta>
<meta type="text/example">
foo = bar
baz = bat
</meta>
</metadata>
Unrecognised elements and attributes SHOULD be silently ignored when
parsing the format, unless specified otherwise. Likewise, unless
otherwise specified ordering of sibling elements SHOULD be ignored.
3.1. Site Metadata Entries
Each "meta" element represents a kind of site metadata that is
available. It MUST have a "rel" attribute containing a link relation
[ref TBD]. It SHOULD have a "type" attribute whose content MUST be
an internet media type [RFC4288], hinting its format.
The actual metadata content may be inlined as the content of the
"meta" element, and/or referred to using the "href" attribute. The
metadata MUST be made available by at least one of these methods.
If the "href" attribute is present, its content MUST be a URI-
Reference [RFC3986] that locates the metadata. Relative URIs MUST be
evaluated with the site root URI as the base URI.
If the metadata content is included inline, it MUST appear as a child
of the "meta" element. If the metadata format is XML-based, the root
element of the metadata will thus be the first (and only) child
element of the "meta" element. If the metadata format is textual, it
will be the text content of the "meta" element (appropriately
escaped, with CDATA section(s) and/or entities).
the "meta" element MUST NOT contain any children other than inlined
metadata content.
4. Discovering site-meta Files
The site-wide metadata for a given authority can be discovered by
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 4]
Internet-Draft Site-Wide Metadata for the Web October 2008
dereferencing the path /site-meta. For example, in HTTP the
following request would obtain site metadata for the authority
"www.example.com";
GET /site-meta HTTP/1.1
Host: www.example.com
If the resource is not available or existent (in HTTP, the 404 or 410
status code), the client SHOULD infer that site 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 site is using this URI for other purposes, and not
process it as a site-meta file.
To aid in this process, sites using this mechanism SHOULD correctly
label site-meta responses with the "application/site-meta+xml"
internet media type.
5. Security Considerations
6. IANA Considerations
6.1. application/site-meta+xml media type registration
The site-meta format, when serialized as XML 1.0, can be identified
with the following media type:
MIME media type name: application
MIME subtype name: site-meta+xml
Mandatory parameters: None.
Optional parameters:
"charset": This parameter has identical semantics to the charset
parameter of the "application/xml" media type as specified in
RFC 3023 [RFC3023]. [RFC3023].
Encoding considerations: Identical to those of "application/xml" as
described in RFC 3023 [RFC3023], section 3.2.
Security considerations: As defined in this specification. [[update
upon publication]]
In addition, as this media type uses the "+xml" convention, it
shares the same security considerations as described in RFC 3023
[RFC3023], section 10.
Interoperability considerations: There are no known interoperability
issues.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 5]
Internet-Draft Site-Wide Metadata for the Web October 2008
Published specification: This specification. [[update upon
publication]]
Applications which use this media type: No known applications
currently use this media type.
Additional information:
Magic number(s): As specified for "application/xml" in RFC 3023
[RFC3023], section 3.2.
File extension: None
Fragment identifiers: As specified for "application/xml" in RFC 3023
[RFC3023], section 5.
Base URI: As specified in RFC 3023 [RFC3023], section 6.
Macintosh File Type code: TEXT
Person and email address to contact for further information: Mark
Nottingham <mnot@pobox.com>
Intended usage: COMMON
Author/Change controller: This specification's author(s). [[update
upon publication]]
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[W3C.REC-xml]
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
xml, October 2000, <http://www.w3.org/TR/REC-xml>.
7.2. Informative References
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 6]
Internet-Draft Site-Wide Metadata for the Web October 2008
[W3C.REC-P3P-20020416]
Marchiori, M., "The Platform for Privacy Preferences 1.0
(P3P1.0) Specification", W3C REC REC-P3P-20020416,
April 2002.
URIs
[1] <http://lists.w3.org/Archives/Public/www-talk/>
Appendix A. Acknowledgements
The authors take all responsibility for errors and omissions.
Appendix B. Frequently Asked Questions
B.1. Is this mechanism appropriate for all kinds of metadata?
No. The primary use cases are described in the introduction; when
it's necessary to discover metadata or policy before a resource is
accessed, and/or it's necessary to describe metadata for a whole site
(or large portions of it), site-meta is appropriate. In other cases
(e.g., fine-grained metadata that doesn't need to be known ahead of
time), other mechanisms are more appropriate.
B.2. Why not use OPTIONS * with content negotiation to discover
different types of metadata directly?
Two reasons; a) OPTIONS is not cacheable -- a severe problem for
scaling -- and b) it is not well-supported in browsers, and difficult
to configure in servers.
B.3. Why not use a META tag or microformat in the root resource?
This places constraints on the format of a site's root resource to be
HTML or similar. While extremely common, it isn't universal (e.g.,
mobile sites, machine-to-machine communication, etc.). Also, some
root resources are very large, which would place additional overhead
on clients and intervening networks.
B.4. Why not use response headers on the root resource, and have
clients use HEAD?
This is attractive, in that you could either put metadata directly in
response headers, or you could refer to a resource in a similar
manner to site-meta. However, it requires an extra round-trip for
metadata discovery, which is unacceptable in some scenarios.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 7]
Internet-Draft Site-Wide Metadata for the Web October 2008
B.5. Why scope metadata to be site-wide?
The alternative is to allow scoping to be dynamic and determined
locally, but this has its own issues, which usually come down to a)
an unreasonable number of requests to determine authoritative
metadata, b) increased complexity, with a higher likelihood of
implementation and interoperability (or even security) problems.
Besides, many mechanisms on the Web already presume a site scope
(e.g., robots.txt, P3P, cookies, javascript security), and the effort
and cost required to mint a new URI authority is small and shrinking.
B.6. Why /site-meta?
It's short, descriptive and according to search indices, not widely
used.
B.7. Aren't you concerned about pre-empting an authority's URI
namespace?
Yes, but it's unfortunately a necessary (and already present) evil;
this proposal tries to minimise future abuses.
B.8. Why use link relations instead of media types to identify kinds of
metadata?
A link relation declares the intent and use of the link (or inline
content, when present); a media type defines the format and
processing model for those bits.
B.9. What impact does this have on existing mechanisms, such as P3P and
robots.txt?
None, until they choose to use this mechanism.
B.10. Why not (insert existing similar mechanism here)?
We are aware that there are several existing proposals with similar
functionality. In our estimation, none have gained sufficient
traction. This may be because they were perceived to be too complex,
or tied too closely to one use case.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 8]
Internet-Draft Site-Wide Metadata for the Web October 2008
Authors' Addresses
Mark Nottingham
Email: mnot@pobox.com
URI: http://www.mnot.net/
Eran Hammer-Lahav
Email: eran@hueniverse.com
URI: http://www.hueniverse.com/
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 9]
Internet-Draft Site-Wide Metadata for the Web October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Nottingham & Hammer-Lahav Expires April 19, 2009 [Page 10]
