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

[minutes] BPWG F2F in Sophia, day 1

From: Francois Daoust <fd@w3.org>
Date: Tue, 17 Jun 2008 17:23:18 +0200
Message-ID: <4857D6E6.50805@w3.org>
To: MWI BPWG Public <public-bpwg@w3.org>

Hi,

I cleaned the minutes of our busy Content Transformation day during the F2F:
http://www.w3.org/2008/06/16-bpwg-minutes.html

... copied as text below.

Most of the issues were resolved and closed!
Next step is to update the draft to reflect the resolutions, resolve the 
remaining hot issue, on our way to publication as a Last Call Working Draft.

Francois.


16 Jun 2008

    [2]Agenda

       [2] http://docs.google.com/View?docid=dd3jk8v_114tkbg6kgj

    See also: [3]IRC log

       [3] http://www.w3.org/2008/06/16-bpwg-irc

Attendees

    Present
           Ed, Jo, Adam, Zack, DKA, Kai, Sunghan, Jonathan, SeanP, Dom,
           Francois, Scott, Rob, Abel, Miguel, Manrique

    Regrets
    Chair
           Dan, Jo

    Scribe
           Matt, edm, rob, SeanP

Contents

      * [4]Topics
          1. [5]Content Transformation - Informative/Normative
          2. [6]Content transformation - Quick review
          3. [7]Content transformation - ISSUE-259 (Informative or
             Normative)
          4. [8]Content transformation - ISSUE-187 (Link/Rel to MOK
             versions of non-MOK resources)
          5. [9]Content transformation - ISSUE-222 (TAG Finding on
             Alternative Representations)
          6. [10]Content transformation - ISSUE-261 (Scoping bogus 200
             responses)
          7. [11]Content transformation - ISSUE-257 (Clarification of
             section 4.1.2)
          8. [12]Content transformation - ISSUE-243 (Use of OPTIONS)
          9. [13]Content transformation - ISSUE-224 (Sanity Checking)
         10. [14]Content transformation - ISSUE-223 (Jo's CT Shopping
             List)
         11. [15]Content transformation - ISSUE-241 (Tokenization of
             URIs)
         12. [16]Content transformation - ISSUE-255 (Subdomain and Path
             as a heuristic in content transformation)
         13. [17]Content transformation - ISSUE-258 (Requirements
             section: merging 3.1 and 3.2)
         14. [18]Content transformation - ISSUE-260 (Do the guidelines
             address Client/Proxy solutions)
         15. [19]Content transformation - ISSUE-242 (User expression of
             persistent and session preferences)
         16. [20]A quick look on the agenda
      * [21]Summary of Action Items
      _________________________________________________________

Content Transformation - Informative/Normative

    dom: Normative or informative -- it can be informative if you won't
    require people to conform to it. BP's are informative because people
    use them as a guide.
    ... MobileOK is normative, because we want people to conform to it.
    ... When BP was chartered it was decided that the CT work would be
    informative.
    ... The charter was not about creating new technologies.
    ... For normative docs the w3c patent policy applies, which means
    members with patents agree to give royalty free licenses... this
    does not apply to informative docs.
    ... We can't make them normative for the time being. The question is
    the legal risk more expensive than rechartering the group to make it
    normative?

    DKA: What about amending the charter at extension time?

    dom: If we want to change from informative to normative, you need to
    recharter the group.
    ... We have to propose something to the w3m, the AC reviews the
    charter for four weeks, and then a 45 day grace period for rejoining
    the group.
    ... It takes about a month or two.
    ... Then republish as WD...
    ... Then 150 days before published as PR.

    <Zakim> Kai, you wanted to ask about a mismatch between the
    intention of the document and what a normative specification
    represents

    Kai: When you look at a specification, it's supposed to be something
    that is implemented, not a lot of room to interpret, etc. A
    guideline has a lot more wiggle room.
    ... How do we say they've fulfilled the specification?

    dom: My reading is that they're testable.
    ... WCAG is testable for instance.

    DKA: Yes, these should be testable, the work is specific enough.

    Kai: In the end you have to say "yes or no" to whether it's adhered
    to.

    <group pauses for station identification>

    jo: Propose continuing the group to end of charter with doc being
    informative. When the group recharters I suggest that we take the
    work continue in a normative fashion.
    ... We don't lose much, only 6 months.

    dom: We can extend the group without having an AC review for up to a
    year...

    jo: The group probably should be rechartered if it's going to go
    beyond this year.

    <DKA1> PROPOSED RESOLUTION: The CT document should be taken to its
    conclusion under the current chartered (non-normative) and therefore
    the question of whether to change it to a normative document should
    be put off to the future re-chartering.

    jo: Can we change an informative rec into a normative rec?

    francois: Maybe we can make normative tests that reference the
    informative guidelines?

    jo: We don't want to lose momentum.

    DKA: I'm concerned that it will impact the usefulness of the doc in
    the long run.

    jo: Anyone who wants to conform to it will conform to it.

    DKA: I don't think it will impact the conformance but the IP.
    ... Because it won't be covered under the w3c IP policy.
    ... The chance of someone having patents on the HTTP stuff is
    probably low.

    jo: We've had this discussion already. The rational thing to do is
    to take legal advice.
    ... There are many people who are not w3c members who have patents
    and are not obliged to declare them..

    Kai: Why is this so important with this document?

    DKA: This doc is the one that gets furthest down the road towards
    implementing new technology -- but it is NOT introducing...
    ... I think we should accept this resolution and then seek legal
    advice, give an action to a w3c-er to find out.

    dom: Asking the lawyer will result in a no.

    jo: Perhaps we can refine the question.

    DKA: Is there a way we can continue with the doc as it is, but work
    in the background so we don't lose time before rechartering?
    ... We get it to CR, and leave it there until July of 2009.

    jo: How does this mitigate IP problems?

    SeanP: Can we ask for testimonials?

    <Zakim> edm, you wanted to ask about publishing the doc as is or
    inserting some statement re its anticipated normative future (or
    not...)

    SeanP: Wouldn't necessarily be enforceable, but make it feel better.

    edm: Can we expose what we're talking about now in the document? Say
    that it's anticipated to become normative?

    DKA: You say keep it informative, but put wording in saying "sorry,
    we forgot to make it normative?"

    edm: Is it better to do it as we are, or to spell it out?

    Kai: I don't see the problem. If we make it a normative document,
    the process deals with it.

    jo: The issue is that we have to change the charter to make it
    normative. We can't
    ... produce normative stuff in this charter.

    dom: We could start rechartering now...

    jo: I would be uncomfortable rechartering without knowing the future
    of the MWI.

    dom: I don't believe the group will close regardless of what happens
    to the MWI.

    DKA: It seems like the work will go on regardless.

    SeanP: There's talk about slowing down the momentum if we
    recharter...

    DKA: It will slow things down, the AC has to review it.

    dom: Plus there's the delay of getting your AC rep to rejoin the
    group, etc.

    DKA: Plus writing the charter, etc time for the staff.

    Kai: There's no short cut?

    dom: I don't believe there is when there's a patent policy
    implication.
    ... People still had to disclose patents, even for informative docs.

    Kai: Now if the doc remains informative, this patent stuff isn't an
    issue...

    DKA: Yes, but you could be exposing the entire ecosystem down the
    line...

    jo: But only adding in exposure from the WG members.

    dom: People in the WG are developing this, and don't want to put
    things in there that are patented, even by those outside the group.
    ... If you have patents and are in the group, you are giving a
    license.

    matt: If this WG is representative of the ecosystem as a whole, and
    the WG doesn't believe it's patentable, that's a good indicator that
    it might not be.

    DKA: That's why I'm leaning towards @@
    ... Perhaps the new charter includes a conformance document that
    references this doc... very lightweight.

    dom: But you lose the patent commitments...
    ... We should take the resolution now or if we make it normative,
    start the recharterting process now
    ... and otherwise keep it informative and leave it alone.

    <Zakim> rob, you wanted to note that Openwave las lots of patents,
    some that might be relevant - but I haven't checked through them to
    know if they are essential

    rob: We've got lots of patents that might be relevant, haven't
    checked them, haven't gotten the lawyers to look at them either.

    DKA: The downside of going into this process is that it might
    trigger a whole lot of legal searches, etc

    dom: It's not a downside.

    DKA: Do we think rechartering would significantly delay things?

    dom: The biggest risk is that we lose members.

    jo: It's not clear that members who signed up through December would
    be happy to go beyond that.

    dom: There's always the chance for participants to leave at any
    time.

    <Zakim> Kai, you wanted to ask about going normative with an
    unfinished document and the legal issues involved

    Kai: I wouldn't bring a doc to the lawyers until it's just about
    done.

    dom: There are various calls for exclusions during the publishing
    process.
    ... You never quite get to see the final document before it's
    finished.

    DKA: Two options: 1. Restart rechartering process now, where the
    only changes: would be the informative to normative change for this
    doc, as well as extend the WG, 6 months into 2009
    ... Option 2: Do nothing, issue document non-normatively, possibly
    revisit in December, but no guarantees.
    ... Having the document being normative would shield you, somewhat
    from member-IP.

    dom: Anything they don't exclude you get a license for.
    ... Very few charters have been rejected after AC review.

    q

    matt: If the charter ran out in December, and you wanted a new
    charter, would there be more work that you might want to add to the
    WG than just these?

    DKA: The talk right now is that we just want to wind down the work
    that's in the charter... and then <mixed metaphor about zombies or
    something>
    ... I favor the idea of not adding more work items.

    jo: "Option 2: Do nothing, issue document non-normatively, possibly
    revisit in December, but no guarantees." -- plus get legal advice.

    1 vote for option 2, option 1 had five or so votes...

    dom: Jo, voting for option 2, is there a strong objection to 1?

    jo: I will not object given the strength of feeling on this but
    there is no chance of my working on writing a new charter given my
    current work load

    DKA: I think people will look even closer when we recharter at the
    CT stuff.
    ... Let's take a resolution that reflects the rough consensus.

    Kai: Option 1 still needs everyone to check their legal stuff before
    we recharter.

    matt: Does this mean jo leaves asap or at end of the year?

    PROPOSED RESOLUTION: Restart rechartering process now, where the
    only changes: would be the informative to normative change for this
    doc, as well as extend the WG, 6 months into 2009

    <DKA1> +1

    <Kai> +1

    <rob> +1

    <dom> I object

    <SeanP> +1

    <dom> NOT

    <edm> +1

    <dom> ACTION: francois to start the rechartering process [recorded
    in [22]http://www.w3.org/2008/06/16-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-776 - Start the rechartering process [on
    François Daoust - due 2008-06-23].

    RESOLUTION: Restart rechartering process now, where the only
    changes: would be the informative to normative change for this doc,
    as well as extend the WG, 6 months into 2009

    <jo> I abstain

    <edm> scribe: edm

    <scribe> scribenick: edm

