Re: [minutes] CT Call 6 january 2009

Just one comment about one of Sean's comments:

 >  sean: Sometimes there's content for high-end phones tagged as
 >  "mobile" that may not work on a low-end phone. We already have a
 >  method for keeping proxies away from content, "no-transform"

Now, I have been accused of being an old record, but Novarra has not 
moved one inch since summer 2007. They still think they can place 
themselves in the middle of all content and "fix it", because they are 
cooler and smarter than everyone else. There is no trace of respect for 
content developers here. Any excuse is good to try and mess with content 
they have no right to.
Frankly, I find this scary. How can this notion be acceptable to anyone 
here? if this concept that anyone can interfere with third-party content 
just because that third-party content may not be usable/accessible in 
some context, then the foundations of the web as we know it are under 
attack.

I don't know whether Novarra will manage to make CTG supportive of 
"their" vision of the mobile web, but if they do, this will be a small 
victory for them, and a big defeat for W3C, since it will have missed a 
great chance to defend very basic web principles.

To provide the measure of how far Novarra is willing to go, please take 
a look at:

http://telecomnewsbd.wordpress.com/2008/10/28/wap-portals-a-futuristic-look/

"Jayanthi Rangarajan, president and CEO of Novarra, says previous 
incarnations of WAP sites were designed for the lowest denominator of 
handset to ensure mass-market availability. Despite the rise in mid- to 
high-end devices, mobile Internet solutions providers like Novarra can 
now automatically “dumb down” a page—that is, transcode the site to suit 
the requirements of the device.
Rangarajan believes that major content providers such as the BBC must 
cater to a global audience and consider the handset capability of users 
outside the UK where 2G/2.5G could be the foremost mode of access. “The 
BBC creates a great WAP site for the UK market, but it has a massive 
following in India and is not designed for the Indian market,” she says."

In short, Novarra is getting ready to reformat perfectly OK mobile 
content, just because someone somewhere may have a legacy device (and 
which definition of legacy is up to them to decide). How much more 
evidence do you need that this is not the way to go? let Novarra do 
whatever they want, but please prevent them from doing it in W3C's name.

Luca

