W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

RE: I-D Submission: draft-lee-httpext-metadata-00.txt

From: 이문상 <sang0627.lee@samsung.com>
Date: Tue, 06 Jul 2010 19:33:04 +0900
To: 'Eran Hammer-Lahav' <eran@hueniverse.com>, 'HTTP Group' <ietf-http-wg@w3.org>
Message-id: <008e01cb1cf6$9de31a70$d9a94f50$%lee@samsung.com>

Refer to my answers below, Eran.

Moon-Sang Lee, Senior Engineer, Ph.D.
Convergence Software Lab., Digital Media & Communication R&D Center,
Samsung Electronics Co., Ltd.,
TEL: +82-31-279-8082
Email: sang0627.lee@samsung.com
Wisdom begins in wonder. *Socrates*

-----Original Message-----
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Monday, July 05, 2010 12:20 AM
To: 이문상; HTTP Group
Subject: Re: I-D Submission: draft-lee-httpext-metadata-00.txt

As I have stated many times over the past few years, there isn’t a perfect
solution for this. The trick is to find the most suitable tradeoff.

Some of the problems with your proposal include:

1. This does not work well with caching since the response is different
based on the presence of this new header field. This means that every cache
in the world will need to change to differentiate between the three request
modes you introduced. This will never happen.

Well, I mentioned cache in my previous email but it refer to “memory
cache” not “web cache”. Anyway, Metadata is relatively small in size.
Should we cache the metadata? It’s possible to set non-cacheable in
response header. (i.e. Cache-Control: no-cache)

Or, it may work in the same way as Link header 
2. Metadata is often big and not suitable for inclusion in headers.

Then, can we include metadata in the response body?
In addition, as I know, HTTP does not define any limit on the size of
header. Just web servers do limit size of headers they accept, and the
limit is configurable. (i.e. In many cases, it’s 8KB or 16KB by default.) 

