RE: Signalling to proxies

Thanks for the summary, Jo.

Of course, as you probably saw from my post, I'm referring to signalling
in advance of the normal request-response cycle of client-server
interaction. This is why I cited robots.txt, as an example of proactive
signalling. POWDER, from what I can see in the examples, is used when
the request-response cycle has already commenced. However, with an
appropriately agreed path (much like Robots and Favicon) if could be
possible for any site to have a POWDER description sitting in the site
waiting to be "spidered". In a way, it's much like the use of ".mobi" in
the domain name to signal in advance that the content will be friendly
to mobile devices. (Ditto for the less formal use of wap.* and /wap,
/wml and /mobile patterns.)

Yes, I accept that the charter prohibits the creation of new technology,
and I openly admit that I placed the idea into the CT forum mainly
because the audience is right, despite the charter limitation. I copied
the POWDER group because I hope that this use case will get some
prominence, and maybe through a formalised example it might actually be
adopted. After all, Robots is not an official standard and look how
successful it has been.

As for the switching issue, you've suggested an interesting extension.
The proxy could insert the "switch to desktop" (or to mobile) buttons
into the delivered page as part of its adaptation, based on whatever
information the site had previously signalled. This would be much along
the lines of what you already do in .mobi at the origin server, but
deferring this practice to the proxy rather than having the logic in the
origin server. Given the complexities of reliable device detection, it
might be useful to sites for this burden to be carried by the proxy.
Then again, maybe this would require further signalling for the site to
inform the proxy if it wishes this option to be applied.

All of this would indeed require new technology. The price of progress.

Apologies for drifting out of group scope.

---Rotan.



-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: 31 October 2008 09:52
To: Rotan Hanrahan
Cc: public-bpwg-ct; public-powderwg@w3.org
Subject: 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-algo
rithm-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 11:32:27 UTC