RE: Content-Location

Thanks for finding the thread Francois!

The benefit I was hoping for would be a meaningful URI at the top of the
phone's screen and a meaningful URI when I click "Set Bookmark" on the
phone's menu. Sadly I've tried a number of phones and none picked up
Content-Location. I also tried <link rel="bookmark" /> and none picked
that up either.

Rob

-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org] 
Sent: Fri 07 November 2008 10:45
To: Robert Finean
Cc: public-bpwg-ct
Subject: Re: Content-Location

Hi Rob,

Robert Finean wrote:
> This is a hopefully short-lived thread picking up on a conversation
that
> started in Seoul...

I don't really remember the conversation you're referring to...

What I do remember is a long thread on the mailing-list on
Content-Location afterwards starting at:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0022.html

... ending with:
  http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0011.html

... and followed by a resolution to stay silent on this in the
guidelines:
  http://www.w3.org/2008/06/03-bpwg-minutes.html#item07

But the whole discussion was focused on caching considerations, with a
view to making content providers aware that serving responses with a
"Vary: User-Agent" header may have a strong impact on caches efficiency
since there are so many User-Agents around there, and thus that adding a
"Content-Location: [representation URI]" would be a way to advertise
one's classes of representations and improve cache efficiency.


> 
> Considering that a CT-Proxy may alter URIs so that
>  - it can adapt HTTPS content
>  - it can represent "made up" resources that don't have a full
> equivalent URI on the origin server such as:
>    * changing sub-page in a big web-page that gets split to fit on the
> phone
>    * representing JavaScript events on the web-page on a phone that
> doesn't support JavaScript
>    * capturing form inputs for a form that cannot be represented in
full
> on the phone
>  - it can compress URIs to accelerate the user-experience
> 
> 
> Is there any benefit in recommending that the CT-Proxy expose the
> original URI in the direction of the phone in a HTTP response header
> like
> 
> Content-Location:
>
http://bl138w.blu138.mail.live.com/mail/InboxLight.aspx?FolderID=0000000
>
0-0000-0000-0000-000000000001&InboxSortAscending=False&InboxSortBy=Date&
> n=1615301387
> 
> Is Content-Location the correct HTTP header to use?

Content-Location looks like the header to use, but I have the feeling it

was meant to be used the other way around, i.e it's meant to say "the 
representation enclosed in this message can be directly accessed at that

particular URI", whereas you're suggesting to use it to say "the 
original representation can be accessed there".

I'd say a "Link" header (sic!) would better carry the relationship 
between the representation served by the CT-proxy and the original URI.


> 
> Is this just a waste of bandwidth to phones that have no use for it
> whatsoever?


I think it's safe to say that user agents don't do anything with the
Content-Location header right now.

And actually I wonder what they could do with the original URI in that 
case. If a future potential user agent provides the user the option to 
go to that original URI, how would the CT-proxy differentiate that from 
a "regular" request? The user agent may add a "Cache-Control: 
no-transform" directive to the request, but that doesn't entail the 
response won't be transformed.

What kind of benefit do you have in mind?

Received on Friday, 7 November 2008 11:14:13 UTC