Re: [wmlprogramming] Verizon, guidelines

On 21 Dec 2008, at 16:26, Luca Passani wrote:

> 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.

Let's get clear on the situation you're talking about: a server wishes  
to multiserve WML or XHTML to mobile devices, and a desktop version to  
desktop devices, but never have the desktop version transcoded for  
mobile. Is that right? In which case, server examines the UA:

- if the UA is a mobile device, the requester is a mobile; server  
sends back mobile content as expected
- if the UA is a desktop device, the requester is either a mobile via  
transcoder, or a desktop browser: send back HTML with a no-transform  
header

Where's the problem? Can you outline the situation causing issues here?

> 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).

Folks wishing to affect caching of their files have been handling this  
sort of situation just fine since the web first arrived. It's why  
mechanisms like .htaccess files exist.

>>> 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.

I'd love to see an explanation of how prohibiting UA spoofing stops  
people from claiming documents say things they don't.

>>> 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.

I don't understand what you mean here.

> - 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.

Anyone is allowed to use X-headers, it's what they're there for:  
experimental use. But actually, you have a point here; there's a good  
argument that we ought to allocate and use a new header for this  
purpose. See the most recent minutes, where the exact discussion of  
which header has gone on:

	http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0035.html

You could certainly support using a new header for this sort of thing,  
though to do so would require developers who've already worked around  
the issue to change their code to support the reality of today and the  
proposed new header.

My opinion is that it's more pragmatic to standardise on a header name  
that's already well-deployed than it is to choose a new one just for  
the sake of it, and that choosing a new header might be perceived as  
prioritising the punishment of particular transcoder vendors over  
keeping things simple for developers - but YMMV.

>> 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.


Please re-read "retains the meaning but closes the loopholes", and  
consider what I'm talking about. Hint: removing sections isn't it.

It's a good thing we're not on one of those stalinesque mailing lists  
which prohibits these sort of long discussions! :)

--
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 Sunday, 21 December 2008 17:00:33 UTC