Re: [wmlprogramming] Verizon, guidelines

On 21 Dec 2008, at 21:09, Luca Passani wrote:

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

In this situation, the transcoder ought to offer the WML version by  
default (i.e. no spoofing UA). If the user asks for a transcoded full- 
web version, the transcoder will request the site with a desktop user  
agent and should then refuse to serve a transcoded version to the user.

So user experience is: get a mobile site, request a transcoded  
version, get told "sorry, no, you can't have that".

And the experience for the content provider is: mobile users get  
mobile version. Desktop users get desktop version. Desktop version is  
never transcoded, because the site said "don't transform me".

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

Same situation. If HTML with no-transform is served, it shouldn't be  
transcoded.

Both the cases you describe are of transcoders which aggressively  
transcode in breach of both Manifesto and CTG.

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

+1, I'd like to understand this better and it predates my involvement  
with any of this stuff... tho creating pages and setting metadata on  
HTTP-requestable objects do seem like 2 different things.

Can anyone clarify this?

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

Actually, the CT document is frequently normative, as evidenced by the  
section "Normative and Informative Parts"

	http://www.w3.org/TR/ct-guidelines/#sec-normative-and-informative-parts

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

Any spec is misrepresentable if you're prepared to misquote it.

For instance, if I release HumeVision, a transcoder which changes all  
UAs to "Hume/1.0" and stamp "Compliant with Luca's Manifesto" on the  
box, I'm not sure you could be held responsible.

> 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

I don't think anyone wants a document that is loose and open to  
misinterpretation.

What do you think of the use case I outlined btw? It seems convincing  
to me, in that I could imagine myself wanting to do it as a user, and  
accepting it as a content provider.

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

Agree, and CTG insists that transcoder deployments do this via the Via  
header - the mechanism enshrined in RFC2616 for proxies to advertise  
their presence. There's no need for a new means of doing this, HTTP  
provides one already.

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

I don't follow this, though given that there is at least one case  
where it acceptable (to me) to replace the UA (user asking for it),  
it's irrelevant IMHO.

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

But insisting on a new header just to make a point to Novarra etc  
makes life worse for developers, not better... it all feels a bit hair- 
shirt to me.

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

I'm not convinced you're reading these posts Luca... removing sections  
isn't closing loopholes, it's changing the meaning. If we need to  
close linguistic loopholes, we should alter the wording and retain the  
meaning.

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


Of course. I'm just pointing out the hypocrisy of your banning exactly  
that approach from your own list, whilst adopting it yourself  
elsewhere ;)

--
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 Monday, 22 December 2008 11:22:17 UTC