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

[minutes] CT call Tuesday 15 April 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 15 Apr 2008 17:18:37 +0200
Message-ID: <4804C74D.8080504@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

The minutes of today's call are available at:
http://www.w3.org/2008/04/15-bpwg-minutes.html

... and copied as text below.


Resolutions taken during the call:
- to replace the editorial note in 4.1.2 re alteration of request 
bodies, write something along the lines of "the CT-proxy MUST ensure 
that the origin server receives the form it expects"
- list "Always request the desktop presentation of the resource" as one 
of the examples in 3.2.1
- add a bullet to the first list of bullets in 4.1.2 "any knowledge it 
has of user's preferences"
- remove first bullet that says: "any administrative arrangements that 
are in place with the user, or the server" (in 4.1.2 as well)

New action on me:
- raise discussion propose alternatives re linearization/zoom 
capabilities and the relation with CT-proxy


Francois.


----
15 Apr 2008

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2008/04/15-bpwg-irc

Attendees

    Present
           francois, Magnus, SeanP, andrews, MartinJ

    Regrets
           rob, bryan, hgerlach, jo, kemp

    Chair
           francois

    Scribe
           MartinJ

Contents

      * [4]Topics
          1. [5]Doc Status
          2. [6]Close some actions without much discussion
          3. [7]Alteration of request bodies (§4.1.2)
          4. [8]Linearization or zoom capability (§4.1.2)
          5. [9]Users preferences
      * [10]Summary of Action Items
      _________________________________________________________

Doc Status

    francois: We published the first public working draft as agreed

    <francois> [11]FPWD of CT guidelines

      [11] http://w3.org/TR/ct-guidelines

    francois: thanks everyone for participating. I hope we will get some
    feedback.
    ... our job is not done yet as there are many areas still to cover
    in the draft
    ... next steps are..
    ... address editorial notes, make structure more clear
    ... keep clear concise guidelines. POWDER..
    ... is there anything else that we should address, or any logistical
    remarks?
    ... looking for suggestions on how we could improve our way of
    working to move faster than we have done

    <SeanP> I'm happy with how the meetings are run.

    <andrews> +q

    andrew: Many thanks to Francois and to Jo for driving this forward.
    ... question I had was how to the public respond to the draft?

    francois: It is listed in the opening section of the document- to
    use the mailing list
    ... we may not get any comments but we really hope we do

Close some actions without much discussion

    <francois> ACTION-625?

    <trackbot-ng> ACTION-625 -- François Daoust to initiate discuss on
    the exception wording ref dangerous content -- due 2008-01-29 --
    OPEN

    <trackbot-ng>
    [12]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/625

      [12] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/625

    francois: A bunch of actions were created and already resolved

    <francois> Close ACTION-625

    <trackbot-ng> ACTION-625 Initiate discuss on the exception wording
    ref dangerous content closed

    <francois> ACTION-685

    <francois> ACTION-685?

    <trackbot-ng> ACTION-685 -- François Daoust to investigate embedded
    original headers in altered requests (message/http), external ref to
    original headers (application/external-body) and/or use of WARNING
    headers for 3.1.4 -- due 2008-03-10 -- OPEN

    <trackbot-ng>
    [13]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/685

      [13] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/685

    <francois> Close ACTION-685

    <trackbot-ng> ACTION-685 Investigate embedded original headers in
    altered requests (message/http), external ref to original headers
    (application/external-body) and/or use of WARNING headers for 3.1.4
    closed

    <francois> ACTION-686?

    <trackbot-ng> ACTION-686 -- François Daoust to will organise the
    next CTTF Editors' meeting -- due 2008-03-10 -- OPEN

    <trackbot-ng>
    [14]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/686

      [14] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/686

    <francois> Close ACTION-686

    <trackbot-ng> ACTION-686 Will organise the next CTTF Editors'
    meeting closed

    <francois> ACTION-731

    <francois> ACTION-731?

    <trackbot-ng> ACTION-731 -- Jo Rabin to enact changes resolved in
    this meeting -- due 2008-04-15 -- OPEN

    <trackbot-ng>
    [15]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/731

      [15] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/731

    <francois> Close ACTION-731

    <trackbot-ng> ACTION-731 Enact changes resolved in this meeting
    closed

    <francois> [16]Open actions

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

    francois: as a reminder, please check your actions
    ... can see them from the link just pasted
    ... if they are not needed any more then please say so