3. By putting the metadata in a header, you are breaking one of the core
principals of the web - the ability to reference objects using links.
Metadata is also data, and should have its own URI. In addition, the
metadata can also have metadata but your proposal does not accommodate this
use case (which is pretty common when it comes to using protocols such as

Yes, if a publisher generates a separate object(document) for metadata,
then it should be referenced by its own URI. But I don’t assume metadata
as a separate object(document) but as a property of object(document). So
the ability to reference objects using links is not broken with my
proposal, since it still uses URI. In my proposal, metadata is not object
and there is no metadata of metadata unless metadata is stored to a
separate object(document which is referable by URI).

4. Since the header isn't a separate entity (i.e. #3), it is bound to the
security consideration of the resource itself. This is too limited as in
many cases, the permissions of the resource are different from the
permissions of the metadata.

Well, you seem like that there is a separate document which stores
metadata. I think it’s possible that if I don’t have any permission to an
object then I don’t have any permission to the metadata of the object. 

5. The proposal doesn't address authoring and manipulating the metadata. By
putting data in a header field, you lose everything HTTP has to offer. You
can't POST/DELETE/PUT metadata. In fact, the only way to manipulate
metadata in your proposal is to have admin access to the web server.

Yes, metadata is instant in my proposal. Again, I’d like to mention that
my metadata is not a separate and independent resource tightly linked to a
resource, but a property of a resource. Therefore, extracting metadata from
a resource and sending http response to a client is sufficient. It’s just
a property of a resource. I’m proposing how to request the property of a
resource over http, especially for media resource like mp3.

6. This is too hard to deploy. Most web servers are not setup to manipulate
headers in this way. A proposal like this will require native support which
is never going to happen.

Nobody might not think web is widespread in 1980’s, but almost every web
servers supports HTTP/1.1 nowadays. I think web servers can adopt this kind
of extension as a plugin according to the type of requested resource. 

This is a partial list. Using the link header adds one layer of indirection
but is much more inline with web architecture and existing tools.

Well, I don’t think so. Using the link header originates many problems you
mentioned like permission (i.e. #4).


On 7/3/10 10:28 PM, "이문상" <sang0627.lee@samsung.com> wrote:

> Thanks for your comments, Eran.
> According to your suggestion, I've read documents you mentioned. And, 
> let me ask and explain several things which show differences between 
> my proposal and other prior proposals.
> If a context IRI is "http://domain/music.mp3", how does the Link 
> header provide additional information about music.mp3? It may provide 
> Link header like Link: <music.xml>; rel="describedby"
> while combining Link header and POWDER. Or, It may also possible to 
> combine Link header and hostmeta as you mentioned. However, if we 
> focus on the acquisition of resource meta-data, these kinds of 
> approach enlarge response time and complicate server maintenance as below.
> 1. Indirect meta-data
> Any combination using existing standards requires two separate 
> requests to get the meta-data of a resource, one for retrieving Link 
> header and the other for retrieving meta-data itself. It increases 
> response time for meta- data acquisition transaction and overall network
> 2. Consistency consideration
> According to previous proposals, it is required to keep consistency 
> between a resource and its meta-data. For example, if a publisher has 
> modified or removed music.mp3, then its linked document should also be 
> modified or removed to keep the consistency. Web is alive and millions 
> of resources are created, modified, and removed every day. Updating 
> resource status to its linked document is not trivial especially for 
> large web server with dynamic contents.
> Regards,
> Moon-Sang Lee
> ---
> Moon-Sang Lee, Senior Engineer, Ph.D.
> Convergence Software Lab., Digital Media & Communication R&D Center, 
> Samsung Electronics Co., Ltd.,
> TEL: +82-31-279-8082
> Email: sang0627.lee@samsung.com
> Wisdom begins in wonder. *Socrates*
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> Sent: Saturday, June 26, 2010 4:54 PM
> To: 이문상; ietf-http-wg@w3.org
> Subject: RE: I-D Submission: draft-lee-httpext-metadata-00.txt
> Hi,
> You are entering an area with a lot of prior experience.
> There is little reason to extend HTTP with additional headers given 
> the recent work on the HTTP Link header [1] (and the 'describedby' 
> relation type), as well as the POWDER [2] and XRD [3] descriptor 
> formats, and the host-meta proposal [4] which is currently in last 
> call. In addition, you might want to take a look at analysis included 
> in an early draft of LRDD [5] which covers existing methods for obtaining
resource metadata.
> Between using the HTTP Link header and host-meta, you should have full 
> coverage of what you are trying to do, without having to create any 
> new mechanism.
> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header
> [2] http://www.w3.org/TR/powder-dr/
> [3] 
> http://www.oasis-open.org/apps/org/workgroup/xri/download.php/38236/xr
> d-
> 1.0-wd17.html
> [4] http://tools.ietf.org/html/draft-hammer-hostmeta
> [5] http://tools.ietf.org/html/draft-hammer-discovery-03#appendix-B
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org 
>> [mailto:ietf-http-wg-request@w3.org]
>> On Behalf Of ???
>> Sent: Friday, June 25, 2010 7:48 PM
>> To: ietf-http-wg@w3.org
>> Subject: FW: I-D Submission: draft-lee-httpext-metadata-00.txt
>> FYI.
>> ---
>> Moon-Sang Lee, Senior Engineer, Ph.D.
>> Convergence Software Lab., Digital Media & Communication R&D Center, 
>> Samsung Electronics Co., Ltd.,
>> TEL: +82-31-279-8082
>> Email: sang0627.lee@samsung.com
>> Wisdom begins in wonder. *Socrates*
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
>> Sent: Friday, June 25, 2010 4:34 PM
>> To: internet-drafts@ietf.org
>> Cc: sang0627.lee@samsung.com; sang0627.lee@samsung.com
>> Subject:
>> Message-Id: <20100625073403.CBA163A69A1@core3.amsl.com>
>> Date: Fri, 25 Jun 2010 00:33:55 -0700 (PDT)
>> ,junglok.yu@samsung.com
>> Subject: Manual Post Requested for draft-lee-httpext-metadata
>> Content-Type: text/plain; charset="utf-8"
>> Mime-Version: 1.0
>> Manual Posting Requested for following Internet-Draft:
>> I-D Submission Tool URL:
>> https://datatracker.ietf.org/idst/status.cgi?submission_id=24392
>> Filename:        draft-lee-httpext-metadata
>> Version:         00
>> Staging URL:     http://www.ietf.org/staging/draft-lee-httpext-metadata-
>> 00.txt
>> Title:                   A New Header For Metadata Exchange
>> Creation_date:           2010-06-25
>> WG ID:                   Individual Submission
>> Number_of_pages: 11
>> 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.
>> Submitter: Moon-Sang Lee (sang0627.lee@samsung.com)
>> Author(s):
>> Moon-Sang Lee, sang0627.lee@samsung.com
>> Jung-Lok Yu, junglok.yu@samsung.com
>> Comment:
>> Thank you!
Received on Tuesday, 6 July 2010 10:34:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:22 UTC