One document matched: draft-lee-httpext-metadata-00.txt

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]