Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>
>
> On 21 Dec 2008, at 15:36, Luca Passani wrote:
>
>> > 2. Users are less likely to want full-web content (e.g. long 
>> "about" pages, privacy policies)
>> > in a mobile context, but may occasionally want it.
>> correct, with a very import note. The fact that a user may want a 
>> full-web transcoded page does NOT imply that a user is entitled to 
>> have it. In particular, if the content owner does not want them to, 
>> users do not have this right.
>
> Absolutely, and requiring that transcoders respect no-transform allows 
> content providers to express this right.
>
> I realise you feel that no-transform is a "legacy" header (whatever 
> that means) that has been "hijacked" (whatever that means). 
> Conversations with folks outside of mobile or the W3C[1] seem to 
> indicate that no-transform isn't really all that controversial: it's 
> the way to do this.
I strongly disagree and not only for the reasons you mention. When the 
UA is spoofed, the spoofing happens in the HTTP request. The 
no-transform can be applied in the HTTP response, but that's already too 
late. If I have a website that leverages the user-agent to decide 
whether I need to serve a mobile version, my ability to do so has 
already been impaired by the UA spoofing.
Also consider that no-transform would be catastrophic in the case of 
WML. In order for me to selectively send a no-transform header (as CTG 
is going to recommend, I undestand), I need the UAprof not to be 
spoofed. But this possibility is taken away from me by the spoofed UA.

But there is more. No-transform is an HTTP header. As such it cannot 
easily be served when using static content (and many resources in a web 
application are left static. Not everything can be served by a program. 
Some resources such as pix, javascript and CSS are simply static files 
also in complex apps). In fact, requiring no-tranform goes against the 
BPWG spirit that content owners may serve totally static but still 
BP-compliant content.


>
>> Transcoders are free to offer the possibility of transcoding, but 
>> they should go out of their way to protect mobile optimised content 
>> AND the rights of fully-fledged websites that do not want to be 
>> transcoded.
>
> Indeed. Mobile optimised content should be offered by default where 
> it's available, and no-transform should be respected. I don't hear any 
> disagreement on these points.
Please not that, within the Manifesto, no-transform is an extra 
possibility for developers to protect their content. With CTG it turns 
into their only hope. This is not OK for me.

>
>> The situation here is that some transcoders (notably novarra) go out 
>> of their way to fool websites and extort web content when a mobile 
>> version might be available.
>> My point is that CTG should be clear that this is not acceptable
>
> Read it again Luca. It is quite specific that this is not acceptable, 
> in section 4.1.5 and in 4.1.5.3.
As the Verizon installation has shown, CTG can be leveraged to say that 
an abusive installation is W3C compliant. Prohibiting UA spoofing would 
make this much more difficult.


>
>> As I had written in http://wapreview.com/blog/?p=1837  , CTG might 
>> specify that the operators adds the transcoder info in HTTP headers:
>
> It already does. See section 4.1.6.1, requiring transcoders to add a 
> Via header which explicitly states they are transcoders (as opposed to 
> other kinds of proxy).
>
> [... Luca's new idea snipped...]
>
> Sounds like a reasonable suggestion, but is also new technology 
> (therefore out of scope), seems to conflict with your desire to 
> minimise work on the part of developers, and I don't see much 
> different in effort-for-developer between this and detecting 
> Via/X-Device-User-Agent headers.
There are at least two incorrect statements here:

- the work of developers would be very small, particularly if you 
consider that developers are now in control of their content.

- X-Device-User-Agent headers are also a new technology and, as such, 
they should not be allowed by CTG (while they are right now!). And NO, 
of course the fact that Novarra had done it before does not account as 
"it existed before", or otherwise everyone could create whatever hack 
they wanted and claim that their "technology" existed from before.

>
> Meanwhile, back at the point I was trying to make: if you feel there 
> are loopholes in the language of the CTG doc, please suggest 
> alternative language which retains the meaning but closes the 
> loopholes. No-one wants the hard work that's gone into the document to 
> be wasted thanks to linguistic tomfoolery.
Remove clause 1.2 and 3 from 4.1.5. This would tighten the effective 
loophole that can be (and has been!) exploited in practice.

Luca

Received on Sunday, 21 December 2008 16:27:28 UTC