Re: Verizon guidelines

 From this thread:

With CTG in its current form, it works like:

Novarra: Verizon is compliant with CTG.
Tom Hume: No, they are not.
Novarra: Yes, it is because Verizon has launched a service to reformat 
the web, so users are implicitly requesting a web experience. Deep down 
somewhere there is a link to opt-out of the service....
Tom Hume: I still think Verizon is not compliant
Novarra: We disagree
...and so on and so on...

Not so, here is how it works:

Tom: Please refer to 4.1.5.3 which clearly states that the default 
assumption must be that users require the original version

[Proxies should assume that by default users will wish to receive a 
representation prepared by the Web site. Proxies must assess whether a 
user's expressed preference for a restructured representation is still 
valid if a Web site changes its choice of representations (see 4.2.6 
Receipt of Vary HTTP Header).]

Tom: And kindly also refer to 4.2.2 which states:

[Proxies must provide a means for users to express preferences for 
inhibiting content transformation. Those preferences must be maintained 
on a user by user and Web site by Web site basis. Proxies must solicit 
re-expression of preferences in respect of a server if the server starts 
to indicate that it offers varying responses as discussed under 4.2.6 
Receipt of Vary HTTP Header.]

And Luca, ref the Vary header ... this is important to stop caches 
caching the wrong thing, or rather to allow them to cache the right 
thing in the presence of varying representations.

Jo

On 23/12/2008 00:28, Tom Hume wrote:
> 
> 
> On 22 Dec 2008, at 23:53, Luca Passani wrote:
> 
>>> You gave examples of 2 situations which you felt were problematic. I 
>>> ran through them and couldn't see a problem with them; in both cases 
>>> a CTG-compliant transcoder would deliver the experience you wanted 
>>> for users and content providers, without any additional work for the 
>>> developer.
>> First, adding a "no-transform" is in itself already "additional work 
>> for the developer".
>> Secondly, wrt the first scenario, I suspect you have misunderstood my 
>> point. If a transcoder spoofs the UA, the site will be unable to 
>> recognize the device and it will return a web experience. At this 
>> point, no matter if the web experience is transcoded or not, the end 
>> user will get an error message on their nokia 7210.
> 
> 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.
> 
>>> 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.
> 
>>>> 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 :)
> 
>>> 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.
> 
>>>> 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?
> 
>>>> 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).
> 
> But if you believe transcoding can happen, then how? If the user opts 
> in? That's what CTG says should happen.
> 
> And given that it can happen, how can it happen without UA spoofing?
> 
>>> 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.
> 
>> 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.
> 
>>>> 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.
> 
> Tom
> 
> 
> -- 
> Future Platforms Ltd
> e: Tom.Hume@futureplatforms.com
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> company: www.futureplatforms.com
> personal: tomhume.org
> 
> 
> 
>

Received on Tuesday, 23 December 2008 08:29:45 UTC