See also: IRC log
francois: Jo's right, we can't go
to last call with no Appendix B
... 1st option is an "intermediate working draft" to give us 2
weeks to finish it
<Zakim> jo, you wanted to wonder if folks can contribute to this within 1 week?
francois: 2nd option is just finish it then go last call in 2 weeks
jo: dependshow quick we can get
the examples together
... or we could publish with one example and then expect
comments back like "you need more examples!"
... whilst secretly working on those
... Would help if CTTF members each provide one example
<jo> [would much prefer if we did what we meant and actually publish a final last call draft with all the examples we mean to include]
francois: good idea to share load
SeanP: yes, happy to do an example
AndrewS: can I have B4?
SeanP: ok, i'll take B2
<francois> ACTION: andrew to write some text for CT Appendix B.4 [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action01]
<trackbot> Created ACTION-815 - Write some text for CT Appendix B.4 [on Andrew Swainston - due 2008-07-29].
<francois> ACTION: Sean to write some text for CT Appendix B.2 [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action02]
<trackbot> Created ACTION-816 - Write some text for CT Appendix B.2 [on Sean Patterson - due 2008-07-29].
<francois> ACTION: rob to write some text for CT Appendix B.5 [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action03]
<trackbot> Sorry, couldn't find user - rob
<francois> ACTION: robert to write some text for CT Appendix B.5 [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action04]
<trackbot> Created ACTION-817 - Write some text for CT Appendix B.5 [on Robert Finean - due 2008-07-29].
<francois> ACTION: daoust to write some text for CT Appendix B.3 [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action05]
<trackbot> Created ACTION-818 - Write some text for CT Appendix B.3 [on François Daoust - due 2008-07-29].
francois: so please examples before Friday
jo: Thursday evening is best, then I can get another draft out on Friday
francois: trying to rationalise the issue; from a technical viewpoint there is no inconsistency but might it confuse users?
<francois> ISSUE-270
jo: suggest we drop this
... there's not much we can say, so let's not try
<jo> PROPOSED RESOLUTION: ref ISSUE-270 3.1.5.3 and 3.2.3 drop these editorial notes
+1
<francois> +1
<SeanP> +1
RESOLUTION: ref ISSUE-270 3.1.5.3 and 3.2.3 drop these editorial notes
<francois> Close ISSUE-270
<francois> ACTION-813?
<trackbot> ACTION-813 -- Heiko Gerlach to draft some clearer wording of 3.3.6.2 on HTTPS link re-writing -- due 2008-07-22 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/813
francois: Bryan had a lot of comments on this
<francois> discussion
francois: but we need to avoid prescribing workings, we just need to prescribe outcomes that are possible
<francois> PROPOSED RESOLUTION: amend text in 3.3.6.2 with some clarification that "to avoid decryption and transformation of the resources the links refer to" means that the CT-proxy must be bypassed in practice.
<Zakim> jo, you wanted to disagree with the propsoed resolution and to suggest adding a note to stress that transformation is not possible without breaking end to end security
<andrews> I agree with Jo
jo: wants to avoid any doubt that "when content is transformed end-to-end security is broken"
<SeanP> Agree, leave text as is
<francois> PROPOSED RESOLUTION: add a note in 3.3.6.2 that states that transformation is not possible without breaking end to end security
<andrews> +1
<francois> +1
RESOLUTION: add a note in 3.3.6.2 that states that transformation is not possible without breaking end to end security
<jo> ACTION: jo to add a note per resolution on CT 3.3.6.3 on end to end security [recorded in http://www.w3.org/2008/07/22-bpwg-minutes.html#action06]
<trackbot> Created ACTION-819 - Add a note per resolution on CT 3.3.6.3 on end to end security [on Jo Rabin - due 2008-07-29].
<francois> Close ACTION-813
<trackbot> ACTION-813 Draft some clearer wording of 3.3.6.2 on HTTPS link re-writing closed
francois: I'm fine with the decision from several months ago
<francois> PROPOSED RESOLUTION: Stick to our decision not to mention examples of Content-Types in 3.3.6
jo: SeanP suggested Content-Type improvements that are in the forthcoming draft
<francois> Close ACTION-812
<trackbot> ACTION-812 Dig in the archives to check reason not to mention content types in the list of heuristics closed
RESOLUTION: Stick to our decision not to mention examples of Content-Types in 3.3.6
<francois> PROPOSED RESOLUTION: not to confuse readers, move the note on meta http-equiv from 3.2.2 to an appendix on legacy servers
<jo> PROPOSED RESOLUTION: Drop note on meta http-equiv no-transform and move to appendix
<francois> +1
<andrews> +1
<SeanP> +1
RESOLUTION: Drop note on meta http-equiv no-transform and move to appendix
<francois> ACTION-811?
<trackbot> ACTION-811 -- François Daoust to send a summary of the pagination note (3.1.4) to the mailing-list -- due 2008-07-22 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/811
francois: don't think there's need for mention of this
<jo> PROPOSED RESOLUTION: Add a note stating that when a transforming proxy is serving stale content as a result of pagination (or for other reasons) it SHOULD note that the data is stale
francois: we can either drop the section or add requirements that CT-proxy must cache it
<Zakim> rob, you wanted to say real users don't understand this stuff
francois: but if i'm scrolling around a page on a browser I don't get informed when it turns stale
<jo> _refresh_ for an up to date
rob: i think we have to point out that the right thing to do is serve cached (and therefore likely stale)
jo: still think we should point out they need to refresh to get the latest copy
SeanP: maybe only do this if you reload the same section of the page?
rob: likely to get this message a lot if cookies imply content is automatically stale
jo: didn't mean that, only meant
if Expires was set explicitly
... this is a deviation from accepted HTTP
francois: if we're deviating from HTTP we should note that's the case
<Zakim> rob, you wanted to say it's standard HTTP if the CT-proxy is a "virtual browser"
SeanP: tending to agree with Jo if I come back an hour later and go to sub-page 2 we should note it's old
<jo> PROPOSED RESOLUTION: Introduce some text stating that for the purposes of consistent pagination proxies MAY serve stale data but when doing do SHOULD notify the user that this is the case and SHOULD provide a simple means of retrieving a fresh copy
<Zakim> jo, you wanted to say that we defined it as not being a "virtual browser"
rob: it's standard HTTP if the CT-proxy and handset are grouped together as a single "virtual browser" entity
jo: we haven't defined it like that though
andrews: user-experience is that
typically you find out content has expired when they hit back
buttons, so maybe they will be used to such warnings
... I think of CT-proxy as an extension of the origin server,
not of the browser
SeanP: if page does expire quickly they will get that message a lot
jo: we're not prescribing a message, just noting they may be provided with a message and means to refresh
<jo> +1
<francois> 0
-1
<andrews> 0 (???)
<SeanP> 0, still thinking about it
<Zakim> rob, you wanted to say MAY not SHOULD
rob: prefer MAY not SHOULD
jo: we could continue with SHOULD until implementations. If implementations show it's irritating, take it out
<jo> PROPOSED RESOLUTION: Introduce some text stating that for the purposes of consistent pagination proxies MAY serve stale data but when doing do SHOULD notify the user that this is the case and SHOULD provide a simple means of retrieving a fresh copy - noting that from a process point of view it is a "feature at risk"
francois: do we need to state this in the document?
<francois> +1
jo: no, just in the actions
<jo> +1
0
<SeanP> Still 0, I like the "may" proposal
andrews: I do see the logic of
treating sub-pages as just scrolling
... so prefer MAY to SHOULD
<Zakim> jo, you wanted to point out to andrews ...
jo: but paging where there's
clearly comms with a remote server doesn't feel like just
scrolling up and down
... so believe we should give SHOULD a shot at
implementation
andrews: ok maybe for a last-call draft
jo: to move from Candidate Rec to
Rec must have implementations
... so we'd find out the experience at that stage
<jo> PROPOSED RESOLUTION: Introduce some text stating that for the purposes of consistent pagination proxies MAY serve stale data but when doing do SHOULD notify the user that this is the case and SHOULD provide a simple means of retrieving a fresh copy - noting that from a process point of view it is a "feature at risk"
<jo> +1
<francois> +1
0
<andrews> 0
<SeanP> 0
RESOLUTION: Introduce some text stating that for the purposes of consistent pagination proxies MAY serve stale data but when doing do SHOULD notify the user that this is the case and SHOULD provide a simple means of retrieving a fresh copy - noting that from a process point of view it is a "feature at risk"
jo: already addressesd in new
draft
... so I'll circulate new draft
... and then we can finish this call on-time
francois: ok, we'll see if next week we're ready for last call
jo: yes, so I'll note that in the
draft
... So draft this afternoon, then everyone contribute Appendix
B examples then final draft Friday