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

[minutes] CT Call Tuesday 25 November 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 25 Nov 2008 18:07:09 +0100
Message-ID: <492C30BD.7020501@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/2008/11/25-bpwg-minutes.html

... and copied as text below.


Resolutions taken during the call:
- Add some text in 4.1.5 to state that inferring that a desktop 
User-Agent is needed in the absence of any indication (e.g. URI 
patterns) is contrary to the guidelines
- do not reference CC/PP in Scope for Future Work as a possible future 
way to communicate between a mobile device and a CT-proxy because it 
probably won't be used as such.
- Strike first paragraph in section 4.2.8.1 on transformations carried 
out by CT proxies as it refers to what CT-proxies do (stated in the 
introduction) and does not have any normative meaning.
- Reword "the user agent has linearization or zoom capabilities or other 
features which allow it to present the content unaltered" as "the user 
agent has features (such as linearization or zoom) that allow it to 
present the content unaltered"
- Move the note under 4.2.8.1 to the start of the section


Francois.

-----
25 Nov 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0077.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/11/25-bpwg-irc

Attendees

    Present
           tomhume, Bryan_Sullivan, Eduardo, francois, SeanP, Andrew, jo

    Regrets
           rob

    Chair
           francois

    Scribe
           Tom

Contents

      * [4]Topics
          1. [5]User experience
          2. [6]W3C mobile addressing standards
          3. [7]Capability negotiation on the client side
          4. [8]"Dry" statements for Alteration of Response and LC-2053
             on Classes of Devices (4.2.8.1)
          5. [9]LC-2023 - note instead of alteration of the list
             (4.2.8.1)
          6. [10]Validation against formal published grammar (4.2.8.1)
      * [11]Summary of Action Items
      _________________________________________________________

User experience

    francois: following discussion on-list, Eduardo proposed an
    algorithm to define "improving the user experience", which is tough
    to define
    ... to me this is out of scope as we've decided not to describe the
    internal operations of proxies

    eduardo: agree to leave the algorithm out of scope

