Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>
>
> 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".

this seems different from the explanation provided by Jo. Jo says that 
developers should implement yet another header (Vary)


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

Ditto. Different from Jo's answer.

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

My understanding from Jo's answer above is that BP still hopes that 
transcoders won't touch mobile content, but this is left at the mercy of 
the transcoder vendor. If I misunderstood, someone jump in and clarify.


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

What I meant by "are not normative" is that the Chicago police won't 
show up at the Novarra office and arrest the CTO for their abuse of the 
W3C name in the Verizon installation. :)

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

Correct. But it would be much simpler for everyone to see that you are 
blatantly misrepresenting what is in the Manifesto.

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


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

I am sorry. I must have lost this bit somewhere. Which use case?

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

well, my proposal goes a bit further and includes the possibility for 
the content owner to provide links directly into the transcoder platform 
of whatever operator the user is going through.

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

This is a place where I think most of the disagreement is. My point is 
that the user does not have a natural right to transcode whatever he 
sees fit for transcoding. The content owner must always have a chance to 
say "do not transcode my stuff, no matter what the user wants".

W3C seems to say that the user has rights to transcode also against the 
will of the content owner. Yet, this position is not explicit. It is 
left ambigous. Some of the choices in CTG take the right away from the 
content owner (spoof the UA), but other choices seem to give part of 
these rights back (original headers in X-Device-*).
This ambiguity is responsible for an ambigous spec which seems to me 
like a sure fire way to bring confusion to the industry and frustration 
for developers and content owners.



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

I am not familiar with this expression. Anyway, my point is that the UA 
should never be spoofed. If W3C decides to accept this, they should at 
least choose a different header to show that they are not at the mercy 
of those who pay to sit at the table.

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

Fair enough. I think CTG should prohibit UA spoofing completely. The 
current interpretation leaves too much room for misappropriation.


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

I am not sure what you mean here. Anyway, I will ignore this remark and 
save myself and others the frustration of non-productive discussions.

Luca

Received on Monday, 22 December 2008 16:55:11 UTC