Francois Daoust wrote:
>
> Hi,
>
> The minutes of today's call are available at:
>  http://www.w3.org/2009/01/06-bpwg-minutes.html
>
> ... and copied as text below.
>
> Summary:
> - Resolution: WAP1 content WML, WBMP and so on is to be treated 
> transparently (but this doesn't affect the operation of WAP Gateways 
> and authorised transformations as specified in xxxx [ref to be 
> supplied by EdC in 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html])
>
> - We had a long discussion on mandating respect of a few heuristics 
> with a SHOULD. No decision taken yet.
>
> - Next calls could be merged with the remaining of the BPWG.
>
>
> Francois.
>
>
> 06 Jan 2009
>
>    [2]Agenda
>
>       [2] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2009Jan/0000.html
>
>    See also: [3]IRC log
>
>       [3] http://www.w3.org/2009/01/06-bpwg-irc
>
> Attendees
>
>    Present
>           Francois, tomhume, Bryan_Sullivan, jo, rob, SeanP, EdC
>
>    Regrets
>    Chair
>           francois
>
>    Scribe
>           tom
>
> Contents
>
>      * [4]Topics
>          1. [5]Mandating respect of some heuristics
>          2. [6]Merging task force with the working group
>      * [7]Summary of Action Items
>      _________________________________________________________
>
> Mandating respect of some heuristics
>
>    <francois> [8]Dom's thread on mandating heuristics
>
>       [8] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0080.html
>
>    francois: This has been in the air since the CT began. Dom posted
>    back onto the mailing list about it. Main question is whether we
>    consider CT to be a generic thing, or whether it's mobile CT that
>    we're chartered to solve.
>    ... I think mobile CT is the core of the guidlines. With no better
>    way for content providers to express their position wrt
>    transformation, we should provide guidelines which prevent
>    transformation of mobile content.
>    ... DOCTYPE and LINK tags are amongst the only ways to determine
>    mobile content.
>
>    <EdC> some mime types are unambiguously mobile as well.
>
>    francois: if we view CT as a generic thing, then transformation of
>    mobile content could be viewed as useful. But if we view CT as a
>    mobile thing to render desktop sites for mobile, we should leave
>    mobile content well alone.
>    ... What are the positions here?
>
>    sean: Sometimes there's content for high-end phones tagged as
>    "mobile" that may not work on a low-end phone. We already have a
>    method for keeping proxies away from content, "no-transform"
>
>    francois: requiring CPs to add no-transform is a bit worrying, in
>    the sense that they have to add it everywhere if they want content
>    to be untouched.
>    ... I don't care if high-end mobile content is adapted for low-end
>    devices, because the developers will already be taking mobility into
>    mind
>
>    sean: the content types are XHTML, right?
>
>    francois: text/vnd.wap.wml implies mobile, but others don't
>
>    <Bryan> xhtml-mp also
>
>    sean: Images, CSS etc have to have no-transform on them anyway. The
>    only one you need to remove it from is the XHTML MIME type
>
>    francois: if CT doesn't alter XHTML or HTML content, it won't alter
>    CSS embedded in it and so on.
>    ... it doesn't remove the need for "no-transform", just removes the
>    need to have it every time
>
>    <Zakim> jo, you wanted to say that just because the content is
>    specifically mobile doesn't mean it is suitable for the device
>    accessing it and to add something on cache-control:
>
>    jo: I think the idea that something is purposed for mobile, doesn't
>    mean that it's purposed for the device in question. We shouldn't
>    encourage the notion that there's just one sort of mobile content.
>    You should do what we say in BP2: classify devices and have 3/4
>    different experiences if your app warrants it. We'd be contradicting
>    our own best practice to say "if it's mobile leave it alone, no
>    matter what the device".
>    ... I agree with Luca that asking people to have no-transform on
>    things that can't have META HTTP-EQUIV tags in them is unduly
>    onerous on developers. We should have a clause to say that if the
>    original page referencing resources requests no transformation, the
>    rule should apply to resources retrieved from this page.
>
>    <Zakim> rob, you wanted to say that these are all heuristics that
>    allow a CT-proxy to assume that the content is suitable as-is and it
>    is useful to say what these are. As Eduardo notes,
>
>    rob: I agree with Luca that it's up to operators in the proxy chain
>    to do no harm, but to do so they need to make some guesses, so it's
>    helpful to point out heuristics we use for clues. As Eduardo pointed
>    out, operators need control to override this with white- and
>    black-lists, and CPs should be aware that no-transform is another
>    way to get what they want if these heuristics don't deliver what
>    they want. All these things are useful together.
>    ... These have to stay heuristics, partic. if you're going to allow
>    operators to override them (other than no-transform, which should be
>    strongly enforced as it gives CPs a chance to veto what happens in
>    front of them).
>
>    bryan: In general it's not a good idea to overtly restrict the scope
>    of applicability. We usefully do transformation of content towards
>    mobile. We also prevent things from breaking, by doing no harm -
>    this is a fundamental objective. So we have to operate with white
>    and blacklists and develop mechanisms to automate management of
>    these lists. We agreed as a group not to go there (rightfully so).
>    We need to say there are other operations necessary to modify the
>    beha
>
>    edC: WAP content cannot have a no-transform directive on it.
>    ... It's been mentioned that there might be several categories of
>    mobile content and that CTs might modify content for different
>    phones. How do you know what sort of adaptation has been performed
>    on the CP side? I don't have much confidence that content for
>    high/mid/low-end phones can be distinguished.
>    ... If you have a page marked "no-transform", then the linked
>    resources should be considered not transformable. This assumes
>    something in the implementation of CT proxies, that it preserves
>    state about page and can associate further HTTP requests with
>    earlier ones. I'm not sure this will alwys work.
>
>    <Zakim> rob, you wanted to consider making the WAP1 Content-Type
>    from an origin server a normative heuristic then?
>
>    rob: Is there a case for making the WAP1 Content-type a normative
>    heuristic rather than informational?
>
>    <Zakim> jo, you wanted to wonder if we did not already decide that
>    WML is considered no-transform by a resolution from last year?
>
>    jo: didn't we already say this is the case? I thought we'd taken
>    that resolution.
>
>    <jo> PROPOSED RESOLUTION: WML content is to be treated as though it
>    has no-transform attached
>
>    <francois> +1
>
>    <rob> +1
>
>    <EdC> -1
>
>    +1
>
>    <SeanP> +1
>
>    bryan: can we make a caveat to say that no-transform doesn't mean
>    "no compression"?
>
>    francois: the rule should only apply to the CT proxy itself... and
>    not to the gateways.
>
>    <jo> PROPOSED RESOLUTION: WML content is to be treated as though it
>    has no-transform attached (but this doesn't affect the operation of
>    WAP Gateways)
>
>    edC: transformation specified by WAP standards should still be
>    allowed.
>    ... there are two normalised transformations. Compression of WML to
>    WBXML, and conversion of WML 1.3 to WML2 content.
>
>    francois: is this already defined in OMA standards?
>    ... we should refer to that then.
>
>    <jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
>    treated as though it has no-transform attached (but this doesn't
>    affect the operation of WAP Gateways and authorised transformations
>    as specified in xxxx [ref to be supplied by EdC])
>
>    <Zakim> tomhume, you wanted to wonder about multiserved content
>
>    tomhume: are there any issues around multiserving of content where a
>    single page might turn out WML or XHTML, and if transformation is to
>    be prohibited, then a no-transform must be included for XHTML but
>    not for WML
>
>    <Zakim> rob, you wanted to rephrase away from "as though it has
>    no-transform" to "transparently" because we are not adding or
>    removing any Cache-Control headers
>
>    <EdC> this question is again the same issue: should we leave
>    mobile-specific content alone by default?
>
>    rob: shouldn't we be talking about no-transform? We're not changing
>    Cache-control headers. I don't think we should talk about WML being
>    no-transform, because it isn't necessarily. We should talk about WML
>    content being treated transparently and not being altered.
>
>    francois: we should say that transformations applied to WAP content
>    are defined elsewhere.
>
>    <Zakim> jo, you wanted to agree with tom that multiserving HTML and
>    WML has complications ref no-transform that we shouldprobably note
>    explicitly
>
>    jo: if you're delivering WML and HTML from the same URI and you want
>    HTML to be not transformed, you should put a no-transform on the
>    HTML, but not onto the WML
>
>    francois: is this a real problem? Does it create any technical
>    issues?
>
>    jo: it's worth noting as a peculiarity. "Don't put no-transform onto
>    WML, because it causes misoperation of WAP gateways".
>    ... meanwhile back at the resolution...
>
>    <EdC> Necessary references re: WAP under
>    [9]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.h
>    tml
>
>       [9] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
>
>    <francois> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is
>    to be treated as though it has no-transform attached (but this
>    doesn't affect the operation of WAP Gateways and authorised
>    transformations as specified in xxxx [ref to be supplied by EdC])
>
>    <EdC> What about: ... is unaltered, except as specified in XXX.
>
>    <jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
>    treated transparently (but this doesn't affect the operation of WAP
>    Gateways and authorised transformations as specified in xxxx [ref to
>    be supplied by EdC])
>
>    <francois> +1
>
>    +1
>
>    <SeanP> +1
>
>    <rob> +1
>
>    <jo> +1
>
>    <Bryan> +
>
>    <Bryan> +1
>
>    <EdC> 0 (treated transparently a bit fuzzy in my mind).
>
>    <jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
>    treated as though it has no-transform attached (but this doesn't
>    affect the operation of WAP Gateways and authorised transformations
>    as specified in xxxx [ref to be supplied by EdC in
>    [10]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
>    html])
>
>      [10] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
>
>    <jo> PROPOSED RESOLUTION: WAP1 content WML, WBMP and so on is to be
>    treated transparently (but this doesn't affect the operation of WAP
>    Gateways and authorised transformations as specified in xxxx [ref to
>    be supplied by EdC in
>    [11]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
>    html])
>
>      [11] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
>
>    <EdC> +1
>
>    RESOLUTION: WAP1 content WML, WBMP and so on is to be treated
>    transparently (but this doesn't affect the operation of WAP Gateways
>    and authorised transformations as specified in xxxx [ref to be
>    supplied by EdC in
>    [12]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.
>    html])
>
>      [12] 
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0082.html
>
>    francois: Back to the main part of the topic... we don't have any
>    new arguments here. I strongly agree with Eduardo, a developer that
>    started developing mobile content already has a foot in the mobile
>    context and can decide on transcoding issues...
>    ... whereas a developer not aware of this has not chosen to do
>    anything and prob. isn't aware of transcoding issues.
>    ... I don't think it goes against MWBP to mandate the respect of
>    mobile content made by mobile developers, and I don't think it
>    encourages mobile devs to use adaptation.
>    ... It would send a good signal to the mobile dev community to
>    respect content that is already at least a bit mobile.
>    ... we have 2 really different standpoints: one is strongly against
>    mandating heuristics, one in favour. I can't think of a way of
>    balancing the two sides. Any ideas?
>
>    <jo> PROPOSED RESOLUTION: no mandatory heuristics (sorry Dom)
>
>    <dom> booh!
>
>    <EdC> If the main idea is to allow access to desktop sites from
>    mobile devices, why should mobile-specific sites be caught in the
>    transcoding net?
>
>    sean: how about keeping this as a heuristic but mentioning it more
>    prominently than others?
>
>    <jo> PROPOSED RESOLUTION: Add a section saying don't just think
>    once, think twice about these heuristics
>
>    <EdC> Why not put the (unambiguous) heuristics under a rule SHOULD
>    (and not a MUST)? This means CT-proxies must have a really good
>    reason (and demonstrate it) to modify mobile-specific content.
>
>    francois: we could leave heuristics in two categories, but I don't
>    think it'll be clear for people beyond us: heuristics that carry a
>    semantic mobile meaning (e.g. the list Dom sent), and those that do
>    not.
>
>    <jo> PROPOSED RESOLUTION: Add a section saying don't just think
>    once, think twice about these heuristics (and then think again)
>
>    <EdC> 1
>
>    bryan: In general, it'd be good to mention the use of heuristics as
>    a method that should be used where possible to ensure other more
>    semantic methods aren't insufficient. Mandating it is difficult,
>    heuristics are more art than science.
>    ... recommending it is probably valuable.
>
>    francois: EdC recommends a SHOULD not MUST. Our SHOULD is strong, so
>    it would be strong.
>
>    edC: I hope this could balance the two trends you mentioned earlier:
>    if content has been developed for mobile and these heuristics
>    unambiguously identify mobile content (some do not, and we must
>    leave them aside), then unless there is a REALLY good reason to
>    alter that content you should leave it alone. This is what app
>    providers expect.
>    ... If you can do something reasonable with mobile content and it is
>    demonstrably good, then fine.
>
>    <jo> PROPOSED RESOLUTION: Specifically call out the heuristics
>    identified by Dom as SHOULDs and separate them from the other
>    heuristics that are not so strongly indicative of intentional mobile
>    content creation
>
>    <francois> +1
>
>    +1
>
>    <EdC> +1
>
>    <SeanP> -1
>
>    <jo> +1
>
>    <rob> +1
>
>    sean: SHOULD seems too strong. What are the requirements for it?
>
>    francois: you need a good reason to do it - i.e. you can't on a
>    regular basis.
>    ... e.g. if you know the document has tables and user agent doesn't
>    support them: you can remove them.
>
>    sean: one reason is to put toolbars on top and bottom, even on
>    mobile pages. Is that reason good enough?
>
>    francois: in my view no. It's not transformation for the sake of
>    improving content, it's transformation for the sake of branding.
>    ... It provides a consistent user experience.
>
>    edC: one historical example: to clean up the garbage before an XML
>    declaration. Many tools put comments here, screwing up mobile
>    parsers. Cleaning this up is a good example where mobile content
>    should be modifiable.
>
>    <Zakim> jo, you wanted to note that headers and footers on
>    no-transform content is not allowed surely
>
>    edC: adding headers usually disturbs the carefully crafted look and
>    feel of mobile pages, it's the most valuable real estate.
>    ... many sites have pictures at top, navigation at footer (or head
>    on high-end phones).
>
>    francois: I don't see that as a valid reason not to respect the
>    SHOULD
>    ... sean, are you convinced?
>
>    sean: This is what people are asking us for, so it's what we need to
>    do. I'd be happy with a recommendation that heuristics be followed
>    for mobile content, but SHOULD is too strong.
>
>    francois: MAY feels too weak, and there's nothing between that and
>    SHOULD
>
>    jo: a customer that says "even if the content is made for mobile,
>    put headers and footers on it", this doesn't follow the intentions
>    of the content author and respect what they might have done around
>    screen size and images.
>    ... SHOULD is appropriate, on the basis that a product showing this
>    behaviour would not be compliant.
>
>    francois: I agree
>
>    <EdC> Let us remember that it is the deployments that are compliant
>    or not; the products provide the mechanisms, the policies are set by
>    the operators (or other customers).
>
>    <Zakim> rob, you wanted to moot that SHOULD isn't MUST and so is
>    appropriate but that we shouldn't go down the road of itemising all
>    the acceptable exceptions
>
>    rob: I'm reasonably happy with the resolution because it's SHOULD
>    not MUST, and SHOULD implies there will be exceptions some time. I
>    don't think we need to say what they are. Maybe this does involve
>    taking out XML comments, or adding toolbars. I don't think we're the
>    right place to make recommendations on what those exceptions are. I
>    know operators want to see toolbars on operators...
>
>    jo: so they should specify that browsers ship with them
>
>    rob: they're not getting what they want, because CPs (rightly) don't
>    want their content messed with. I don't think we can specify a
>    resolution to win that argument here and now.
>
>    jo: I think it's fine for operators to specify products to insert
>    toolbars, but it's not fine for us to say that's a compliant
>    implementation.
>
>    bryan: we have to keep clear focus on what we're developing. We're
>    not saying "anything you do to mobile content must comply with this
>    spec". If operators want ads, headers, dancing bears, that's up to
>    them... but outside the spec.
>
>    jo: I disagree, it's about transparency and fidelity of access path
>    to providers content. It's not OK for CPs to insert dancing bears
>    onto other peoples content. The spec intentionally (to my mind) says
>    this is not OK.
>
>    bryan: you're not saying "this isn't how CT must work", you're
>    saying "you can't have this biz model"
>
>    jo: you can have that, just not whilst complying with these
>    guidelines
>    ... we're trying to provide a way to say to CPs "develop good mobile
>    experiences, it's the best way to get content onto mobiles". In this
>    doc we say "preserve fideltiy of the channel, so that mobile content
>    isn't messed with and their expectations can be realised".
>
>    edc: what he said... compliance with the spec is with a deployment,
>    not a product.
>
>    <francois> PROPOSED RESOLUTION: Specifically call out the heuristics
>    identified by Dom as SHOULDs and separate them from the other
>    heuristics that are not so strongly indicative of intentional mobile
>    content creation
>
>    <francois> +1
>
>    <rob> +1
>
>    <EdC> +1
>
>    <jo> +1
>
>    <SeanP> -1
>
>    +1
>
>    <Bryan> +1
>
>    <jo> [suggest we review on list and come back to this]
>
>    <jo> [one more PROPOSED RESOLUTION: Content that is an included
>    resource of a document treated transparently should be treated
>    transparently]
>
> Merging task force with the working group
>
>    francois: we mentioned in the last BPWG call that it's a good time
>    to merge CT back with MWBP main body. We're not at the end but these
>    discussions should involve the rest of the group, who'll have to be
>    happy with the decision we've taken. There'll be a single call for
>    CT and MWBP, but when?
>
>    <francois> [13]questionnaire on next calls
>
>      [13] http://www.w3.org/2002/09/wbs/37584/BPWG-mergingcalls/
>
>    francois: depending on decision we take on thursday on this, we may
>    not have a CT-specific call from now.
>    ... I'll send an update re the next call to the list. Qs?
>    ... (there has been no decision re merging)
>
>    sean: on the timing, the current time is better than thursdays
>
>    francois: I've updated the closing date ...
>
> Summary of Action Items
>
>    [End of minutes]
>
>

Received on Tuesday, 6 January 2009 23:49:25 UTC