W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > January 2009

[minutes] CT Call 6 january 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 06 Jan 2009 17:26:15 +0100
Message-ID: <49638627.6060205@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

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 16:26:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 6 January 2009 16:26:49 GMT