Content transformation - Quick review

    dka: would like to get the CT document as close as possible to last
    call working draft status

    <francois> [23]latest draft

      [23] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606

    dka: suggest a quick walkthrough

    francois: emphasis on quick - let's focus on the remaining issues

    <DKA1>
    [24]http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0049.htm
    l

      [24] http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0049.html

    francois: CT guidelines focus on the proxy between the user and the
    server...

    <dom> [25]13 open issues on content transformation guidelines

      [25] http://www.w3.org/2005/MWI/BPWG/Group/track/products/12

    francois: ... so that content provider retains some control over
    proxy behavior
    ... CT guidelines are organized as request side and response side
    ... restrictions appear mostly on the request side - less on the
    response side
    ... let's review the remaining issues

Content transformation - ISSUE-259 (Informative or Normative)

    <francois> Close ACTION-756

    <trackbot> ACTION-756 Seek further legal advice on the patent issues
    around CT closed

    dka: let's close the informative vs. normative issue - as per this
    morning's discussion

    <francois> Close ACTION-757

    <trackbot> ACTION-757 Seek opinion on CT Patent issue closed

    <francois> + Close ISSUE-259

Content transformation - ISSUE-187 (Link/Rel to MOK versions of non-MOK
resources)

    francois: issue-187 (old)

    <jo> ISSUE-187?

    <trackbot> ISSUE-187 -- Link/Rel to MOK versions of non-MOK
    resources -- OPEN

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

      [26] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/187

    francois: ISSUE-187 Link/Rel to MOK versions of non-MOK resources

    jo: this relates to ISSUE-222...

Content transformation - ISSUE-222 (TAG Finding on Alternative
Representations)

    ISSUE-222?

    <trackbot> ISSUE-222 -- TAG Finding on Alternative Representations
    -- OPEN

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

      [27] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/222

    francois: link element is the key
    ... guidelines specify CT proxy should redirect to handheld
    representation...
    ... ...but the server should indicate the medium for the intended
    presentation...

    dka: what's the negative of using the link element to link to
    itself?

    jo: how do you determine if the representation from the URI is a
    link to self

    <dom> [28]Media descriptors in HTML 4.01 rec

      [28] http://www.w3.org/TR/html401/types.html#type-media-descriptors

    <dom> "Future versions of HTML may introduce new values and may
    allow parameterized values. To facilitate the introduction of these
    extensions, conforming user agents must be able to parse the media
    attribute value as follows:

    <dom> 1. The value is a comma-separated list of entries. For
    example,

    <dom> media="screen, 3d-glasses, print and resolution > 90dpi"

    <dom> is mapped to:

    <dom> "screen"

    <dom> "3d-glasses"

    <dom> "print and resolution > 90dpi"

    <dom> "

    <jo> PROPSOSED RESOLUTION: Link header/element with media type of
    handheld and an empty URI indicates that the current resource is
    intended for handheld presentation

    jo: we need means for the origin server to signal that this
    representation is meant for this presentation

    dom: points out a difference between the URI referring to the
    representation of the resource and/or the representation
    ... if you send the right user agent header you should get the right
    representation

    jo: some URIs point to abstract resource, some to specific
    representations of this resource

    dom: CT guidelines suggest not transforming anything that claims to
    be mobile friendly - whether or not it really is

    <dom> maybe "s/the current resource/the current representation/"

    jo: in response to mobile headers, whose mobile friendly content
    should apply - origin server's or proxy's?

    <jo> PROPOSED RESOLUTION: Having requested a resource with mobile
    headers, a Link header/element with media type of handheld and an
    empty URI indicates that the current representation of the resource
    is intended for handheld presentation

    <dom> +1

    dom: the decision of what is appropriate representation rests with
    the content provider

    <dom> [29]Results of testing 406 responses on mobile browsers

      [29] http://www.w3.org/2008/06/rejected-mwbp-test/results

    Francois: 404 response works, 406 not necessarily for all browsers

    dka: media handheld is what is being supported now, other media
    types could be considered when get introduced

    <Zakim> jo, you wanted to say something meaningful

    <dom> [30]profile attribute on HEAD in HTML

      [30] http://www.w3.org/TR/html401/struct/global.html#adef-profile

    <jo> PROPOSED RESOLUTION: a Link header/element with media type of
    handheld and a URI referring to a location within the resource
    indicates that the current representation of the resource is
    intended for handheld presentation

    dka: would this allow to close ISSUE-222?

    <rob> +1

    <francois> +1

    <jo> +1

    <Kai> +1

    <DKA1> +1

    <SeanP> +1

    RESOLUTION: a Link header/element with media type of handheld and a
    URI referring to a location within the resource indicates that the
    current representation of the resource is intended for handheld
    presentation

    <Kai> ScribeNick: Kai

    DKA: only the tag thing needs to be resolved for this issue

    <jo> PROPOSED RESOLUTION: Make the point explicitly in the document
    that an empty href on a link header/element means that this reource
    is capable of being rendered in a way that is suitable for handhelp
    presentation, but that without the above link element there is a
    question as to whether this representation is or is not suitable for
    handheld

    Jo: if you have an emtpy href it could mean it is or could be
    rendered as handheld

    francois: the important part is the fragment. you could link to
    yourself

    dom: does that effect the resolution we just took?

    francois: no not really.

    <jo> PROPOSED RESOLUTION: Make the point explicitly in the document
    that an href which refers to this resource but which does not have a
    fragment identifier on a link header/element means that this reource
    is capable of being rendered in a way that is suitable for handheld
    presentation, but that without the above link element there is a
    question as to whether this representation is or is not...

    <jo> ...suitable for handheld

    <francois> +1

    <DKA1> +1

    RESOLUTION: Make the point explicitly in the document that an href
    which refers to this resource but which does not have a fragment
    identifier on a link header/element means that this reource is
    capable of being rendered in a way that is suitable for handheld
    presentation, but that without the above link element there is a
    question as to whether this representation is or is not...

    <SeanP> +1