Alteration of request bodies (§4.1.2)

    <francois> [17]Last message on alteration of request bodies

      [17] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0015.html

    francois: there seems to be some consensus
    ... we should not go into too many details in the document regarding
    the cases when the CT proxy actually has to change the request body
    but all the changes are to make sure the from the CP point of view
    the request it as it expects it to be
    ... so from the CP point of view the proxy is transparent
    ... document seems a bit clumsy in ites dealing with the HTTP
    request. It gives the feeling that there is always one request, when
    it might actually be multiple requests between the user agent and
    the proxy
    ... not sure how to phrase that in a simple enough way
    ... maybe "The CT proxy must make sure that from the CP point of
    view the request remains unchanged" but this is not clear at all

    SeanP: we are not really talking about something being changed
    because it hasn't been sent yet. It's the content provider getting
    what it expects.

    francois: Yes exactly.

    SeanP: So "unchanged" is probably not the right word to use.

    francois: So should we just replace it all with "The CP must always
    receive what it expects".

    SeanP: but without that happening it won't work at all

    Francois: So I now think we should just drop this part and not say
    anything about request bodies since it is obvious what must happen

    <francois> PROPOSED RESOLUTION: drop the editorial note in 4.1.2 re
    alteration of request bodies on the basis that it's trivial that the
    CT-proxy makes sure the Content Provide receives what it expects

    <jo> I think we should mention request bodies otherwise it will seem
    as though something is missing

    +1 to Jo

    <jo> we should mention that certain fix-ups are required but are out
    of scope

    <jo> give examples

    francois: OK - it doesn't do any harm to state the obvious

    <francois> I'm not sure examples are needed here, but we could go
    with the "obvious yet true" statement about the Content Provider
    that must receive the form it expects

    <SeanP> OK with me

    <jo> I think that the wording will need to be carefully constructed

    and me

    MartinJ: I think examples might imply that we needed them everywhere
    else too

    <francois> PROPOSED RESOLUTION: to replace the editorial note in
    4.1.2 re alteration of request bodies, write something along the
    lines of "the CT-proxy MUST ensure that the origin server receives
    the form it expects"

    <jo> examples are needed elsewhere, I agree

    <SeanP> On the examples, it might not hurt to put one inline or
    something just so the reader knows where we are coming from.

    francois: reading the document the good thing is that is not too
    long and the statements are simple and clear.
    ... adding examples in the doc may not be the best thing to do but
    we could have them in another section, addressed later on

    <SeanP> +1 to resolution

    francois: let's not spend too much time on this. We all agree on the
    direction anyway..
    ... we have a line from the proposed resolution and we may or may
    not want to extend it to have examples

    +1 to resolution

    francois: If no objection lets take that

    RESOLUTION: to replace the editorial note in 4.1.2 re alteration of
    request bodies, write something along the lines of "the CT-proxy
    MUST ensure that the origin server receives the form it expects"

    francois: anyone want to take an action for that or we can leave it
    in Jo's hands

    <francois> ACTION-681?

    <trackbot-ng> ACTION-681 -- François Daoust to ask aaron kemp for
    clarification of the character encoding issue -- due 2008-03-10 --
    OPEN

    <trackbot-ng>
    [18]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/681

      [18] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/681

    <francois> Close ACTION-681

    <trackbot-ng> ACTION-681 Ask aaron kemp for clarification of the
    character encoding issue closed

    <SeanP> I can do it

    <francois> ScribeNick: Magnus

    <francois> ACTION-680?

    <trackbot-ng> ACTION-680 -- Robert Finean to provide a pseudo-code
    example of form transformation for CT document. -- due 2008-03-10 --
    OPEN

    <trackbot-ng>
    [19]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/680

      [19] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/680

    francois: the 2nd option is on Rob
    ... might be worth leaving it open if we want to add some examples
    ... for example form splitting
    ... let's move on

