See also: IRC log
francois: We published the first public working draft as agreed
<francois> FPWD of 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
<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> 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> 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> 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> 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> Open actions
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
<francois> Last message on alteration of request bodies
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> 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> 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
<francois> SeanP's comments
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 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].
francois: This was raised by Sean in an email. In 4.1.2 we say that the proxy should not modify unless...
<francois> Control by the User
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.