Content transformation - ISSUE-261 (Scoping bogus 200 responses)

    <dom> ISSUE-261?

    <trackbot> ISSUE-261 -- Scoping 200 responses that should be
    regarded as 406 responses -- OPEN

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

      [31] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/261

    francois: Topic ISSUE-261

    <edm> ISSUE-261?

    <trackbot> ISSUE-261 -- Scoping 200 responses that should be
    regarded as 406 responses -- OPEN

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

      [32] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/261

    francois: I am not sure how many websites will send human readble
    responses about an error
    ... Aaron was going to send some stats on this
    ... he has not yet, but could bring stats within 2 weeks
    ... is our recommendation useful and needed?

    dom: does dotmobi have studies on this?

    jo: not that I know of

    Dka: is that a meaningful question? If one or two high use sites do
    it, that would already be as damaging as many low use sites

    francois: if only a few are doing that, proxies could list those and
    send different headers

    jo: however they do it does not concern the guidelines#

    dka: the guidelines are written thinking that more and more site
    adapt, operators use proxies...problems will become bigger problems,
    which is why we are setting these rules down.
    ... this is the whole point...anticpation
    ... we try to codfiy it before it becomes a problem

    francois: we already have enough restritction on http header
    modification

    dka: key is are recommeding this approach or not?
    ... for when a 200 response is sent but there is no link header. If
    they do see it they should consider it.
    ... we are justified to put this in the doc

    SeanP: so you say we will have to do something about this anyway?

    DKA: yes

    jo: we could not mention bogus responses
    ... or we say a 200 response like that is a rejection
    ... if there is no no-transform this is intentional

    SeanP: I think we should mention it. we don't want to be too vague.

    DKA: we should be explicit

    <jo>
    [33]http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0039.
    html

      [33] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0039.html

    jo is going through his email

    jo: proposes to use the pertinent part of the document, with some
    editorial changes

    <jo> jo quotes the following:

    <jo> The logic of 4.1.2 would then be:

    <jo> Request resource with original headers

    <jo> - If the response is a 406 response, re-request with altered
    headers

    <jo> (unless the 406 response contains no-transform).

    <jo> - If the response is a 200 response,

    <jo> -- if the response contains vary: User-Agent, an appropriate
    link

    <jo> element or header, or no-transform, forward it

    <jo> -- otherwise assess (by unspecified means) whether the 200
    response is a

    <jo> bogus one

    <jo> --- if it is not, forward it

    <jo> --- if it is, re-request with altered headers

    jo: we would not want this to become a normative algorythm

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal
    for a process for a process for CT bogus 200 response detection
    (4.1.2) and close ISSUE-261.

    <jo> +1

    <francois> +1

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal
    for a process for a process for CT bogus 200 response detection
    (4.1.2) and close ISSUE-261.

    <dom> +1

    RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process
    for a process for CT bogus 200 response detection (4.1.2) and close
    ISSUE-261.

    <francois> Close ACTION-673

    <trackbot> ACTION-673 See if he can get some figures that scope the
    problem of bogus 200 responses closed

    <francois> Close ACTION-768

    <trackbot> ACTION-768 Ping Aaron on scoping bogus 200 responses
    closed

    francois: so I don't have to bother aaron

    <francois> Close ACTION-771

    <trackbot> ACTION-771 Send a proposal on using meta data to alert
    CT-proxy that this is a rejected response even if it's a 200 closed

    <jo> ACTION: Jo to edit 4.1.2 according to above resolution
    [recorded in
    [34]http://www.w3.org/2008/06/16-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-777 - Edit 4.1.2 according to above
    resolution [on Jo Rabin - due 2008-06-23].

Content transformation - ISSUE-257 (Clarification of section 4.1.2)

    francois: ISSUE-257?

    ISSUE-257?

    <dom> ISSUE-257?

    <trackbot> ISSUE-257 -- Clarification of section 4.1.2 -- OPEN

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

      [35] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/257

    francois: I would like to resolve to rename the section

    jo: i would prefer if we address specific points
    ... (going through document)
    ... Section 4.1.2

    <DKA1> a) the user would be prohibited from accessing content as a
    result of a

    <DKA1> 406 or bogus 200 response;

    <DKA1> b) the user has specifically requested a restructured desktop
    experience;

    <DKA1> c) the request is part of a session of some sort and either
    it is

    <DKA1> technically infeasible not to adjust the request because of
    earlier

    <DKA1> interaction, or because doing so preserves a consistency of
    user experience.

    <DKA1> In that section my understanding of what we are trying to do
    is

    <DKA1> identify that the request headers should not be altered
    unless:

    <DKA1> a) the user would be prohibited from accessing content as a
    result of a

    <DKA1> 406 or bogus 200 response;

    <DKA1> b) the user has specifically requested a restructured desktop
    experience;

    <DKA1> c) the request is part of a session of some sort and either
    it is

    <DKA1> technically infeasible not to adjust the request because of
    earlier

    <DKA1> interaction, or because doing so preserves a consistency of
    user experience.

    jo: i think together with renaming this is the essence of what we
    are trying to say

    francois: we still need to deal with user preferences

    jo: yes, need to have a discussion on it
    ... so we would remove the unnumbered bullets and reword 1 through 3
    ... do we need very specific text here?
    ... there are three cases to consider

    dka: that removes the discussion of prior knowledge, server behavior
    etc.

    jo: yes it does

    dka: it removes the ability for CT proxies to rely on user
    preferences

    francois: that is a different discussion

    dka: the request doesn't have to be at that point

    jo: that's for us to define

    seanp: can look at the exact text?
    ... tick...tick...tick...tick

    <jo> Proxies should not intervene in methods other than GET, POST,
    HEAD and PUT.

    <jo> If there is a no-transform directive present in the request the
    proxy should not modify the request headers.

    <jo> The proxy should not modify request headers unless:

    <jo> a) the user would be prohibited from accessing content as a
    result of a

    <jo> 406 or bogus 200 response;

    <jo> b) the user has specifically requested a restructured desktop
    experience;

    <jo> c) the request is part of a session of some sort and either it
    is

    <jo> technically infeasible not to adjust the request because of
    earlier

    <jo> interaction, or because doing so preserves a consistency of
    user experience.

    <jo> Note:

    <jo> Rejection of a request by a server is taken to mean both a HTTP
    406 Status as well as HTTP 200 Status, with content indicating that
    the request cannot be handled - e.g. "Your browser is not supported"

    dka: this replaces all up to point 3) in 4.1.2

    francois: can we change the name of the section?

    SeanP: this is to remove the duplication and make it clearer?

    <DKA1> PROPOSED RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT
    document (pending some editorial "tweaking") and close ISSUE-257.

    dka: any objections?

    <DKA1> +1

    <francois> +1

    RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT document (pending
    some editorial "tweaking") and close ISSUE-257.

