Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>
> 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?
yes. Two situations off the top of my head.

I am a user with a Nokia 7210 (WML-Only). Site www.company.com can 
normally recognize my UA and serve the ad-hoc WML content. The UA is 
spoofed. I get Mozilla-Firefox. I serve HTML with no-transform header. 
User-experience is totally broken because transcoder won't transcode AND 
7210 is unable to read HTML.

A different situation. Nokia N95. Safari browser. Site www.company.com 
can normally recognize my UA and serve great XHTML and graphics 
customzed for the N95. Spoofed UA. HTML with no-trasform is served. User 
can see transcoded web site, but user-experience is severely impacted in 
a negative way (not to mention brand recognition). The mobile site's 
business model is to serve banners and ads. UA spoofing effectively 
prevents the back-end from serving the correct ads (banners of the right 
size. Links to ringtones for Nokia N95). Result: the mobile sites loses 
revenue.

>> 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.
 I recall very clearly that the period I have followed BPWG (over one 
year), one of the pillars has been that it MUST be possible for 
developers who have no access to CGI, .htaccess, nor MIME type server 
configuration to create MobileOK and BP compliant pages. If this has 
changed, then this must have been kept very well hidden.
On the other hand, if this has not been changed, there is a clear lack 
of consistency between CTG and BP-MobOK.
In fact, it would be cool if someone from BPWG could comment on this.

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

I have already explained this a few times. I'll try again.
W3C's recommendations are not normative for anyone. The industry 
typically reverts to W3C for justification of how their product works 
and not necessarily for guidance of how they should work. This is a 
direct consequence of the fact that there are no sanctions for breaking 
W3C specs.
CTG has been a clear example of this. Transcoders do not need W3C to 
decide how they want their product to work. They only need W3C to state 
that their products are "standard" for some definitions of standard. 
Because of this, they are perfectly OK with a spec that's 
"misrepresentable". Novarra, for example, have shown that they are 
champions at this in the Verizon case.
My point is that CTG should be made extra tight, so that 
misrepresentation becomes much harder for transcoder vendors. Preventing 
UA spoofing would be a good move in this case. Right now transcoder 
vendors can spoof the UA and still say that this is what the end user 
wanted, so they are still compliant to CTG thanks to 4.1.5.2


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

What I mean is that, once operators advertise transcoding capabilities 
in the headers along the lines that I have suggested, leveraging those 
transcoders becomes straightforward for content owners who want to take 
advantage of that feature.

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

So, there are two points here:

- first, if you do not spoof the UA string, there is no need to place 
the UA in another header. It would still be in its original place 
(user-agent). After all, the point I am raising is that it is the 
content owners' right to see the original headers (UA in particular) in 
the right place. By placing it in a different header, W3C is sending out 
an inconsistent message (you don't have a right to the UA string when 
someone wants to transcode you, but on second though you have the 
right.....this is inconsistent).

- secondly, Novarra and VodafoneUK have come along and have unilaterally 
tried to change the way HTTP works. W3C should show its independence by 
not adopting a standard which someone is trying to establish "by 
arrogance". This would go a long way in showing that W3C can maintain 
some independence from the petty interests of small companies.  

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

Look, it's really very simple. Just strike 4.1.5 and replace it with this:
---------------------------------------------
4.1.5 Alteration of HTTP Header Value

Other than to comply with transparent 
<http://www.w3.org/TR/ct-guidelines/#term-transparent> HTTP operation, 
proxies *should not* modify request headers.
---------------------------------------------

(the last full stop is my addition). And you are done. Misrepresenting 
this would suddenly be much more difficult.

>
> It's a good thing we're not on one of those stalinesque mailing lists 
> which prohibits these sort of long discussions! :)
We have discussed this over and over again. As long as you  keep making 
believe that the problem is just the wording of the CTG and not how the 
mobile industry works at a more general level, I will need to keep 
arguing about how inadequate CTG is to the protect the mobile ecosystem.

Luca

Received on Sunday, 21 December 2008 21:09:41 UTC