Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>
> Well, the site shouldn't be transcoded unless there's no mobile 
> version or the user asks for transcoding anyway (under CTG)... so 
> there is no UA spoofing by default (which I think is the issue you're 
> worried about). And if there's no mobile version, a transcoded desktop 
> is better than nothing anyway, unless the content provider objects.
It's very hard to discuss with you when you are hyperactive in 
misunderstanding what I wrote. When I say that CTG should rule out any 
possibility of UA spoofing, the answer is no. When I make an example of 
how UA spoofing will bring to catastrophic user experience and will 
infringe on the rights of the content owner, your answer is "the UA 
cannot be spoofed".
How can we proceed in the discussion in these conditions?


>
>>> So either I've misunderstood something important (entirely 
>>> possible), or there's no issue here. Can you explain to me why 
>>> there's any problem here, bearing in mind the explanation I've posted?
>> I suspect you misunderstood my example. My example refers to the case 
>> of a user going through a transcoder configured to spoof the UA 
>> string and respecting all other CTG rules.
>
> Right, but spoofing by default would be a breach of CTG rules.
No, it wouldn't.  Transcoder vendor just needs to claim that this is 
what the user wants. This has also been demonstrated in practice by Verizon.
Now, either CTG rules out "UA Spoofing" (which is "new technology" and 
by your own assumption should not be accounted as a possibility by CTG) 
or I can legitimately make examples of how UA spoofing breaks 
applications, even while a transcoder installation claims CTG-compliance 
"within reasonable doubt"


>
>>>> Developers want transcoders to respect mobile content without 
>>>> having to change their mobile applications. The question is whether 
>>>> W3C can help with this very simple (and fair!) request from the 
>>>> developer community or they prefer to run to the rescue of 
>>>> transcoder vendors (as they are doing now, IMO).
>
> Given that this would be changing HTTP or effectively marking parts of 
> it as legacy, I think it's down to the developer community to use HTTP 
> properly (if they're not already, which in most cases of course they 
> are). And I'm writing that as a developer myself :)

Tom, you are a developer, but you obviously have no content portfolio to 
protect, or you wouldn't be arguing in defense of CTG as strongly as you 
have been doing.
So, according to which HTTP definition is "changing the UA string" old 
technology and not new technology?

>
>>> Once again, it's you vs RFC2616.
>> Once again, never in the history of webkind have developers been 
>> expected to set headers on each and every HTTP response for each and 
>> every media type in their application. I don't think it's fair to 
>> require this of developers only because it serves the needs of 
>> transcoder vendors. Full stop.
>
> Caching is an example of somewhere where exactly this has been 
> happening for years. And caches have been configured over-aggressively 
> in the past, causing problems.
There is a few *big* differences here:
- Once the no-cache headers have been added, the caching proxy will not 
impair the ability of a web application to recognize the requesting 
client and work properly.
- Caching has not been introduced abusively by one company from one day 
to the next with the attached message "screw you" for the rest of the 
ecosystem.


>
>>>> Very well. Can someone from W3C comment? can I safely state that 
>>>> W3C thinks that developers should had no-transform to their mobile 
>>>> applications if they do not want their content transcoded under any 
>>>> circumstances?
>
> Anyone? I think that Rigo's advice covers this myself, but can anyone 
> else clarify?
Yes. Come on, W3C. You have been discussing around this for one year 
now. Does the Stetement above reflect CTG or not?

OK, I will fix it for you. 24 hours from now, if no evidence for the 
contrary has been provided, I will assume that the above statement is 
true and publicly state that, according to W3C, if mobile developers 
want to protect their application from transcoders, they should modify 
their applications and start using no-transform.

>
>>>> this is not what I said. I said that transcoders should do whatever 
>>>> possible to protect mobile content. I did not say that transcoding 
>>>> should not happen at all.
>
> OK, but here CTG and you are in agreement (and I think Jo has pointed 
> out specific sections of CTG which state this).

No. We are not in agreement. In my view, no action whatsoever should be 
required of mobile developers in order for them to protect their 
applications. This is a *BIG* difference. The rest is cosmetic.

>
> But if you believe transcoding can happen, then how? If the user opts 
> in? That's what CTG says should happen.

No. CTG allows Novarra to misrepresent and get away with it.
Another big difference is that there is no natural right of users to 
access transcoded code against the will of content owners, while this is 
exactly what CTG assumes (the user wants it = the user has a right to 
have it).
>
> And given that it can happen, how can it happen without UA spoofing?

The Manifesto way, for example, which is being adopted in practice by 
loads of installations around the planet (Sprint in the US and Voda in 
South Africa, just to mention two off the top of my head).
Send the request with original headers. If the response is not mobile, 
then transcoders are allowed to re-issue with a spoofed set of headers 
to get clean full-web HTML.

>
>>> this is your interpretation. I'll admit that I would not be crying 
>>> for many days if trasncoders would not exist, but transcoder 
>>> destruction is not the request that I am bringing to the table here. 
>>> What I am standing for is respect of the mobile ecosystem, and the 
>>> demand that mobile content and copyright is respected *without onus 
>>> for the developer and the content owner*.
>>
>> Am I asking for too much? I just don't think so.
>
> Me neither, but I think CTG achieves this.

No. It doesn't. Where the Manifesto has been adopted, problems have been 
solved. Where CTG has been adopted (Verizon), confusion and frustration 
has been the result.
But there is more. Transcoder vendors who adopted the Manifesto have 
been very responsive to developer issues and worked together with 
developers to fix them in actual installations. Vendors who did not 
sign, on the other hand, tried to hide behind their customers letting 
them take the wrap for their wrong doing.

>> This is what developers think it's fair and some major transcoder 
>> vendors agree with them and signed the Manifesto. I'll tell you more. 
>> Some transcoder vendors who have not signed the Manifesto have 
>> admitted to me off-the-record that the Manifesto rules are common 
>> sense and perfectly OK to implement (the hardest one has been the 
>> 10kb limitation for them to digest).
>
> Indeed, and I expect there's a lot of overlap between CTG and the 
> Manifesto rules for exactly this reason.
There is little overlap, because the foundation is different. The 
Manifesto puts no burden on developers and content owners. CTG does. 
This makes a world of difference, you see.
The manifesto establishes that existing applications must be preserved. 
The CTG establishes a dangerous precedent: a company can break 
applications and someone else will need to do something to fix it. This 
is a great way to demolish a developer platform.


>
>>>> I disagree. I read your thread on Googlegroups. The people who 
>>>> responded to your message were missing the context and had no idea 
>>>> of the kind of abuse that has been attempted by Novarra and VodaUK 
>>>> against the mobile ecosystem. If those same people were to find 
>>>> that major DSL providers are messing with their javascript and 
>>>> breaking their apps, they would go ballistic.
>
>
> Well, I did point out in my post that exactly this was happening and 
> that JavaScript was being messed up by Vodafone - who are a pretty 
> large ISP. I also referenced the Manifesto and CT guidelines in my 
> post; so I think I've represented the dangers accurately ("this is 
> happening. It's likely to happen more."). One of the responders noted 
> that they'd seen the problem already and were working around it by 
> messing with their JavaScript, the other suggested no-transform as the 
> answer.

well, but Vodafone is a mobile ISP, i.e. not a major wireline ISP. A 
real DSL ISP would not make such sloppy mistakes or they would be 
flooded by customer calls.

Luca

Received on Tuesday, 23 December 2008 11:38:25 UTC