W3C mobile addressing standards

    <francois> ISSUE-284?

    <trackbot> ISSUE-284 -- W3C mobile addressing standards -- RAISED

    <trackbot>
    [12]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/284

      [12] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/284

    francois: jo raised this issue after the Verizon statement, where
    they claimed to follow the CT guidelines but advised URI patterns
    which CT lists as examples
    ... the interpretation was also that desktop user-agents should be
    substituted by default. This is contrary to the guidelines we're
    writing.

    <francois> PROPOSED RESOLUTION: Add some text in 4.1.5 to state that
    inferring that a desktop User-Agent is needed in the absence of any
    indication (e.g. URI patterns) is contrary to the guidelines

    SeanP: Verizon are working on changing this document.

    jo: we're starting to put things in because we've seen them in the
    wild, which is risky

    <francois> +1

    <jo> +1

    +1

    <EdC> +1

    RESOLUTION: Add some text in 4.1.5 to state that inferring that a
    desktop User-Agent is needed in the absence of any indication (e.g.
    URI patterns) is contrary to the guidelines

    jo: would like a resolution on the subject of reinforcing the text
    in the Heuristics appendix to say "these are just heuristics"

    francois: feels the guidelines are clear, but could be emphasised
    some more

    <jo> PROPOSED RESOLUTION: Beef up text on Heuristics to say that
    they are *not* endorsed and are not even recommended as good
    practice

    <andrews> +1

    +1

    <francois> +1

    Eduardo: wonders why they're not recommended as best practice

    jo: if we say "it's good practice to use these" we're endorsing
    them.
    ... we're saying "this is not advice of best practice, just an
    observation of what people do"
    ... Verizon said "these are the W3C endorsed mobile addressing
    patterns", but we don't endorse them.
    ... I wouldn't want us to say "it's good practice to use
    x.domainname or domainname/x", but it's worth our saying "if you're
    building a CT proxy, these are the things people typically look out
    for"
    ... it's unsound to recommend people parse site entry points in any
    way, it's worth noting that people do do that.
    ... you should send unaltered headers in the first instance
    ... the pattern of the name should inform you re your decision to do
    this

    Eduardo: wasn't the Verizon thing taking the counterposition of the
    guidelines?

    SeanP: I'd like to amend the proposed resolution to say they're not
    endorsed, but also say "you can't deduce that a site isn't mobile by
    looking at these patterns"

    Bryan: you can't reliably deduce... but the issue of using specific
    url/domain-naming conventions is that it's a practice that isn't
    considered "best practice" but has support.
    ... unless it's driven by W3C/IETF recommendation, we're in danger
    of creating technology. e.g. some older browsers used WSP instead of
    HTTP, and it was dropped after a lot of pain
    ... we should avoid similar situations by implying that this is a
    proposed technology approach

    Eduardo: saying that some of these practices aren't good practices
    will have to be checked. e.g. .mobi domain *is* good practice to
    recognise a mobile site

    francois: jo, could you suggest some text on the mailing list?

    <jo> ACTION: Jo to propose beefed up text on heuristics in respect
    of practice vs good practice [recorded in
    [13]http://www.w3.org/2008/11/25-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-886 - Propose beefed up text on heuristics
    in respect of practice vs good practice [on Jo Rabin - due
    2008-12-02].

Capability negotiation on the client side

    francois: we mentioned POWDER as a possibility to let servers
    communicate with CT proxies. From the clients POV we don't have such
    a reference, CC/PP could be used a bit more in future. We could
    refer to this in "scope for future work".

    jo: CC/PP should be retired in a dignified fashion

    bryan: we should look forward to new technology to solve this
    problem. The OMA Mobile Client Environment MCE group is defining an
    ontology for device capabilities. Should see something coming to the
    market in the next year or two.
    ... (that's the OMA mobile client environment MCE group)

    <francois> PROPOSED RESOLUTION: do not reference CC/PP in Scope for
    Future Work as a possible future way to communicate between a mobile
    device and a CT-proxy because it probably won't be used as such.

    <jo> +1

    <EdC> +1

    <francois> +1

    <SeanP> +1

    RESOLUTION: do not reference CC/PP in Scope for Future Work as a
    possible future way to communicate between a mobile device and a
    CT-proxy because it probably won't be used as such.

"Dry" statements for Alteration of Response and LC-2053 on Classes of
Devices (4.2.8.1)

    francois: conclusion of the discussion from the mailing list was
    that all normative statements must be testable. We must avoid
    wishful thinking or unclear statements.
    ... two statements in particular aren't testable, both in 4.2.8.1

    <francois> [14]section 4.2.8.1

      [14] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-alteration-of-response

    francois: we have 2 statements saying a proxy must do its best not
    to break content, and only adapt to make things better for user
    agents

    francois: how can we reword this along the lines of the Best
    Practice we have on exploiting device capabilities, or do we need
    something else?

    Eduardo: The first paragraph in 4.2.8.1 is questionable on 2
    grounds: it's not testable, and it introduces a restriction in
    setting the scope for what kind of transformations are allowed
    ... there are transformations to match the capabilities of the
    network, not just the handset (e.g. to encode/decode content). This
    statement prohibits that kind of application.

    francois: doesn't think we want to be this rigid

    Eduardo: there is a document about MWBP, if there should be
    something stated it should be to that document (perhaps w/chapter
    references), not as a normative statement but as an indication

    bryan: this is similar to earlier statements we had re the scope of
    the document. When this doc restricts what a CT proxy can do, it
    should be explicit that this is only within the scope of what a CT
    proxy is intended for (translating for purposes of usability), and
    not for e.g. reducing load of network, which should be outside the
    scope of these guidelines.
    ... these statements are OK but shouldn't imply a restriction on the
    same system that's doing CT for other purposes.

    <Zakim> jo, you wanted to agree with the point that these are poor
    as they stand, and to suggest that someone drafts some proposed text
    for these bits

    jo: happy to adopt that text, but think reformatting images *is*
    within scope for this doc.

    SeanP: agree this should be non-normative, but not sure referring to
    BP is much better. "Exploit device capabilities" isn't any more
    testable than what we have here.

    jo: how about striking these sections altogether?
    ... this is leaning towards talking about proxy internals. proxy
    vendors should be free to make a lousy product.

    eduardo: introduction of guidelines talk about improving user
    experience. There could be an indication in an appendix to BP as an
    information reference.

    <francois> PROPOSED RESOLUTION: Strike first paragraph in section
    4.2.8.1 on transformations carried out by CT proxies as it refers to
    what CT-proxies do (stated in the introduction) and does not have
    any normative meaning.

    <Bryan> +1

    jo: we've had comment that the bits that matter here (points 1/2/3)
    get lost in the body

    <francois> +1

    <SeanP> +1

    +1

    <jo> +1

    RESOLUTION: Strike first paragraph in section 4.2.8.1 on
    transformations carried out by CT proxies as it refers to what
    CT-proxies do (stated in the introduction) and does not have any
    normative meaning.

    <EdC> +1

    <andrews> +1

    francois: appendix already contains reference to BP

    <jo> ACTION: Jo to put a reference somewhere to the Best Practice
    about exploiting device capabilities [recorded in
    [15]http://www.w3.org/2008/11/25-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-887 - Put a reference somewhere to the
    Best Practice about exploiting device capabilities [on Jo Rabin -
    due 2008-12-02].

    <jo> ACTION: Jo to be lucky :-) [recorded in
    [16]http://www.w3.org/2008/11/25-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-888 - Be lucky :-) [on Jo Rabin - due
    2008-12-02].

    francois: eduardo, you'd like it to apply to 4.2.8 in the list of
    heuristics
    ... one of the heuristics would be that the proxy would examine the
    user-agent
    ... this goes with features like zoom capability

    <francois> "the user agent has linearization or zoom capabilities or
    other features which allow it to present the content unaltered"

    eduardo: it's actually not general enough. you might have
    desktop-capable user agents on a mobile device without
    linearization, but that's still able to access content from a web
    server. So you can keep that bullet-point, but there are other
    properties of user agents which you have to take into account to
    deal properly with the decision to transform.

    jo: what do we need over and above the phrase "other features"?

    <jo> PROPOSED RESOLUTION: Reword "the user agent has linearization
    or zoom capabilities or other features which allow it to present the
    content unaltered" "the user agent has features such as
    linearization or zoom that allow it to present the content
    unaltered"

    <jo> PROPOSED RESOLUTION: Reword "the user agent has linearization
    or zoom capabilities or other features which allow it to present the
    content unaltered" as "the user agent has features (such as
    linearization or zoom) that allow it to present the content
    unaltered"

    francois: perhaps "the user agent as identified by some evidence in
    the http request"?

    eduardo: didn't someone say evidence is a terminology in some other
    group?

    francois: used by the DDR Simple API

    jo: we don't care how the user agent is determined

    RESOLUTION: Reword "the user agent has linearization or zoom
    capabilities or other features which allow it to present the content
    unaltered" as "the user agent has features (such as linearization or
    zoom) that allow it to present the content unaltered"

    <francois> Close ACTION-880

    <trackbot> ACTION-880 Review LC-2053 and clarify to group closed

LC-2023 - note instead of alteration of the list (4.2.8.1)

    francois: in 4.2.8.1 Jo inserted a note instead of what had been
    agreed. Are we fine with the note?

    jo: the note should be moved to the top of the section

    <jo> PROPOSED RESOLUTION: Move the note under 4.2.8.1 to the start
    of the section

    <francois> +1

    RESOLUTION: Move the note under 4.2.8.1 to the start of the section

    <francois> ACTION-881?

    <trackbot> ACTION-881 -- Jo Rabin to enact resolution on 4.2.8.1 ref
    adding character-encoding to the list of format, layout, dimensions
    etc. -- due 2008-11-17 -- PENDINGREVIEW

    <trackbot>
    [17]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/881

      [17] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/881

    <francois> Close ACTION-881

    <trackbot> ACTION-881 Enact resolution on 4.2.8.1 ref adding
    character-encoding to the list of format, layout, dimensions etc.
    closed

Validation against formal published grammar (4.2.8.1)

    francois: for the time being, it says SHOULD validate. Discussion on
    the mailing list is that we could split this into 2 guidelines:
    content MUST be well formed (if it's XML), the second being that it
    SHOULD validate to a formal grammar.

    <EdC> are there other formal notions of well-formedness than just
    for XML?

    <francois> PROPOSED RESOLUTION: ref. Validation against formal
    published grammar, two guidelines "The altered content MUST be
    well-formed (if it's XML-based)" and "The altered content SHOULD
    validate to an appropriate published formal grammar"

    francois: if we split into 2 guidelines, will it be misunderstood?

    <Zakim> jo, you wanted to say that it is probably clearer as it is

    jo: it already echoes the language of the BP doc, I'd rather leave
    as is
    ... the doc says it SHOULD validate according to a published formal
    grammar. If there's no published formal grammar for the content
    type, this can't be complied with (hence this being a SHOULD) and
    there are reasons not to comply with formal grammars even when you
    can (hence SHOULD)
    ... ponders what virtue there is to well-formedness

    eduardo: if we ask for well-formedness we're stating a minimum

    jo: it should still only be a SHOULD; there are cases where
    well-formedness works less well than non-well-formed on some devices

    eduardo: is there an example where non-well-formedness is an
    example? we couldn't see one.
    ... there are examples where you want to restrict the whole set of
    well-formed documents to a smaller set, because of browsers being
    particular. But these are still well-formed documents.

    SeanP: if we put in a statement about well-formedness, what does it
    buy us here? Proxies aren't going to create non-well-formed if
    browsers can't handle them ("don't put in bugs") so why do we need
    this?

    eduardo: if best practice is not to put in bugs, well-formedness is
    the way not to put in bugs.

    francois: I share Sean and Jo's POV, that there isn't enough added
    value to say "content must be well formed" given that there could be
    an example where this isn't required. What value does having two
    statements instead of one add?

    <jo> -1 to well formed

    <EdC> +1 to wf

    <francois> 0 to well formed

    <Bryan> -1

    0

    <andrews> 0

    <SeanP> -1 to well formed, but I don't care that much

    francois: let's think about this and return to it next week

Summary of Action Items

    [NEW] ACTION: Jo to be lucky :-) [recorded in
    [18]http://www.w3.org/2008/11/25-bpwg-minutes.html#action03]
    [NEW] ACTION: Jo to propose beefed up text on heuristics in respect
    of practice vs good practice [recorded in
    [19]http://www.w3.org/2008/11/25-bpwg-minutes.html#action01]
    [NEW] ACTION: Jo to put a reference somewhere to the Best Practice
    about exploiting device capabilities [recorded in
    [20]http://www.w3.org/2008/11/25-bpwg-minutes.html#action02]

    [End of minutes]
Received on Tuesday, 25 November 2008 17:07:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 November 2008 17:07:47 GMT