Network Working Group M. Lee Internet-Draft J. Yu Intended status: Standards Track Samsung Electronics Expires: December 27, 2010 June 25, 2010 A New Header For Metadata Exchange draft-lee-httpext-metadata-00.txt Abstract This document provides a mechanism by which web servers can provide metadata of a web resource which is indicated by a URL. The web client like web browser can use this metadata to filter out unwanted web resource or link to itself. In addition, the web client can take advantage of such metadata to provide high-level services like displaying additional information about the web resource without downloading it. We expect this mechanism to enable quick access to metadata of any web resource from any web client reduces overall web traffic remarkably. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 27, 2010. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Lee & Yu Expires December 27, 2010 [Page 1] Internet-Draft A New Header For Metadata Exchange June 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. HTTP Header Extension . . . . . . . . . . . . . . . . . . . . 6 5. Client and Server Behavior . . . . . . . . . . . . . . . . . . 7 6. Metadata Format Consideration . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Lee & Yu Expires December 27, 2010 [Page 2] Internet-Draft A New Header For Metadata Exchange June 2010 1. Requirements notation 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]. Lee & Yu Expires December 27, 2010 [Page 3] Internet-Draft A New Header For Metadata Exchange June 2010 2. Introduction The URL enables access to web resource in a uniform way. A web client sends a request to a URL of a web resource which may be an html page, an audio/video file, a proprietary document file, or even a web service endpoint. A web server which is presented as a part of the URL responds with the requested web resource. Small-sized html pages had dominated traditional web sites and small- sized photos at most. However, with the evolving of the Web, large media files and streaming services are overwhelming the Web. There are millions of large photos taken by DSLR, mp3 files with high bit ratio, and user-generated video files. A media file is encoded in its own format and cannot be understood by a client program until it is downloaded and its header is verified, which incurs excessive data traffic. If a client program can get metadata of a web resource beforehand, it can induce minimal traffic by driving user to select a necessary resource or automatically filtering out unnecessary resources. There are several ways to let a web client know about a web resource prior to downloading it. For example, the publisher of a web resource may create an html page which has description and link to the web resource, and keep to maintain the up-to-date page. For another example, a proprietary server program like CGI or JSP can provide additional resource information based on the resource URL (eg. http://domain_A/path/meta.cgi?resource=http://domain_A/path/ music.mp3). However, these methods are proprietary and hard to maintain tight coupling between a web resource URL and its metadata URL across the entire Web. Lee & Yu Expires December 27, 2010 [Page 4] Internet-Draft A New Header For Metadata Exchange June 2010 3. Terminology This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication. The following terms pertaining to http protocol are used in this document as defined in [RFC2616]. Connection A transport layer virtual circuit established between two programs for the purpose of communication. Message The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 of [RFC2616] and transmitted via the connection. Request It is an HTTP request message, as defined in section 5 of [RFC2616]. Response It is an HTTP response message, as defined in section 6 of [RFC2616]. Resource A network data object or service that can be identified by a URI, as defined in section 3.2 of [RFC2616]. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways. Entity The information transferred as the payload of a request or response. An entity consists of meta-information in the form of entity-header fields and content in the form of an entity-body, as described in section 7 of [RFC2616]. Lee & Yu Expires December 27, 2010 [Page 5] Internet-Draft A New Header For Metadata Exchange June 2010 4. HTTP Header Extension This proposal for extending the HTTP header enables acquiring metadata of web resource with least modifications to HTTP 1.1. This extension specifies optional header fields which web clients and servers may present to each other in its request and response messages. The extended header fields are defined as below. [HTTP Request Header Extension] Resource-Meta: Exclusive | Inclusive | None [HTTP Response Header Extension] Resource-Meta-Data: Quoted-String Resource-Meta-Location: URL Lee & Yu Expires December 27, 2010 [Page 6] Internet-Draft A New Header For Metadata Exchange June 2010 5. Client and Server Behavior A web client may or may not specify the Resource-Meta header field. If it does not specify the header field, the protocol operates in the same way as HTTP 1.1. If it does, the protocol behaves differently according to the value of Resource-Meta header field. The Resource- Meta header may have one of three values. Exclusive: It requests only metadata of web resource, specified by a URL. Inclusive: It requests both of web resource and its metadata, specified by a URL. None: It is the same as not specifying the Resource-Meta header field. When a web server receives a request which does not specify the Resource-Meta header field, it responds in the same way as HTTP 1.1. If there is the Resource-Meta header field in the request and the value of the header field is Exclusive or Inclusive, the web server adds metadata of the requested resource to the response header. If the value is Exclusive, the web server should respond with http header while excluding the response body from the response message. A web server may directly embed metadata in the Resource-Meta-Data field or a URL where metadata of the requested resource is provided in the Resource-Meta-Location field of its response. A web client should send an additional request for metadata to the specified URL in case of receiving the Resource-Meta-Location header field. Lee & Yu Expires December 27, 2010 [Page 7] Internet-Draft A New Header For Metadata Exchange June 2010 6. Metadata Format Consideration There are various resources in the Web and their formats are hard to be standardized in one single format. In addition, this proposal is not for metadata representation but for metadata transfer. Therefore, it is good to respect commodity standards like id3 tag of mp3 format and to follow the internet media type [RFC2046]. Or, it is also good to follow the Ontology for Media Resource by Media Annotation Working Group in W3C [http://www.w3.org/2008/01/media-annotations-wg.html]. The only restriction is that all metadata should be presented in XML whether it is embedded directly in the response header or is provided through a URL indicated in the response header. Lee & Yu Expires December 27, 2010 [Page 8] Internet-Draft A New Header For Metadata Exchange June 2010 7. Security Considerations There is no security considerations. Lee & Yu Expires December 27, 2010 [Page 9] Internet-Draft A New Header For Metadata Exchange June 2010 8. References 8.1. Normative References [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. 8.2. Informative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. Lee & Yu Expires December 27, 2010 [Page 10] Internet-Draft A New Header For Metadata Exchange June 2010 Authors' Addresses Moon-Sang Lee Samsung Electronics Jung-Lok Yu Samsung Electronics Lee & Yu Expires December 27, 2010 [Page 11]