Re: [wmlprogramming] Verizon, guidelines

Tom Hume wrote:
>> this seems different from the explanation provided by Jo. Jo says 
>> that developers should implement yet another header (Vary)
> Well, I'm not Jo, or telepathically linked to him ;)

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.

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

>>>>>> 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. :)
> You are correct to point out that the W3C are not a law enforcement 
> agency, yes.

right. So, my original point stands. W3C must make their specs extra 
tight to make sure that their recommendations are not misrepresented.

>>> Correct. But it would be much simpler for everyone to see that you 
>>> are blatantly misrepresenting what is in the Manifesto.
> Not if we write the CT doc in such a way that ambiguities aren't 
> lurking in it.

(warning: cycle ahead) right. And my point is that the "unless" clauses 
in 4.1.5 are giving way too much wiggle room to transcoder vendors.

>> I am sorry. I must have lost this bit somewhere. Which use case?
> This one:
>> You and I have now seen a use case (in the discussion on 
>> WapReview[2]) providing a circumstance where a user might request a 
>> transcoded desktop experience over a made-for-mobile. For anyone who 
>> (understandably) can't be bothered to wade through discussion to find 
>> it, it's thus:
>> 1. Made-for-mobile sites tend to be context-aware and contain less 
>> content than their web equivalents.
>> 2. Users are less likely to want full-web content (e.g. long "about" 
>> pages, privacy policies) in a mobile context, but may occasionally 
>> want it.
>> 3. Transcoders should therefore be in a position to offer transcoded 
>> desktop sites over made-for-mobile sites, if and only if such 
>> versions are specifically requested.
>> This seems reasonable to me. If I were providing a mobile version 
>> of <>, I would 
>> want mobile users to get this version by default and certainly 
>> wouldn't include full details of all our case studies, say, on it; 
>> but I can imagine there being rare situations where, nevertheless, 
>> users might want to read them in a mobile context.

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

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

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?

>>>  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.
> I'd rather have HTTP headers chosen for sound technical reasons than 
> to "send messages" or make points, personally. Particularly if the 
> upshot of the latter is more work for developers.

There is also value in preventing that arrogant behavior and business 
practices are rewarded. We need to prevent that the same approach is 
chosen in the future. It's an ecosystem thing.


Received on Monday, 22 December 2008 17:41:32 UTC