Linearization or zoom capability (§4.1.2)

    <francois> [20]SeanP's comments

      [20] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0020.html

    francois: this is an issue raised by Sean
    ... in 4.1.2 right after the editorial note
    ... knowing about Linearization or zoom capability
    ... two things to consider
    ... what are out intentions
    ... we are talking about response ,whereas this section is abour the
    request
    ... if we keep it we should split it into 2
    ... one saying the proxy should not change the headers
    ... and one for the headers

    <francois> ScribeNick: MartinJ

    <jo> this section is saying that the headers should not be changed
    if the device is/has a quart in pint pot browser

    SeanP: reading it again, we are saying that if the client has some
    transformation capabilities then it should be allowed to do that.
    ... you are right that it it seems to be in the wrong place

    francois: we should split in two: part in 4.4

    SeanP: where's the line about were you allow transformation and
    where you don't - it seems kind of vague
    ... it's not a binary thing - I'm sure there's a range of abilities
    that clients have.
    ... there may be content types that are not supported for example

    francois: so do you propose to just remove that part?

    SeanP: Not sure we want to remove it but we should either expand on
    it or whatever.

    francois: Anyone else?
    ... I will take an action to clarify what we intend to say here

    <francois> ACTION: daoust to raise discussion on the mailing-list
    and propose alternatives re linearization/zoom capabilities and the
    relation with CT-proxy [recorded in
    [21]http://www.w3.org/2008/04/15-bpwg-minutes.html#action01]

    <trackbot-ng> Created ACTION-735 - Raise discussion on the
    mailing-list and propose alternatives re linearization/zoom
    capabilities and the relation with CT-proxy [on François Daoust -
    due 2008-04-22].

Users preferences

    francois: This was raised by Sean in an email. In 4.1.2 we say that
    the proxy should not modify unless...

    <francois> [22]Control by the User

      [22] http://www.w3.org/TR/ct-guidelines/#sec-user-control

    francois: [one of the condtions] the user requested a restructured
    version...

    <francois> PROPOSED RESOLUTION: list "Always request the desktop
    presentation of the resource" as one of the examples in 3.2.1

    francois: In 4.1.2 I would have the first point unchanged, but the
    second point mentioning the user's preference

    <SeanP> +1

    +1

    <andrews> +1

    RESOLUTION: list "Always request the desktop presentation of the
    resource" as one of the examples in 3.2.1

    <francois> PROPOSED RESOLUTION: add a bullet to the first list of
    bullets in 4.1.2 "any knowledge it has of user's preferences"

    SeanP: Aren't we proposing that administrative agreements are a
    proxy for or form of the user's preferences?

    francois: I think we agreed that admin arrangements are out of scope
    of the document
    ... it makes sense to refer to preferences and not mention admin
    arrangements. It's implied that they may override preferences
    ... 3.2.3 covers administrative arrangements such as terms and
    conditions that the user agrees to

    SeanP: OK

    francois: If we agree they are out of scope we should just talk
    about them in 3.2.3

    SeanP: That's fine with me

    <francois> PROPOSED RESOLUTION: add a bullet to the first list of
    bullets in 4.1.2 "any knowledge it has of user's preferences"

    +1 to the proposed resolution

    <SeanP> +1

    RESOLUTION: add a bullet to the first list of bullets in 4.1.2 "any
    knowledge it has of user's preferences"

    francois: same topic: as a side effect of our discussion I suggest
    we remove the first bullet in 4.1.2
    ... implied by 3.2.3 there are the administrative arrangements

    <andrews> +1

    <francois> PROPOSED RESOLUTION: remove first bullet that says: "any
    administrative arrangements that are in place with the user, or the
    server"

    +1

    <SeanP> +1

    RESOLUTION: remove first bullet that says: "any administrative
    arrangements that are in place with the user, or the server"

    francois: some more discussion and actions are needed to address the
    remaining editorial notes so feel free to commence this on the
    mailing list. You might take it on yourselves to progress these.

Summary of Action Items

    [NEW] ACTION: daoust to raise discussion on the mailing-list and
    propose alternatives re linearization/zoom capabilities and the
    relation with CT-proxy [recorded in
    [23]http://www.w3.org/2008/04/15-bpwg-minutes.html#action01]

    [End of minutes]
Received on Tuesday, 15 April 2008 15:19:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 April 2008 15:19:12 GMT