RE: Comment on the Problem Statement draft

Hi Nigel

Thanks for taking the trouble to post your point of view on this list.

It seems that we haven't made it clear enough that what we are doing in
this document is trying to characterise "the problem" rather than define
the solution (which is a different document). So when we say "by
masquerading as ..." are in fact agreeing with you that this is part of
the problem.

I believe that it is true to say that operators commonly use content
transformation technology, this is a just a statement as how things
stand. It's not a comment on whether this is desirable or not, nor do we
intend to exclude the idea that others can and do operate such devices.

It is apparently not clear enough in the current version of the document
that we agree that respecting both the site owner's choice and the
user's choice are very important aspects that need to be taken into
account when looking at the solution.

Naturally I think that your inference that the group is somehow being
manipulated to serve the interests of any particular group or company is
quite misplaced.

Thanks again for your comments we'll review the document for clarity in
light of them.

Jo

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Nigel Choi
> Sent: 20 September 2007 01:38
> To: public-bpwg-ct@w3.org
> Subject: Comment on the Problem Statement draft
> 
> 
> Hi there,
> 
> I have some comment about the draft Problem Statement. But first, let
me
> introduce myself. I work for Admob, and before that in the Yahoo
mobile
> group, helping to develop their mobile web content delivery platform.
> 
> Heeding a call for discussion here in Vodafone Betavine, I am taking
the
> plunge. Hope I don't get devoured :) .
> 
> Here's what I think about the Problem Statement from my years of
> experience. Specifically, in Section 1.2
> 
> 
> "Content transformation proxies typically work by masquerading as
> desktop browsers"
> 
> I strongly object to this characterization. By masquerading as desktop
> browsers, you are in fact fooling resources that are designed to
detect
> mobile browsers/clients and return their own adapted content. Instead,
I
> would like to see this:
> 
> 
> "Content transformation proxies should remain transparent during
requests
> for content, and perform its transformation only if it detects that
the
> content returned are intended for desktop consumption".
> 
> I would go further to say that Content transformation is largely a
> transitional technology. As more and more publishers become aware of
> mobile browsing, more of them will adapt their content for mobile
> consumption.
> 
> 
> You are also making the assumption that mobile operators are the one
> operating the Content Transformation Proxy. How about the case that
> content owners themselves sign up to have their content transcoded for
> them? Ultimately, it should be left to the content owners themselves
to
> decide how their content is shown to the user, whether they want to do
> their own adaption, or have their content transcoded. It is
problematic,
> not to mention arrogant, to say that the Operator can decide to shove
> Content Transformation down the throat of every content owner that's
not
> cozy with the Operator.
> 
> Having companies manipulate standards body for their own good is not
new.
> But this to me is as blatant as it can get. As an individual I would
like
> to pose as a counterforce. I'm sure in the court of public opinion,
common
> sense always wins.
> 
> 
> 
> Nigel.
> 
> 
> 
> --0-1503583065-1190248661=0129
> Content-Type: text/html; charset=-ascii
> Content-Transfer-Encoding: quoted-printable
> 
> <html><head><style type="text/css"><!-- DIV {margin:0px;} --
> ></style></head><body><div style="font-family:times new roman, new
york,
> times, serif;font-size:12pt"><div><p>Hi there,</p><br>I have some
comment
> about the draft Problem Statement. But first, let me introduce myself.
I
> work for Admob, and before that in the Yahoo mobile group, helping to
> develop their mobile web content delivery platform.<br><br>Heeding a
call
> for discussion here in Vodafone Betavine, I am taking the plunge. Hope
I
> don't get devoured :) .<br><br>Here's what I think about the Problem
> Statement from my years of experience. Specifically, in Section
> 1.2<br><p><br></p><p>"Content transformation proxies typically work by
> masquerading as
> desktop browsers"</p><br><p>I strongly object to this
characterization. By
> masquerading as desktop browsers, you are in fact fooling resources
that
> are designed to detect mobile browsers/clients and return their own
> adapted content. Instead, I would like to see
this:<br></p><br><p>"Content
> transformation proxies should remain transparent during requests for
> content, and perform its transformation only if it detects that the
> content returned are intended for desktop consumption".</p><br><p>I
would
> go further to say that Content transformation is largely a
transitional
> technology. As more and more publishers become aware of mobile
browsing,
> more of them will adapt their content for mobile
> consumption.<br></p><br><p>You are also making the assumption that
mobile
> operators are the one operating the Content Transformation Proxy. How
> about the case that content owners themselves sign up to have their
> content transcoded for them? Ultimately, it should be left
>  to the content owners themselves to decide how their content is shown
to
> the user, whether they want to do their own adaption, or have their
> content transcoded. It is problematic, not to mention arrogant, to say
> that the Operator can decide to shove Content Transformation down the
> throat of every content owner that's not cozy with the
> Operator.</p><br><p>Having companies manipulate standards body for
their
> own good is not new. But this to me is as blatant as it can get. As an
> individual I would like to pose as a counterforce. I'm sure in the
court
> of public opinion, common sense always
> wins.<br></p><p><br></p><p>Nigel.<br></p></div></div></body></html>
> --0-1503583065-1190248661=0129--
>

Received on Friday, 21 September 2007 11:35:22 UTC