Content transformation - ISSUE-243 (Use of OPTIONS)

    francois: could we agree on issue-243 to leave it and address it
    later?
    ... it's linked to POWDER and can probably wait?

    <jo> ACTION: Jo to add the stuff on possible use of OPTIONS to the
    appendix [recorded in
    [36]http://www.w3.org/2008/06/16-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-778 - Add the stuff on possible use of
    OPTIONS to the appendix [on Jo Rabin - due 2008-06-23].

    francois: I will take the action

    <dom> ACTION-777?

    <trackbot> ACTION-777 -- Jo Rabin to edit 4.1.2 according to above
    resolution -- due 2008-06-23 -- OPEN

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

      [37] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/777

    <DKA1> PROPOSED RESOLUTION: Close ISSUE-243.

    <francois> PROPOSED RESOLUTION: Close ISSUE-243 and mention it in
    "Scope for Future Work" appendix

    <DKA1> PROPOSED RESOLUTION: Close ISSUE-243 and mention this topic
    in the appendix as scope for future work.

    <francois> +1

    RESOLUTION: Close ISSUE-243 and mention this topic in the appendix
    as scope for future work.

Content transformation - ISSUE-224 (Sanity Checking)

    ISSUE-224?

    <trackbot> ISSUE-224 -- How should we make an assessment of the
    impact of the various possible guidelines on real web sites -- OPEN

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

      [38] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/224

    francois: don't know how to address that?

    jo: it is not so much of an issue today.

    dom: the cr phase would be for that

    <DKA1> PROPOSED RESOLUTION: regarding ISSUE-224, we are no longer as
    worried about the impact of these guidelines on existing content, so
    this issue can be closed and the topic left to the exit-criteria
    from CR (testing implementations).

    <francois> +1

    <DKA1> PROPOSED RESOLUTION: regarding ISSUE-224, we are no longer as
    worried about the impact of these guidelines on existing content, so
    this issue can be closed and the topic left to the exit-criteria
    from CR (testing implementations) - and close ISSUE-224.

    <francois> Close ACTION-774

    <trackbot> ACTION-774 Check the OPTIONS method for ISSUE-243 closed

    <jo> +1

    RESOLUTION: regarding ISSUE-224, we are no longer as worried about
    the impact of these guidelines on existing content, so this issue
    can be closed and the topic left to the exit-criteria from CR
    (testing implementations) - and close ISSUE-224.

    <DKA1> lunch!

    dka: we will continue to go through issues after lunch. Will do
    scheme discussion after second break.

    <DKA1> Returning from lunch.

    <rob> Scribe: rob

    <scribe> scribenick: rob

    dka: 6 issues remain...

Content transformation - ISSUE-223 (Jo's CT Shopping List)

    <dom> ISSUE-223?

    <trackbot> ISSUE-223 -- Various Items to Consider for the CT
    Guidelines -- OPEN

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

      [39] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/223

    francois: 1-6 already dealt with
    ... point 7 seems like nothing we can do without inventing new
    technology
    ... POWDER could be used in future

    jo: points 7,8,9,11 are the same - future work

    <DKA1> PROPOSED RESOLUTION: From Jo's list (ISSUE-223) we will
    consider points 7, 8, 9 and 11 as out of scope for the current work
    (but possibly in scope for future work).

    <francois> +1

    <SeanP> +1

    +1

    RESOLUTION: From Jo's list (ISSUE-223) we will consider points 7, 8,
    9 and 11 as out of scope for the current work (but possibly in scope
    for future work).

    <jo> ACTION: Jo to transcribe points 7 8 9 and 11 of ISSUE-223 into
    Scope for future work [recorded in
    [40]http://www.w3.org/2008/06/16-bpwg-minutes.html#action04]

    <trackbot> Created ACTION-779 - Transcribe points 7 8 9 and 11 of
    ISSUE-223 into Scope for future work [on Jo Rabin - due 2008-06-23].

    francois: point 10 is MobileOK required for CT-proxies?

    dka: seems obvious, it's overloading the doc

    jo: in doc sec 4.4 we said CT-proxy output should validate according
    to a formal standard

    <DKA1> PROPOSED RESOLUTION: On point 10 of ISSUE-223 (whether CT
    proxies should be MobileOK) we should remain silent.

    <SeanP> +1

    <DKA1> +1

    +1

    <Kai> +1

    RESOLUTION: On point 10 of ISSUE-223 (whether CT proxies should be
    MobileOK) we should remain silent.

    francois: point 12 - if content is mobileOK then can it be
    transformed?

    <DKA1> PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT
    proxies should refrain from transforming MobikeOK content) we should
    allow for the possibility that CT proxies should be able to
    transform MobikeOK content but that they should take into account
    MobileOK-ness as part of the heuristics involved in determining
    whether content is mobile-friendly.

    <SeanP> +1

    kai: content could still be transformed (from mobileOK to mobileOK)
    because a CT-proxy knows somehting about the device that the
    original content didn't account for

    jo: RFC2616 has an example about medical imaging content that
    mustn't be altered

    <DKA1> PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT
    proxies should refrain from transforming MobikeOK content) we should
    allow for the possibility that CT proxies should be able to
    transform MobikeOK content but that they should take into account
    MobileOK-ness as part of the heuristics involved in determining
    whether content is mobile-friendly (but remain silent on how you
    check if something is mobileOK).

    <francois> +1

    <SeanP> +1

    +1

    <Kai> +1

    <dom> +1

    <DKA1> PROPOSED RESOLUTION: On point 12 of ISSUE-223 (whether CT
    proxies should refrain from transforming MobikeOK content) we should
    allow for the possibility that CT proxies should be able to
    transform MobileOK content but that they should take into account
    MobileOK-ness as part of the heuristics involved in determining
    whether content is mobile-friendly (but remain silent on how you
    check if something is mobileOK).

    RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should
    refrain from transforming MobileOK content) we should allow for the
    possibility that CT proxies should be able to transform MobileOK
    content but that they should take into account MobileOK-ness as part
    of the heuristics involved in determining whether content is
    mobile-friendly (but remain silent on how you check if something is
    mobileOK).

    <jo> +1 (in respect of Mobikes)

    <jo> ACTION: Jo to add text to section 4.4 referencing above
    resolution on mobikeOK [recorded in
    [41]http://www.w3.org/2008/06/16-bpwg-minutes.html#action05]

    <trackbot> Created ACTION-780 - Add text to section 4.4 referencing
    above resolution on mobikeOK [on Jo Rabin - due 2008-06-23].

Content transformation - ISSUE-241 (Tokenization of URIs)

    ISSUE-241?

    <trackbot> ISSUE-241 -- Tokenization of URIs -- OPEN

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

      [42] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/241

    francois: do we need to say anything about changing links in an
    adapted session to "made-up links" to the CT-proxy's own domain so
    it can invent new URLs for sub-pages, javascript events, etc

    dom: so what about rewriting URLs in a page of search-results?

    seanP: they all get rewritten

    jo: if you follow what it says in sec 4.1 you will then fall out of
    the transforming loop

    dom: URL re-writing does overwrite the Host: request header

    jo: it would be inconsistent to allow users to go to the operator
    portal and the operator to rewrite URLs to the whole of the Internet
    to then assume they are compliant

    <dom> [I would request at least that the issue be re-titled]

    francois: need to ensure content-providers at least can see the
    requests as faithfully as possible when appropriate

    jo: this touches on the undefined concept of a "session" being
    entered where the CT-proxy is unavoidably explicitly addressed by
    all requests from the handset

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request to a
    new server, this is a different "session" and therefore the content
    must be tasted.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request to a
    new "web site", this is a different "session" and therefore the
    content must be tasted (allowing for different heuristics for
    determining whether request is to a different or the same "web
    site.")

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request to a
    new "web site", this is a different "session" and therefore the
    content must be tasted (allowing for different heuristics for
    determining whether request is to a different or the same "web site"
    but giving "hitting a new domain name" as a good example.)

    jo: key issue is if CT-proxy is transforming content for site A and
    then makes bad decisions in continuing transformation following
    links to site B that would normally be mobile-friendly

    kai: domain name isn't a great distinguishing feature for websites,
    eg images often served from different domains

    seanP: in the CT world, we tend to think of a "session" as something
    between the handset and CT-proxy, not between bandset and website

    dom: currently guidelines allow you to carry on transforming all the
    time (even after following a link to mobile-friendly site) after you
    have started transforming a website that needed transformation

    jo: do we need to distinguish between "linked resources" (eg <a
    href="...">) and "included resources" (eg <img src="..." />)
    ... ?

    dka: do we stand a chance of resolving this issue today? Or should
    we leave it for future work?
    ... should we tease apart the two sides of the CT-proxy and define
    "sessions" on both sides?
    ... or concentrate on rules for "tasting content"?

    jo: both in my opinion

    <DKA1> PROPOSED RESOLUTION: Except in the case of https, the content
    transformation guidelines document does not differentiate between
    URI rewriting and so-called "transparent" proxy operation.

    <DKA1> PROPOSED RESOLUTION: For CT guidlines, for included resources
    within a page, content tasting is not required.

    francois: for included resources tasting is clearly not required.
    It's only be for linked resources that the question of tasting
    content arises

    +1

    <DKA1> PROPOSED RESOLUTION: For CT guidelines, for included
    resources within a page, additional content tasting is not required.

    <Kai> +1

    <francois> +1

    <SeanP> +1

    RESOLUTION: For CT guidelines, for included resources within a page,
    additional content tasting is not required.

    <Kai> ScribeNick: Kai

    jo: should you then taste all linked resources?
    ... this is where get into the end to end session
    ... it would be simpler if we said all linked resources must be
    tasted

    <DKA1> PROPOSED RESOLUTION: For CT guidelines, except in the case of
    https, the content transformation guidelines document does not
    differentiate between URI rewriting and so-called "transparent"
    proxy operation.

    rob: tasting linked resources may end in superflous tasting

    jo: a linked resource is the target of an a element...for sake of
    simplicity
    ... following a hyper link is a linked resource...what would that
    mean?

    SeanP: might mean extra requests

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linkd resource to a new "web site", content must be tasted (allowing
    for different heuristics for determining whether request is to a
    different or the same "web site" but giving "hitting a new domain
    name" as a good example.)

    rob: perhaps you should abide by the same tasting rules if you don't
    know the resource

    jo: what does not know mean?`
    ... tasted before cache expiry level

    DKA: can we focus on resolutions?

    RESOLUTION: For CT guidelines, except in the case of https, the
    content transformation guidelines document does not differentiate
    between URI rewriting and so-called "transparent" proxy operation.

    jo: for the second resolution..any linked resource should be tasted
    with respect to cache expiry

    dka: I don't think so. this brings up all the issues of tasting...am
    I putting two bids on an auction, putting two books in my basket,
    etc.
    ... it's a non starter

    jo: we are exploring what ifs
    ... never taste or always taste linked resources

    francois: dan's point relates to the HTTP method. If there is a form
    it should not trigger a new tasting.
    ... can this be explained with GET?

    dka: I don't think it is possible.

    SeanP: another issue is whether a user wants a desktop experience
    ... then you wouldn't need to taste it

    francois: that is a separate issue

    SeanP: the resolution says that it must be tasted.

    rob: it should be what is says 4.1

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example.)

    jo: if we say that linked resources are a different case then we
    always have content tasting. On the other hand never do that, which
    it won't be and I don't know why it is not always

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example.)

    rob: it is not clear to me either considering 4.1

    francois: if there is a session started, if there is another tasting
    for the same session......

    dka: jo you are saying we don't need the thing about new website,
    because it is dealt with?`

    jo: no, not exactly.

    dka: so what is wrong with the proposed resolution?
    ... (reading the resolution)

    jo: rob is thinking why not always taste, but prior knowledge has
    been taken out....how does that change what you said?

    rob: dan is talking about a resource to a new website, using the
    domain name as a definition....it is probably as good as taking out
    all prior knowledge

    jo: the prior knowledge relates to black and white list discussion
    ... the problem there is if the server alters its behavior it is
    difficult to change lists. It would be better to do this
    dynamically.

    dka: I don't see where we have white and black lists

    jo: we had this last week
    ... if we can do this dynamically, without ref to prior knowledge or
    blacka nd white lists it sets an expectation that server behavior is
    taken account of
    ... question about the sesssion is related to the prior knowledge...
    ... so this is like lists, you could make equal assumptions
    ... linked resources...how often do you need to taste...would also
    ensure you are fresh

    dka: we are not introducing wording that would have a bad effect.

    jo: but we need to take session out
    ... this is why we are teasing this apart

    dka: so hence my resolution

    jo: but it may be more granular
    ... if you have a domain with people having differnet websites
    underneath same domain...for example

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that the proxy should not taste every
    linked resource.

    SeanP: I think I agree with Dans resolutio before..

    rob: we should say do taste if you go to a different website, but
    not define it as such

    jo: let's take both of these resolutions then
    ... section 4.3...we are saying that you have to re-request, if
    headers have been modified
    ... this means if the heuristics are wrong you may be wrong

    francois: there are other ways to control transformation.....

    jo: I understand but lets take these resolutions, after modification
    to remove the word session

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example. And remove the word
    "session" from the previous resolution on 4.1.2.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that the proxy should not taste every
    linked resource.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we agree that the proxy does not have to taste every
    linked resource.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we agree that the proxy does not have to taste every
    linked resource (for the sake of clarity).

    RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that
    the proxy does not have to taste every linked resource (for the sake
    of clarity).

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example. And remove the word
    "session" from the previous resolution on 4.1.2.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example.) And remove the word
    "session" from the previous resolution on 4.1.2.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example. And remove the word
    "session" from the previous resolution on 4.1.2. And close
    ISSUE-241. And subsidize soybeans

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-241, in the CT
    guidelines we should state that when the proxy makes a request for a
    linked resource to a new "web site", then what's in section 4.1.2
    should happen (allowing for different heuristics for determining
    whether request is to a different or the same "web site" but giving
    "hitting a new domain name" as a good example. And remove the word
    "session" from the previous resolution on 4.1.2. And close
    ISSUE-241.

    RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should
    state that when the proxy makes a request for a linked resource to a
    new "web site", then what's in section 4.1.2 should happen (allowing
    for different heuristics for determining whether request is to a
    different or the same "web site" but giving "hitting a new domain
    name" as a good example. And remove the word "session" from the
    previous resolution on 4.1.2. And close ISSUE-241.

Content transformation - ISSUE-255 (Subdomain and Path as a heuristic
in content transformation)

    <dom> ISSUE-255?

    <trackbot> ISSUE-255 -- Subdomain and Path as a heuristic in content
    transformation -- OPEN

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

      [43] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/255

    <SeanP> scribe: SeanP

    <scribe> scribenick: SeanP

    <jo> [jo makes note to self ref Linked Resources and Included
    Resources plus Form Submission]

    <dom> PROPOSED RESOLUTION: re. ISSUE-255, drop mention of
    examination of URI from 4.1.2 as it's a heuristic to scope rejected
    200 responses, detailed in 4.4, and 4.1.2 already precises to
    examine the response (with a link to 4.4)

    <francois> +1

    <jo> ACTION: Jo to enact changes sugegsted by the previous 4
    resolutions [recorded in
    [44]http://www.w3.org/2008/06/16-bpwg-minutes.html#action06]

    <trackbot> Created ACTION-781 - Enact changes sugegsted by the
    previous 4 resolutions [on Jo Rabin - due 2008-06-23].

    RESOLUTION: re. ISSUE-255, drop mention of examination of URI from
    4.1.2 as it's a heuristic to scope rejected 200 responses, detailed
    in 4.4, and 4.1.2 already precises to examine the response (with a
    link to 4.4)

Content Transformation - ISSUE-258 (Requirements section: merging 3.1
and 3.2)

    Francois: Do we still want to do what's in 258?

    Jo: Not sure requirements belong here, but some people like them.

    Francois: Used to find this useful, now that I've been working on it
    a while, think it should be removed.

    DKA: If you are new to the W3C, then you might need it. Could leave
    it in for historical reasons.
    ... Could move requirements into scope section.

    Jo: Requirements are partially wrong.

    Francois: Should move them and refresh them.

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of
    CT Guidelines document into Scope section (and refresh to
    synchronize with the rest of the document).

    Jo: In 3.1, 1a and 1b are fine.
    ... 2a is OK, 2b is not OK, 2c is OK
    ... 3a is OK, 3b is OK
    ... 3b needs to be replaced by "is not permissible"

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of
    CT Guidelines document into Scope section (and refresh to
    synchronize with the rest of the document) moving removed
    requirements into scope for future work.

    Jo: 3c is OK
    ... 3d is OK
    ... 4a is OK, 5a is not OK, 5b is OK
    ... 2d is OK

    <DKA1> PROPOSED RESOLUTION: Regarding ISSUE-258, move section 3.1 of
    CT Guidelines document into Scope section (and refresh to
    synchronize with the rest of the document) moving removed
    requirements into scope for future work (and close ISSUE-258).

    Jo: This could be folded into 3.2 (1, 2, 3, and 4)

    RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines
    document into Scope section (and refresh to synchronize with the
    rest of the document) moving removed requirements into scope for
    future work (and close ISSUE-258).

Content Transformation - ISSUE-260 (Do the guidelines address
Client/Proxy solutions)

    Francois: Difference between regular CT proxy and proxy client
    combination (like Opera Mini). Treat proxy/client combo as black
    box.
    ... Jo noted that black boxes tend to leak.
    ... So guidelines should partially apply. Example of where
    guidelines should apply is to fix problem where all Opera Mini
    requests seem to come from Norway.

    Rob: with google proxy, all requests come from the same place too

    Francois: but in that case, the Google proxy is a regular CT proxy

    <jo> ACTION: Jo to draft text on which aspects of the CT guidelines
    should be followed by e.g. Opera Mini [recorded in
    [45]http://www.w3.org/2008/06/16-bpwg-minutes.html#action07]

    <trackbot> Created ACTION-782 - Draft text on which aspects of the
    CT guidelines should be followed by e.g. Opera Mini [on Jo Rabin -
    due 2008-06-23].

    Francois: We should put something about proxy/client combo following
    guidelines into Appendix.

    <francois> Close ACTION-678

    <trackbot> ACTION-678 Raise and issue on the distinction between a
    CT proxy and (say) Opera Mini closed

    <dom> ScribeNick: dom

Content Transformation - ISSUE-242 (User expression of persistent and
session preferences)

    ISSUE-242?

    <trackbot> ISSUE-242 -- User expression of persistent and session
    preferences -- OPEN

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

      [46] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/242

    Francois: 2 questions here
    ... the distinction between persistent and semi-persistent
    ... we decided to avoid talking about semi-persistent settings
    ... we still have to explain what persistent means
    ... The problem here is about user preferences and administrative
    arrangements
    ... User preferences could just mean that the operator got the user
    to sign an agreement that completely removes control from the user
    ... this opens a big hole in the guidelines
    ... we need to rewrite 3.2 to be explicit (or clear we're not
    explicit)

    DKA: this about the relation between the user and the CT proxy,
    right?

    FD: yes, unrelated to a specific request made by the user
    ... It could be controlled by terms and conditions set by the
    operator

    EdM: how persistent is persistent? until explicitly changed by the
    user?

    Jo: let's put it another way
    ... in the rewritten 4.1.2, the 3 conditions for a proxy to change
    the headers: technically required, according by previous
    interactions with the server, because the user has specifically
    requested a desktop presentation
    ... for this third bit, what does it mean?
    ... * for this server specifically
    ... * or for any request?
    ... I think that's what's at the heart of this
    ... I think it's reasonable that the user should be able to say "for
    this site, always give me the desktop presentation"
    ... (if the proxy offers that feature)

    <jo> PROPOSED RESOLUTION: It is permissible for the proxy to offer
    the user a restructured desktop presentation on a 'site' by 'site'
    basis

    EdM: when you say site, is "m.example.com" and "www.example.com" the
    same site?

    FD: we leave this to CT vendors to define

    Jo: one of the questions is whether we can say something is
    permissible if it isn't under law?

    DKA: think we're covered by the document license

    RESOLUTION: It is permissible for the proxy to offer the user a
    restructured desktop presentation on a 'site' by 'site' basis

    Jo: in 3.1 of the guidelines, we say that the best place to
    implement user choice of presentation is at the origin server
    ... which comes first? presentation switch on the origin server or
    in the CT proxy?
    ... so it's probably worth noting that it would be useful to develop
    that point in BP2

    ISSUE: Discuss the option to offer choices of presentation as a best
    practices for mobile web apps

    <trackbot> Created ISSUE-262 - Discuss the option to offer choices
    of presentation as a best practices for mobile web apps ; please
    complete additional details at
    [47]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/262/edit .

      [47] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/262/edit

    Jo: we want to encourage the creation of mobile-friendly content on
    the origin server, so we probably don't want to promote a practice
    that would go against that policy

    SeanP: so you're saying that a CT proxy should have a persistent
    preference to always get the desktop version?

    Jo: the complication is that if the user wants a mobile version, and
    the CT still sends the desktop headers, the user doesn't get what
    she wants
    ... it raises the question of blanket user preferences

    SeanP: but that's what most CT do

    Jo: but is this the expression of a specific user's choice?

    SeanP: I think in reality is that the operator is making the choice

    Jo: but is it appropriate? esp. with the mission of the BP in mind
    ... a concern is that if all vendors default to
    desktop-presentation, this would still be conformant with the
    guidelines without helping what we want to achieve
    ... so my conclusion that a blanket agreement doesn't constitute a
    proper expression of user's choice

    Francois: my concern is, if the user really wants the default
    desktop-experience, we would forbid him to have this expressed or
    recorded?

    Jo: it comes back to a matter of principle
    ... the CP choice must prevail, unless the user specifically
    expresses it

    <DKA1> PROPOSED RESOLUTION: If both a mobile and a desktop
    experience are provided by the origin server, the default should be
    to provide the user with the mobile experience unless the proxy
    determines that providing the mobile experience will result in a
    non-functional user experience.

    SeanP: the way of the CT work now is that they send the desktop
    headers

    <Zakim> francois, you wanted to talk about power users

    francois: it's probably true that this would affect very few users
    (referring to dom's not minuted comment)
    ... it's no big deal if only a few users can't express their
    preferences if most benefit from it

    Jo: I'm not sure we should make assumptions about the existing
    balance - given how rapidly these consideration change

    <Zakim> Kai, you wanted to point out that we need to consider
    editorial issues when it comes to thinking about content providers
    views

    Kai: editorially speaking, it's sometimes impossible to have a
    single version adapted to mobile - and creating many versions is
    expensive

    <jo> PROPOSED RESOLUTION: Blanket expression of user preference for
    restructured desktop presentation is not consistent with encouraging
    content providers to build specific mobile user experiences and
    providing a choice of experience at the origin server

    Kai: automation is cheap - so leaving the burden on transformation
    proxy makes economical sense

    Dom: but there is a different between content transformation proxies
    and content adaptation engine used by the CP

    Jo: we should note that distinction in the doc

    <jo> PROPOSED RESOLUTION: Insert into the document a scoping
    statement that says that a CT proxy is a CT proxy only if it is not
    under the control of a content provider. One that is in control of
    the contrnet provider is an adaptation solution and is out of scope

    <jo> PROPOSED RESOLUTION: Insert into the document a scoping
    statement that says that a CT proxy is a CT proxy only if it is not
    under the control of a content provider. One that is in control of
    the contrnet provider is an adaptation solution and is considered to
    be part of the origin server and is therefore out of scope

    <jo> PROPOSED RESOLUTION: Insert into the document a scoping
    statement that says that a CT proxy is a CT proxy only if it is not
    under the control of a content provider. One that is in control of
    the content provider is an adaptation solution and is considered to
    be part of the origin server and is therefore out of scope

    DKA: Vodafone does both - isn't that a bit wishy-washy?

    <jo> PROPOSED RESOLUTION: Insert into the document a scoping
    statement that says that a proxy is a CT proxy only where no prior
    arrangement exists between the operator of the proxy and a content
    provider. One where an arrangement exists with the content provider
    is an adaptation solution, is considered to be part of the origin
    server and is therefore out of scope

    <DKA1> +1ish

    <rob> +1

    <SeanP> +1

    <jo> PROPOSED RESOLUTION: Insert into the document a scoping
    statement that says that a proxy is a CT proxy in scope of this
    document only where no prior arrangement exists between the operator
    of the proxy and a content provider. One where an arrangement exists
    with the content provider is an adaptation solution, is considered
    to be part of the origin server and is therefore out of scope

    RESOLUTION: Insert into the document a scoping statement that says
    that a proxy is a CT proxy in scope of this document only where no
    prior arrangement exists between the operator of the proxy and a
    content provider. One where an arrangement exists with the content
    provider is an adaptation solution, is considered to be part of the
    origin server and is therefore out of scope

    PROPOSED RESOLUTION: Blanket expression of user preference for
    restructured desktop presentation is not consistent with encouraging
    content providers to build specific mobile user experiences and
    providing a choice of experience at the origin server

    <jo> PROPOSED RESOLUTION: Blanket expression of user preference for
    restructured desktop presentation is not consistent with encouraging
    content providers to build specific mobile user experiences and
    providing a choice of experience at the origin server

    +1

    <jo> +1

    <SeanP> 0

    <DKA1> +1

    <adam> +1

    PROPOSED RESOLUTION: Blanket expression of user preference for
    restructured desktop presentation is not consistent with encouraging
    content providers to build specific mobile user experiences and
    providing a choice of experience at the origin server

    Jo: a possible simple fix would to insert simply a note in the
    document that states this

    francois: and remove the part that allows to always request the
    desktop version

    jo: right

    <jo> (and remove section 3.2.3)

    jo: otherwise, we can require this to be made on a case by case
    basis
    ... a further choice would be to say that when a CP provides the
    choice, this should override the blanket agreement

    Kai: why this would override the choice of the user?

    Jo: the choice the user has expressed is with the CT, not with the
    CP

    SeanP: I would disagree with such a proposal - we have plenty of
    requests for this

    Jo: but the user doesn't really care whether the desktop version
    comes from the CT or the CP

    DKA: we need to consider the point of encouraging content providers
    to create mobile friendly content
    ... these rules need to be consistent with that overall set of goals
    ... also, this task force was kicked off in reaction to the call
    from content providers to have more control and visibility in the
    proxy layer
    ... so I think we should be erring on the side of what Jo proposed

    <Zakim> rob, you wanted to say that site-by-site opt-in to
    restructuring desktop editions could also prevent thos sites from
    subsequently getting a mobile-friendly edition to the user

    Jo: we need to reconcile the need from the users (e.g. always
    wanting the desktop version), from the needs of CP to control what
    is served

    Rob: site-by-site opt-in to restructuring desktop editions could
    also prevent those sites from subsequently getting a mobile-friendly
    edition to the user
    ... I think default is less an issue than the fact that you can
    change your mind

    DKA: but most users just don't know anything about this
    ... so we're talking about making decisions for users
    ... with a blanket preference, as a new user, I wouldn't ever know
    that there may be a mobile version of a given site

    SeanP: there would probably be a link, though

    DKA: (which is what Jo raised as an issue for BP2)

    SeanP: if you disallow blanket preferences for Desktop-version, you
    run the risk of people not following the guidelines

    Dom: what about requiring a CT proxy that relies on a user
    preference to always get the desktop version to have a link to get
    the mobile version served by the site?

    Kai: what about the other way around?

    DKA: or more generally speaking, when a CT proxy does
    transformation, requiring that it puts a link to the "other mode" of
    the site?
    ... In vodafone, lots of the discussions about the default depends
    on the device the user has

    <jo> PROPOSED RESOLUTION: Put a pin in this discussion noting that
    the questions that remain to be resolved are:

    <jo> a. how the CT proxy should react against specific user
    preferences when a site becomes more capable

    <jo> b. that the default experience should be for the mobile
    experience

    <jo> c. that blanket expression of preferences should be interpreted
    in the context that if an origin server can provide a choice of
    experience then it should do so

    <jo> d. that CT proxies should, in restructured content, proivide
    links to alternative representations

    Jo: I agree with Rob's point that the user should be alerted when a
    site changes and becomes mobile-friendly if she had expressed a
    preference for that site before

    <jo> e. how would a CP indicate to a CT Proxy that it offers user
    choice of representation?

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for desktop presentation and multiple representations are
    found to exist then the CT proxy server SHOULD prompt the user to
    inform them of this and ask the user which representation they want
    to view.

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for desktop presentation and multiple representations are
    found to exist then the CT proxy server SHOULD inform the user of
    this fact and provide the user with an option to change the
    representation.

    <jo> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for desktop presentation and multiple representations are
    found to exist then the CT proxy server SHOULD make the user aware
    of it and provide the user with the option to change the
    represntataion

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for any specific presentation option and multiple
    representations are found to exist then the CT proxy server SHOULD
    inform the user of this fact and provide the user with an option to
    change the representation.

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for any specific representation option and multiple
    representations are found to exist then the CT proxy server SHOULD
    inform the user of this fact and provide the user with an option to
    change the representation.

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for any specific representation option and multiple
    representations are found to exist then the CT proxy server SHOULD
    inform the user of this fact and provide the user with an option to
    change to one of the alternative representations.

    Adam: this seems to be making the document much more complex
    ... I wonder if we shouldn't stay silent on this

    <DKA1> PROPOSED RESOLUTION: We remain silent on the issue of what
    explicit prior user consent consists of.

    Jo: the key question is the level of user expression consent

    Dom: agree; once the user has sufficiently agreed to it, the ct
    proxy becomes part of the user-agent
    ... (e.g. a user could use a user-defined proxy to do the
    transformations he deems necessary)

    [discussions on no-transform]

    SeanP: one problem with no-transform is that ct proxies still want
    to add headers/footers or rewrite links
    ... even if the content is set to no-transform

    Dom: I think that whether this is going to be implemented or not is
    a different discussion on whether it should be or not
    ... maybe not all vendors will apply this, but that doesn't change
    the fact that we might think this is a good thing

    DKA: as an operator, we may actually want to have these changes as a
    longer term goal

    <DKA1> PROPOSED RESOLUTION: if there is a blanket user preference
    asserted for any specific representation option and multiple
    representations are found to exist then the CT proxy server SHOULD
    inform the user of this fact and provide the user with an option to
    change to one of the alternative representations.

    RESOLUTION: if there is a blanket user preference asserted for any
    specific representation option and multiple representations are
    found to exist then the CT proxy server SHOULD inform the user of
    this fact and provide the user with an option to change to one of
    the alternative representations.

    DKA: I think we need to strengthen the clauses around "no-transform"

    Rob: when rewriting urls, if one of the links link to a no-transform
    site, what do you do?

    dom: you could redirect there instead of rewriting?

    <jo> PROPOSED RESOLUTION: For no-transform responses and for https
    change text referring to "express user choice" to mean "case by case
    choice"

    <DKA1> PROPOSED RESOLUTION: In the context of tasting content, if
    header comes back as cache-control no-transform, then CT proxies
    SHOULD change to transparent proxy operation.

    <DKA1> PROPOSED RESOLUTION: I

    <DKA1> PROPOSED RESOLUTION: remain silent on all other issues

    <francois> ScribeNick: dom

    <francois> ScribeNick: francois

    DKA: can we exclude visible header/footers from our discussion?

    SeanP: Well, the other issue is URI rewriting

    DKA: I don't think that's a problem.

    <DKA1> PROPOSED RESOLUTION: no means no

    DKA: If a site is precisely tailored for a specific device, then it
    takes into account width and screen of the device, and adding link
    would mess with the representation

    Kai: support that Cache-Control: no-transform needs to be a strong
    statement

    Rob: OK, but I still point that URI rewriting is a problem

    francois: redirect doesn't solve the problem?

    rob: probably, but not in all cases. There could be cases where
    various proxies in the path would proxy the HTTP 302 redirect back
    to the CT-proxy again. But this is only a technical problem to
    overcome, not a reason to not specify best-practise.

    <DKA1> PROPOSED RESOLUTION: In the context of tasting content, if
    header comes back as cache-control no-transform, then CT proxies
    SHOULD change to transparent proxy operation (e.g. sending a http
    redirect).

    Jo: I don't think we need to write this, because we already say that
    the proxy SHOULD be transparent "unless".

    <jo> +1

    Jo: I don't particularly object to your resolution though.
    ... Agree we need to be clear.

    RESOLUTION: In the context of tasting content, if header comes back
    as cache-control no-transform, then CT proxies SHOULD change to
    transparent proxy operation (e.g. sending a http redirect)

    <jo> PROPOSED RESOLUTION: For no-transform responses and for https
    change text referring to "express user choice" to mean "case by case
    choice"

    DKA: next proposed resolution to resolve the issue within the next
    half hour?
    ... does that not imply that the user will be repeatedly prompted
    with security warnings?

    jo: the point is that blanket expression of user preferences should
    not be used here.

    rob: insertion of a warning header by the CT-proxy in the page is
    enough?

    francois: no, the CT-proxy must not start transformation of HTTPS
    content without the agreement of the user
    ... same thing with HTTPS links within HTTP pages

    SeanP: Can the proxy keep the user's choice for the web site?

    DKA: yes, it would be the middle ground between blanket and case by
    case. The user could be given different choices: only for this page,
    for the site, ...
    ... but that may be going too far in prescribing how the CT-proxy
    may behave

    Dom: I don't think we need to be explicit about that

    francois: I note that what is in the guidelines for HTTPS rewriting
    is already the result of such a discussion on how to rephrase it so
    that we stay on this middle ground

    DKA: OK, can we translate the HTTPS part to the Cache-Control:
    no-transform directive?

    <jo> PROPOSED RESOLUTION: If the response includes a Cache-Control:
    no-transform directive then the response must remain unaltered other
    than to comply with transparent HTTP behavior and other than as
    noted below. If the proxy determines that the resource as currently
    represented is likely to cause serious mis-operation of the user
    agent then it may advise the user that this is the case and must...

    <jo> ...provide the option for the user to continue with unaltered
    content.

    <jo> PROPOSED RESOLUTION: If the response includes a Cache-Control:
    no-transform directive then the response must remain unaltered other
    than to comply with transparent HTTP behavior and other than as
    follows. If the proxy determines that the resource as currently
    represented is likely to cause serious mis-operation of the user
    agent then it may advise the user that this is the case and must...

    <jo> ...provide the option for the user to continue with unaltered
    content.

    DKA: Should we lower the statement: "If the proxy knows better"
    ... ?

    francois: I don't think so. The response that is being altered may
    not be designed to be displayed directly to the user. It could be
    the result of an AJAX call for instance. I still support a strong
    Cache-Control: no-transform directive.
    ... Adding an interstitial response would break existing content

    <DKA1> +1

    DKA: I suggest that we move forward on this resolution, and that we
    use the Last Call period to get feedback from CT vendors and Content
    Providers. I suggest we use the Last Call to poll feedback.

    <jo> a. how the CT proxy should react against specific user
    preferences when a site becomes more capable

    <jo> b. that the default experience should be for the mobile
    experience

    <jo> c. that blanket expression of preferences should be interpreted
    in the context that if an origin server can provide a choice of
    experience then it should do so

    <jo> d. that CT proxies should, in restructured content, proivide
    links to alternative representations

    <jo> e. how would a CP indicate to a CT Proxy that it offers user
    choice of representation?

    <jo> f. allow users to change previosuly expressed preferences

    francois: agree with the resolution, although I don't see the
    difference with what we already have in there.

    RESOLUTION: If the response includes a Cache-Control: no-transform
    directive then the response must remain unaltered other than to
    comply with transparent HTTP behavior and other than as follows. If
    the proxy determines that the resource as currently represented is
    likely to cause serious mis-operation of the user agent then it may
    advise the user that this is the case and must .provide the option
    for the user to continue with unaltered content.

    DKA: Another resolution we can take in the remaining 10mn?

    Jo: [going through the above list]
    ... On point e: we already resolved on the use of the Link element
    with some reference somewhere in the document. Now we need the
    following:

    <jo> PROPOSED RESOLUTION: If the server has alternative
    representations then it should indicate this using link
    header/elements

    <DKA1> +1

    <rob> +1

    Kai: What about POWDER?

    RESOLUTION: If the server has alternative representations then it
    should indicate this using link header/elements

    Jo: Then, how does a Content Provider advertise the fact that it
    proposes a choice to the end user between a desktop and a mobile
    representation?

    dom: I think we should leave that as heuristics

    jo: Overall, my feeling is that we're not going to make more
    progress on this subject today...

    Kai: would appreciate if resolutions were not taken that quickly,
    especially when I have questions on the matter.

    francois: summary of where we are re. CT?
    ... I think we need to think carefully about it. It involves
    complete rewriting of 3.2 in my view.

    jo: I'd say the whole section should disappear.
    ... Well have to wait for the new draft and see where the direction
    goes.

A quick look on the agenda

    DKA: On the agenda, I don't want to move the points we missed this
    afternoon to tomorrow morning
    ... I suggest that in order of priority that we move these
    discussions into early afternoon on Wednesday.

    Jo: I think that's fine.

    DKA: Session adjourned

Summary of Action Items

    [NEW] ACTION: francois to start the rechartering process [recorded
    in [48]http://www.w3.org/2008/06/16-bpwg-minutes.html#action01]
    [NEW] ACTION: Jo to add text to section 4.4 referencing above
    resolution on mobikeOK [recorded in
    [49]http://www.w3.org/2008/06/16-bpwg-minutes.html#action05]
    [NEW] ACTION: Jo to add the stuff on possible use of OPTIONS to the
    appendix [recorded in
    [50]http://www.w3.org/2008/06/16-bpwg-minutes.html#action03]
    [NEW] ACTION: Jo to draft text on which aspects of the CT guidelines
    should be followed by e.g. Opera Mini [recorded in
    [51]http://www.w3.org/2008/06/16-bpwg-minutes.html#action07]
    [NEW] ACTION: Jo to edit 4.1.2 according to above resolution
    [recorded in
    [52]http://www.w3.org/2008/06/16-bpwg-minutes.html#action02]
    [NEW] ACTION: Jo to enact changes sugegsted by the previous 4
    resolutions [recorded in
    [53]http://www.w3.org/2008/06/16-bpwg-minutes.html#action06]
    [NEW] ACTION: Jo to transcribe points 7 8 9 and 11 of ISSUE-223 into
    Scope for future work [recorded in
    [54]http://www.w3.org/2008/06/16-bpwg-minutes.html#action04]

    [End of minutes]
Received on Tuesday, 17 June 2008 15:24:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 June 2008 15:24:46 GMT