W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > September 2008

ACTION-829 Re: Action 829

From: Jo Rabin <jrabin@mtld.mobi>
Date: Thu, 04 Sep 2008 09:06:21 +0100
Message-ID: <48BF96FD.7060109@mtld.mobi>
To: "Gerlach, Heiko, VF-Group" <Heiko.Gerlach@vodafone.com>
CC: public-bpwg-ct@w3.org

Hi Heiko

Some comments in line.


On 04/09/2008 08:55, Gerlach, Heiko, VF-Group wrote:
> Hi All, 
> LC 2025, casays <casays@yahoo.com>
> In general, I must state unequivocally that our experience with
> current transformation proxies deployed throughout the world has
> always been negative, since all proxies seem to transform original
> mobile content regardless, with results ranging from passable to
> outrageously unusable. The draft, while an interesting attempt to
> bring some order in the wild practices that abound in the mobile Web,
> is 
> "still vague and incomplete in several points,"
> and thus, in its
> present form, may not stem some of the more egregious forms of
> transcoding we have witnessed so far.

I don't think that any specification will stop people who wish to behave 
egregiously from doing so. I think part of the document's purpose is to 
define more clearly what the consensus view is on what constitutes 
egregious behaviour.

> I collected different comments on quality and purpose of the document from the comment list. Summary of all comments:
> 1) What is the purpose of the document, it does not deliver much guidance
> 2) The document is quite vague
> 3) The structure might be difficult to understand
> 4) Some sentences are not easy to understand. (Comment LC-2068, LC-2012)
> My impression why this happened
> As I remember from the history we spent lots of energy in wording instead of content.
> Some Agreements have been achieved just by removing details from the document e.g. Whitelists (comment LC-2003)
Hmmm, yes we spend a lot of energy on wording - not wasted in my view. I 
also think that we removed details of white lists not because we 
couldn't get consensus otherwise (after all, if people feel that white 
lists should be mentioned then leaving them out would not constitute 
consensus). The reason for removing reference to white lists is because 
we can discuss the effects of white lists without making specific 
reference to them. It's desirable in my view to avoid reference to the 
assumed internal operation of systems, and instead to refer to their 
observable behaviour.

> What can be done:
> 1) Before starting, create a common understandin about targets
> 2) Be more specific (LC 2038)
> 3) Add use cases and User Experience
> 4) Detail the "heuristics" (LC-2069, LC-2073)
Well, that one is certainly up for grabs, I think, because of the point 
about wanting to define observable behaviour rather than internal 
operation. I don't have a particular problem with including further 
heuristics but equally think that those included at present were chosen 
for good reason. Certainly one to revisit though.
> 5) Define when and how to change the UA string (LC 2054 is a great explanation)
> 6) Maybe we sould ad some flow chart starting from content tasting, ending with the requests and responses
We made a good start on this in the Appendices. More can undoubtedly be 
> Cheers
> Heiko Gerlach 
> Vendor Manager / Product Owner
> Global Consumer Internet Services & Platforms 
> Tel: +49 211 820 2168 
> Fax: +49 211 820 2141 
> Mobile +49 172 20 40 50 7 
> E-Mail: heiko.gerlach@vodafone.com 
> Vodafone Group Services GmbH
> Mannesmannufer 2, D-40213 Düsseldorf
> Amtsgericht Düsseldorf, HRB 53554 
> Geschäftsführung: Dr. Joachim Peters, Rainer Wallek
> This message and any files or documents attached are confidential and may also be legally privileged or protected by other legal rules. It is intended only for the individual or entity named. If you are not the named addressee or you have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Thank you.  Please also note that transmission cannot be guaranteed to be secure or error- 
Received on Thursday, 4 September 2008 08:07:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC