W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

Re: Comments on Content Transformation Guidelines?

From: Francois Daoust <fd@w3.org>
Date: Mon, 04 Aug 2008 13:52:14 +0200
Message-ID: <4896ED6E.6050703@w3.org>
To: Luca Passani <passani@eunet.no>
CC: Kai Hendry <hendry@iki.fi>, public-bpwg-comments@w3.org

Hi Luca,

Many thanks for the feedback!

I added your comments to our tracking system. While it may be some time 
before we get back to you with some proposed resolutions and/or some 
requests for clarification, we will address them as soon as possible.

Luca Passani wrote:
 > I will forward this message to WMLProgramming (the WURFL mailing list)
 > to see if other developers have something to add.

Thanks for forwarding the message to the WMLProgramming mailing-list. As 
you probably noticed, I sent an email today to the mailing-list to ask 
for feedback as well.


Luca Passani wrote:
> Kai Hendry wrote:
>> http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/
> Hi Kai, thank you for taking contact with me. As you may know, I have 
> some strong viewpoints about the whole reformatting issue.
> Here are my comments on the CT guidelines (CCing 
> public-bpwg-comments@w3.org):
> - the styleguide should spell out very clearly "The Transcoder is NOT 
> allowed to change the User-Agent String".
>  I understand that the current document says "do not change headers", 
> but at the same time, there are clauses ("the user has specifically 
> requested a restructured desktop experience") which would allow abusive 
> transcoders to find an excuse and keep being abusive of the rights of 
> content owners. Preventing transcoders from changing the UA string is an 
> effective way to avoid this abuse.
> - original headers MUST not be changed (User-Agent string has a special 
> place, but also the UAProf x-wap-profile is very very relevant). This 
> makes it unnecessary to explain how original header values are recast to 
> different headers (this is not supposed to happen in any case). In 
> short, should be removed.
> - the "|application/xhtml+xml" MIME type should be the basis for an 
> heuristics that informs transcoders that no transcoding must be applied. 
> The rationale for this is obvious: this MIME type is being used for 
> mobile content virtually exclusively these days
> - There should be restrictions over how short a  page transcoders are 
> allowed to reformat.  In no case should a page smaller than 10kb be 
> reformatted (ideally this threshold should be higher, but 10kb will make 
> it consistent with BT, so it would be a step in the right direction)
> |
> - Navigation bars: this is something that I would like to introduce in 
> the Manifesto too. In no event should a transcoder add extra footers or 
> headers (logos, extra navbars, advertisement and similar) without the 
> consent of the content owner.
> - Messing with HTTPS should not be permissible under any circumstances. 
> Disrupting HTTPS they way transcoder do today is probably illegal and 
> certainly unethical. HTTPS is built to guarantee end2end security. 
> Breaking end2end security is probably illegal and certainly not an 
> activity that W3C should endorse in any way.
> - The list of "safe" URL patterns should be improved to support iphone.* 
> and  */iphone/
> Also, I see that CTG does not mention "whitelists". I think it should, 
> since many transcoders manage that. The rule (consistently with the 
> concept that transcoders must err on the side of not transcoding) should 
> be that whitelists can only specify which potentially mobile sites can 
> be forced to be trascoded (and not the other way around as happens to be 
> common today, thus potentially forcing mobile developers to ask 
> operators in different countries to whitelist their service, which is of 
> course unacceptable).
> I will forward this message to WMLProgramming (the WURFL mailing list) 
> to see if other developers have something to add.
> Thank you for the opportunity to comment on CT.
> Luca Passani
Received on Monday, 4 August 2008 11:51:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:10 UTC