W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: transcoders bad

From: Luca Passani <passani@eunet.no>
Date: Tue, 05 Aug 2008 23:03:14 +0200
Message-ID: <4898C012.5080501@eunet.no>
To: public-bpwg-comments@w3.org
CC: Terren Suydam <terren@singleclicksystems.com>

Sean Owen wrote:
> I would love to hear a response to my response, since this is an
> important point and one you are passionate about:
>
> 1) The guidelines specify that User-Agent's value is preserved in an
> X-Device-User-Agent header, if modified. I am not sure how this is not
> "preserved" then? Maybe you missed that part and this is good news.
> Because on that, we agree -- no reason the information should not be
> preserved.
>   
placing a header value into a different header is not my idea of 
preservation. My idea of preservation is that header names and header 
values are left the same.
While I am here, I think it is a shame that W3C has accepted Novarra's 
attempt to redefine the mobile web, and I can't believe that you are 
supporting this with a straight face. Are you the same Sean Owen behind 
the W3C Best Practices?
> 2) If you don't change the User-Agent, you're lying. The site is NOT
> talking to a mobile device! it's talking to a transcoder. 
OK, but if the transcoder has been placed in the middle of all HTTP 
traffic then this still does not work. Mobile developers get screwed 
because their traffic from that operator drops overnight (which is 
exactly what happened with VodaUK).
I understand that Google does not care if thousands of developers get 
screwed, but I and the thousands of mobile developers do.

> It is
> important to tell the site, so that it can say "don't transcode" for
> example. Did you reverse your statement? 
your logic would make sense if the CTGs were about opt-in transcoders, 
but, as you said, they are not.
> why would I serve a
> no-transform directive if I *was* talking to a mobile phone directly?
>   
as a counter-hack which may help against transcoders illegally messing 
with my content.
> it's only if I knew I was talking to a transcoder that I would. So,
> preserving the User-Agent is harmful by this logic.
>   
Look, the great majority of mobile site is built on top of UA detection. 
So, a transcoder which runs all HTTP traffic and changes the UA is 
abusive and I will tell the world that this is not acceptable no matter 
how much you keep trying to mud the water.

> Sending back mobile-oriented content to a transcoder is likely worse
> than sending back desktop content too. What's your answer to that? I
> think it is a legitimate problem, from experience.
>   
I think transcoders should send the original request with all headers 
intact, analise the response, go out of their way in making sure that 
what they got is not already mobile-optimised and, in case it isn't, 
then they can transcode (and even issue a new request with a spoofed UA 
string if they really need to).
> I do honestly look forward to understanding how you'd propose to avoid
> this problem, for developers like Terren for example.
>   
Add this rule "DO NOT CHANGE THE USER-AGENT STRING NO MATTER WHAT"

Luca
> On Tue, Aug 5, 2008 at 4:23 AM, Luca Passani <passani@eunet.no> wrote:
>   
>>     
>>>  Hi Terren,
>>> The CT Guidelines ensure that any mobile-aware content provider can have
>>> *total control* over whether transcoding is used or not on content, by
>>>  the use of standard HTTP features: See "4.2.2 Server Origination of
>>>  Cache-Control: no-transform".
>>>       
>> It is not so, Brian. CT Guidelines do not demand that the User-Agent string
>> has to be preserved. This means that a transcoder can use a web browser UA
>> and a mobile site won't even know it is talking to a mobile device and will
>> not know it can serve a "no-trasform" header to the device.
>> More than that, even if the server served "No-trasform" headers
>> unconditionally, it would still be getting the wrong User-Agent.
>>
>> So, please do not mud the water.
>>
>> Luca
>>
>>
>>
>>     
>
>   
Received on Tuesday, 5 August 2008 21:03:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC