Re: Signalling to proxies

Hi Rotan

A couple of observations on your post:

The CT doc suggests using both Cache-Control: no-transform and Vary: to 
signal a prohibition of changing aspects of the response and signalling 
that the representation varies according to the specified aspects of the 
request.

We currently have an open question out to the TAG referenced under 
ISSUE-222 on the use of the link rel=alternate formula asking their view 
on how to signal the availability and locations of different 
representations, and especially how to signal the fact that different 
representations are available with the same media attribute (Referencing 
the TAG finding on Alternative Representations [1]).

This latter is especially important when communicating that different 
representations are available relating to the same media type (e.g. you 
may have many varying representations that all fall under the catch-all 
media="handheld").

There's a related issue in that current efforts to revive the HTTP link 
header do not proposed to standardise the media attribute present in HTML.

Ref providing a coherent system of "switching" we're working on that 
under the "Best Practices 2" or more accurately "Application Best 
Practices" document. There an article on MobiForge about this: "A Very 
Modern Mobile Switching Algorithm" [2].

And finally ref a more fine-grained approach to this, in the CT document 
we reference POWDER as a possible mechanism for implementing this under 
"Scope for Future Work". Our limitation is that we are not chartered to 
"Create New Technology" only to advise on Best Practice use of existing 
technology.

Cheers
Jo

[1] http://www.w3.org/2001/tag/doc/alternatives-discovery.html

[2] 
http://mobiforge.com/designing/story/a-very-modern-mobile-switching-algorithm-part-i

On 30/10/2008 23:22, Rotan Hanrahan wrote:
> Just a general observation about signalling to proxies...
>  
> One way to signal to a transforming proxy is to have a cache-control: 
> no-transform header in your HTTP response. This signal says "I'm already 
> good for this context".
>  
> In future, we will need to signal additional information, beyond just 
> the current HTTP response. For example, suppose I want to be proactive 
> and inform any proxies that I have a permanent alternative URL for 
> mobile users? (My preference is that only one URL is ever needed, but I 
> accept the reality of the current Web that multiple URLs are quite common.)
>  
> We need to help site designers to be proactive (in an 
> indistry-recognised way) to assist the proxies to "do the right thing", 
> not just on a page-by-page basis, but on a per-site basis. Proper 
> signalling between the client, proxy and origin server would certainly 
> help*. Proactive signals I'm thinking about would include, for example:
> - I'm a desktop site, but you may remember this redirect to a 
> contextually-sensitive equivalent.
> - I'm a desktop site, but I can serve mobile content if you ask for it.
> - You may optimize images from this site, but you should not restructure 
> and/or recode content.
>  
> The CT guidelines are excellent, insofar as they give concrete 
> information and examples to site designers and proxy implementers 
> regarding what they should do. Very valuable advice. Much like the 
> plentiful advice on the use of the de-facto robots.txt "standard".
>  
> What I'm thinking is that perhaps it's time to create some concrete 
> examples of how to signal this higher-level concerns to proxies, 
> possibly borrowing from the success of the example.com/robots.txt URL 
> pattern, and introduce an example.com/proxies-powder.xml "well known URL 
> pattern". Yes, that would be a POWDER resource, specifically to assist 
> proxies, and specifically at a known path so that proxies can sniff them 
> in advance (much like search engines currently sniff the robots.txt 
> before proceeding to index the site). Pretty soon, we could all be using 
> little POWDER files on our sites to ensure that the adaptable is 
> adapted, the adapted is not re-adapted and everything else in-between is 
> treated appropriately.
>  
>  
> ---Rotan
>  
>  
>  
> * Though obviously the legacy Web will still need special treatment.
>  
>

Received on Friday, 31 October 2008 09:53:01 UTC