Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>> Right, but since you two are both part of the CTG WG, it would be 
>> nice if answers to the same CTG-related question were consistent.
> Actually, we're allowed to disagree ;)
> (not that I think we are here, just giving different answers).

well, Jo says that developers should have added a "Vary" header. You say 
that a CTG compliant should be able to offer offer the WML version by 
dafault. This seems like disagreement to me.

>>> Can you clarify for me where the problem in your scenario exists? 
>>> Playing it out as I did above, I can't see the issue.
>> Well, my point is still that developers should not be required to 
>> change their applications in any way, in that the responsability of 
>> recognizing mobile-optimised sites should sit squarely and 
>> unambiguously on the shoulders of both transcoder vendors and 
>> operators who adopt those transcoders. This is also what the 
>> Manifesto aims at (but not the CTG, as far as I understand).
>> In this context, the recommended use of "no-transform" is already not 
>> an option in my opinion.
> Right. Do you fancy answering the question now?
> You gave examples of 2 situations which you felt were problematic. I 
> ran through them and couldn't see a problem with them; in both cases a 
> CTG-compliant transcoder would deliver the experience you wanted for 
> users and content providers, without any additional work for the 
> developer.

First, adding a "no-transform" is in itself already "additional work for 
the developer".
Secondly, wrt the first scenario, I suspect you have misunderstood my 
point. If a transcoder spoofs the UA, the site will be unable to 
recognize the device and it will return a web experience. At this point, 
no matter if the web experience is transcoded or not, the end user will 
get an error message on their nokia 7210.

The second scenario is similar. Full-web HTML is returned by the web 
server, since the application is unable to distinguish that it's a Nokia 
N95 that has requested the page and it will think it's a web browser. At 
this point, no matter whether the transcoder decides to transcode or 
not, the user experience becomes a lot worse than the one designed by 
the content owner for Nokia N95 users.

> So either I've misunderstood something important (entirely possible), 
> or there's no issue here. Can you explain to me why there's any 
> problem here, bearing in mind the explanation I've posted?
I suspect you misunderstood my example. My example refers to the case of 
a user going through a transcoder configured to spoof the UA string and 
respecting all other CTG rules.

>> right. So, my original point stands. W3C must make their specs extra 
>> tight to make sure that their recommendations are not misrepresented.
> Absolutely. And they need help from everyone to do this. Shouting "I 
> don't like these guidelines" every time someone asks you to help 
> tighten up the language of them doesn't count as help.

Look. If I tell you "remove this part", you answer that I am changing 
the meaning and not simply tightening the language. If I tell you 
"change the meaning", your reaction is that shouting "I don't like these 
guidelines" does not count as help. This may be a cycle, but I am 
certainly not the only responsible for it.
Developers want transcoders to respect mobile content without having to 
change their mobile applications. The question is whether W3C can help 
with this very simple (and fair!) request from the developer community 
or they prefer to run to the rescue of transcoder vendors (as they are 
doing now, IMO).

>>>>> I think I have addressed this one: the user does not have some 
>>>>> kind of natural right to access a transcoded website. They can do 
>>>>> so as individuals under their own responsibility, but there should 
>>>>> not be a W3C document which endorses a non-existent right to 
>>>>> access transcoded websites from a mobile phone.
> Once again, it's you vs RFC2616.

Once again, never in the history of webkind have developers been 
expected to set headers on each and every HTTP response for each and 
every media type in their application. I don't think it's fair to 
require this of developers only because it serves the needs of 
transcoder vendors. Full stop.

>> On the other hand, the content owner may wish that their transcoded 
>> web site is made available to end-users as a way to jump start their 
>> mobile offering. In this case, they should provide a link (ideally at 
>> the beginning of the page) which reads "Make this site available on 
>> mobile". The actual URL could be something like:
> No-one is stopping them from doing this.

Yes. But my point is when someone else does it for them without their 

>>> We're going round in circles again. Content owners have this right, 
>>> they express it through no-transform. Absence of no-transform is 
>>> permission to transform. This is all in RFC2616.
>> Cool. Is this W3C's official position?
> I'm not sure, though it's consistent with the advice from W3C counsel. 
> Given that it's in the spec for HTTP, I'd be surprised if not.

Very well. Can someone from W3C comment? can I safely state that W3C 
thinks that developers should had no-transform to their mobile 
applications if they do not want their content transcoded under any 

>> Let's agree to disagree then. Two distinct positions here:
>> 1) I (and many other content owners and developers) think that 
>> transcoders should keep their hands off third-party content without 
>> the need for content owners to do anything at all.
> Is that really the position of lots of developers - that transcoding 
> shouldn't happen at all?

this is not what I said. I said that transcoders should do whatever 
possible to protect mobile content. I did not say that transcoding 
should not happen at all.
And yes, my position is the position of a lot of developers.

> I get that over-aggressive transcoding and incidents like 
> Novarra/Vodafone have caused us all problems, but I'm not convinced 
> that not wanting these problems to persist or repeat is the same as 
> saying "transcoders shouldn't exist".

this is your interpretation. I'll admit that I would not be crying for 
many days if trasncoders would not exist, but transcoder destruction is 
not the request that I am bringing to the table here. What I am standing 
for is respect of the mobile ecosystem, and the demand that mobile 
content and copyright is respected *without onus for the developer and 
the content owner*.

Am I asking for too much? I just don't think so. This is what developers 
think it's fair and some major transcoder vendors agree with them and 
signed the Manifesto. I'll tell you more. Some transcoder vendors who 
have not signed the Manifesto have admitted to me off-the-record that 
the Manifesto rules are common sense and perfectly OK to implement (the 
hardest one has been the 10kb limitation for them to digest). I don't 
need any further evidence than this to know that I am right and CTG is 
ambiguous in preventing what is obviously wrong.

>> 2) W3C (or just CTG WG?) think that it's the content owner 
>> responsability to change their applications to protect their content 
>> AND the way to do it is "no-transform".
>> Is 2) W3C's position? yes or no?
> It's my position, but I'm not a spokesperson for W3C.
I am really curious to hear what W3C has to say.

Dom? Francois?

is it the content owner responsibility to protect their mobile 
applications from reformatting with "no-transform" or they'll implicitly 
forfeit their right not to be transcoded?

> Communicating with communities outside mobile-land (e.g. the AJAX 
> guys) seemed to confirm the idea that no-transform is the way to say 
> no to transformation.

I disagree. I read your thread on Googlegroups. The people who responded 
to your message were missing the context and had no idea of the kind of 
abuse that has been attempted by Novarra and VodaUK against the mobile 
ecosystem. If those same people were to find that major DSL providers 
are messing with their javascript and breaking their apps, they would go 


Received on Monday, 22 December 2008 23:53:45 UTC