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

From: 이문상 <[email-masked]>
Date: Sun, 04 Jul 2010 14:28:17 +0900

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" type="application/powder+xml"
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 traffic. 

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: [email-masked]
Wisdom begins in wonder. *Socrates*

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Saturday, June 26, 2010 4:54 PM
To: 이문상; [email-masked]
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.

EHL

[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/xrd-
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: [email-masked] [mailto:[email-masked]]
> On Behalf Of ???
> Sent: Friday, June 25, 2010 7:48 PM
> To: [email-masked]
> 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: [email-masked]
> Wisdom begins in wonder. *Socrates*
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: Friday, June 25, 2010 4:34 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject:
> 
> Message-Id: <[email-masked]>
> Date: Fri, 25 Jun 2010 00:33:55 -0700 (PDT)
> 
> ,[email-masked]
> 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 ([email-masked])
> 
> Author(s):
> Moon-Sang Lee, [email-masked]
> 
> Jung-Lok Yu, [email-masked]
> 
> 
> Comment:
> Thank you!
>

---

From: 이문상 <[email-masked]>
Date: Sun, 04 Jul 2010 14:36:54 +0900

Thanks for your comment, Michael.
In addition to your comments, it would greatly help web servers reduce
their maintenance cost for service infrastructure. It may reduce network
traffic to back-end servers, require less storage since it does not store
meta-data in another separate document, and simplify publishing and
maintaining of web resource. It relies on web resource itself for meta-
data, and dynamically extracts meta-data on demand. There is the
possibility that CPU load of web server would increase to process such meta-
data extraction, but memory cache could compensate the load.

Semantically, it's similar to range-unit and content-range header in HTTP/1.
1, which allows client to request that only a range of the response entity
be included within the response. In case of this proposal, request-meta
header allows client to request that only a meta-data of the target
resource be included within the response. 

I think the property (or meta-data) of an object (or web resource) is a
part of the object (or web resource). For example, an apple is laid down in
a showcase and I'd like to decide whether I'll buy it. I don't need to grab
the apple directly if I could know its color, smell, sweetness, and
freshness. Pick-out to grab and push-back to the showcase is more
inconvenient. An equipment which monitors the property of the apple can
tell me about the apple if I push a button, and I'm proposing such button
pushing protocol to operate web server to respond with resource meta-data.

Regards,
Moon-Sang Lee

---

-----Original Message-----
From: Hausenblas, Michael [mailto:[email-masked]] 
Sent: Saturday, June 26, 2010 6:12 PM
To: Eran Hammer-Lahav
Cc: 이문상; [email-masked]
Subject: Re: I-D Submission: draft-lee-httpext-metadata-00.txt

+1 to what Eran said, I couldn't have phrased it better.

Nevertheless, your use case sounds interesting, Moon-Sang, and I'd be more
than happy to follow-up off-list to investigate how it can be realised with
existing methods, such as Link: header.

Cheers,
             Michael
--
http://sw-app.org/mic.xhtml#i
Sent from my iPhone

On 26 Jun 2010, at 08:57, "Eran Hammer-Lahav" <[email-masked]>
wrote:

> 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.
>
> coverage of what you are trying to do, without having to create any 
> new mechanism.
>
> EHL
>
> [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
>> From: [email-masked] [mailto:ietf-http-wg- 
>> [email-masked]] On Behalf Of ???
>> 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.
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 4 Jul 2010 08:19:46 -0700

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.

2. Metadata is often big and not suitable for inclusion in headers.

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
OAuth).

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.

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.

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.

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.

EHL

---

From: 이문상 <[email-masked]>
Date: Tue, 06 Jul 2010 19:33:04 +0900

Refer to my answers below, Eran.

---

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

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.) 

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).

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.

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. 

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

EHL

On 7/3/10 10:28 PM, "이문상" <[email-masked]> wrote:

> 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"
type="application/powder+xml"
> 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
traffic.
> 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
> 
> ---
> in an early draft of LRDD [5] which covers existing methods for obtaining
resource metadata.
> d-