- From: Luca Passani <passani@eunet.no>
- Date: Wed, 14 Jan 2009 13:30:30 +0100
- To: MWI BPWG Public <public-bpwg@w3.org>
I read the minutes a few times, but I am still confused. Was it decided that it's OK to just place no transform on the main XHTML page to protect also the resources referenced in it? or not? or was it decided to be silent and let the point be ambiguous? Luca Francois Daoust wrote: > > Hi, > > The minutes of today's (bad-audio) call are available at: > http://www.w3.org/2009/01/13-bpwg-minutes.html > > ... and copied as text below. > > > Resolutions taken: > - on CT, We will not reconsider the question of extending the > cache-control directive for CT usage > - on CT, We will not say anything about transforming included resources > > Please answer the questionnaire re. next F2F: > http://www.w3.org/2002/09/wbs/37584/BPWG-Possible-F2F-March-2009/ > > On CT, the discussion on mandating heuristics and security issues > linked to links rewriting were postponed to next week, so that the > discussion may go on on the mailing-list. No final decision on > registering the "X-Device-*" like as we're still unclear about > deprecation rules for "X-" once the non-"X-" header becomes available. > > Bruce is to take the lead on reviewing and possibly commenting the > Widgets packaging document. > > Francois. > > > 13 Jan 2009 > > [2]Agenda > > [2] > http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0005.html > > See also: [3]IRC log > > [3] http://www.w3.org/2009/01/13-bpwg-irc > > Attendees > > Present > tomhume, Jeff, francois, jo, Dom, rob, Bryan_Sullivan, yeliz, > EdC, miguel, achuter, bruce, martin_spain > > Regrets > DKA, SeanP, DavidStorey, abel, nacho > > Chair > jo > > Scribe > tom > > Contents > > * [4]Topics > 1. [5]F2F Poll > 2. [6]Update on Mobile Accessibility > 3. [7]Mandating respect of heuristics > 4. [8]HTTPS Link Rewriting > 5. [9]X-Device-* HTTP header fields > 6. [10]re-consider our position regarding the use of > Cache-Control extension mechanisms > 7. [11]Included resources of a non transformed resource should > not be transformed. > 8. [12]Request for last call comments [$1\47], from WebApps WG > on Widgets 1.0: Packaging and Configuration > * [13]Summary of Action Items > _________________________________________________________ > > F2F Poll > > francois: this should run for 1 week. > > jo: Please answer ASAP. London is in the lead, by a short head. > > <francois> [14]questionnaire on next F2F's location > > [14] > http://www.w3.org/2002/09/wbs/37584/BPWG-Possible-F2F-March-2009/ > > jo: Dan has an action to find hosts for Boston etc. > > Update on Mobile Accessibility > > alan: Sent a message to the list, but it didn't arrive. > > <jo> / > > alan: It was updated in October, I haven't done any work on it yet. > WCAG became a W3C recommendation end December, but it's still > pending some changes from Sean and Lisa in the Education & Outreach > WG. Next week I'll do this, publish a new version which can be > approved by the working group. > ... No more work required by the group at the moment. > ... Before next weeks call (before Monday next week) I should be > able to update it, so we can review Tuesday and the following Friday > the EOWG can review and pass onto the WCAG. > > jo: We should give this group a week to review, so if you could get > out by Monday that'd be great. > > Mandating respect of heuristics > > francois: the main topic that remains re CTG are those in the > agenda, plus a few details > ... Mandating respect of explicit mobile heuristics, mandating > meaning the CT proxy SHOULD NOT transcode responses where these > heuristics are found > ... There's discussion on the CT mailing list for the time being > around this. I've not had time to go through Eduardo's last > response. I suggest we postpone the discussion til next week, in > Sean's absence > > jo: Plus we've not aired this discussion on the list. > > <EdC> +1 for postponing. > > <jo> ACTION: Francois to stimulate discussion on the SHOULD NOT > question ref mobile heuristics [recorded in > [15]http://www.w3.org/2009/01/13-bpwg-minutes.html#action01] > > <trackbot> Created ACTION-896 - Stimulate discussion on the SHOULD > NOT question ref mobile heuristics [on François Daoust - due > 2009-01-20]. > > HTTPS Link Rewriting > > tomhume: we're also awaiting some feedback re safe means to > transcode HTTPS content from the transcoder folks > > jo: This was an action on Sean, I think? > > <francois> ISSUE-285? > > <trackbot> ISSUE-285 -- Does BPWG feel it can write Best Practices > on links rewriting in the CT guidelines? Or that it cannot be a best > practice? -- OPEN > > <trackbot> > [16]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285 > > [16] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285 > > francois: there are two things - issue-285 to get advice from the > main body of the working group on best practices around security > guidelines. > ... and an action from Rob to start ???ing different guidelines > being composed. > > jo: for the benefit of the WG here, we reached a stalemate in > discussion and Rob took an action to write some guidelines on "is > there anything we can say is best practice around the idea of > intercepting links that people have deliberately designated as > secure". The task-force was evenly divided between those that > thought not and those that think saying something is essential > > <EdC> I was suddenly diverted to another call, and now cannot join > the number at +33 (busy tone). > > jo: for HTTPS, we're waiting for a discussion on-list > > X-Device-* HTTP header fields > > francois: in the guidelines we emphasise that whenever a CT proxy > changes one of the HTTP Header fields it must add an X-Device- and > the name of the original field, so that the origin server can > reconstruct the original HTTP request from these headers. The > problem is with the registration of these fields: X- means > experimental, by definition we cannot register this and new header > fields must be registered with the IETF. > > <jo> PROPOSED RESOLUTION: We will document this as X-TBD-* headers > and explain that registration is being sought and that > implementations should expect to see both with and without the X- > > <jeffs> this seems no longer "experimental", so move to Provisional > Header reg at IETF instead of X-Device-* makes sense to me, so it > would have my +1 > > <jo> [francois notes that we may have objections to going to rec > with X- and also that the Device- prefix is overloaded] > > <EdC> Comment: some other standards have kept x-* fields (e.g. > Uaprof), without registration. Registering different fields will > require supporting both for the foreseeable future both in > CT-proxies and application servers. Is there a KO criterion to go > the way of registration? > > <jo> PROPOSED RESOLUTION: We will document this as X-TBD-* headers > and explain that registration is being sought and that > implementations should expect to see both with and without the X- > > <francois> [I don't think the "Device-" header is overloaded. The > "Original-" header is, which was one of the possibilities to improve > the header name in the first place.] > > jo: edC, I understand the point re keeping X- fields > ... my feeling is that we can get away with it by noting this as > what we're seeing. > > <Bryan> sorry, have to drop off for another call > > <francois> [My point is if we are to change the name of the X- > headers, then we should as well register proper names *without* the > X- prefix!] > > jo: I don't think the point is whether we register an X- header, > it's that we can't do this > ... the proposed resolution is we document as X- headers and proceed > in parallel with registration. Any objections? > > francois: I think the proposed resolution should be to document this > as X-Device- > ... if you change the name there's no reason to keep the X-, we can > register proper headers if we invent a new header. > > <jo> PROPOSED RESOLUTION: We will document this as X-Device-* > headers and explain that registration is being sought and that > implementations should expect to see both with and without the X- > > <jo> +1 > > <EdC> What is the ultimate relation between X-Device-* and the TBD-* > ? Migration? > > jo: the TBD is no longer on the table > > <rob> +1 > > <francois> +1 > > <EdC> MUST implementations support both? > > <EdC> SHOULD or MUST? > > jo: they SHOULD > > <EdC> To be practical: what must the CT-proxies support? > > edC: if there are two header fields, then app servers must support > both. What will the CT proxies have to do? MUST they support the > registered header field once the registration passes? Can they just > continue with the older experimental header fields? > > jo: we'll have a problem if there's a MUST surrounding a future > event, this is probably a W3C conformance question > > edC: there is a question of the migration path. Also, can it be that > a proxy supports both at the same time? > ... Should it put the header into both? There's nothing to prevent > it, but this is linked to the previous question. > > jo: it'd be good if we just had one. How long will it take to > register these headers? > > francois: it's easily done, we need to define the headers in the > guidelines (which we're doing anyway) then send an email to the > IETF. > > jo: so there'll be no dependency from the IETF delaying us? > > francois: there's a small risk of their not liking the name (but I > don't think we need to worry about that). The registration doesn't > take long and isn't hard to do. > > edC: There was a question that it'd be good if we just had 1 field. > On the migration path: if after some time the TBD header fields come > into force, CT proxies will need to send both to keep app servers > working with old and new headers working... and you don't want to > exclude one or the other. > > <jo> PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* > headers and review progress. We will document that Proxies MUST use > these headers and note taht they SHOULD use the X-Device headers at > least initially for backwards compatibility reasons > > tomhume: will this mean that on publication of the CTG, every proxy > is in conflict with them? > > jo: possibly true > > rob: I can't comment, I'm not sure how our proxy works. > > <EdC> Record the resolution proposal and postpone it to when all > other CT-proxy-representatives are present to comment? > > rob: being able to duplicate the header and having 2 is harder than > just changing the header > > jo: This problem is partly introduced by the convention of X- > > rob: our preference is to change the header... but some applications > may be looking for one value, others for another. > ... Eduardo's problem still exists. > > jo: we can't standardise on current practices; we will face this > problem. > > <jo> PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* > headers and review progress. We will document that Proxies MUST use > these headers and note that they SHOULD use the X-Device headers at > least initially for backwards compatibility reasons > > <francois> +1 > > <rob> +1 > > +1 > > <jo> straw poll, -1 if you think we do not have enough info to > proceed +1 to take the resolution > > <jo> +1 > > +1 straw poll > > <brucel> abstention > > rob: resolution avoids issue of using both > > <brucel> abstention from resolution > > jo: effectively it says they SHOULD use both > > rob: this may last for years. > > jo: it will. I see no objections, are there any? > > <jo> PROPOSED RESOLUTION: We will go ahead and register the DEVICE-* > headers and review progress. We will document that Proxies MUST use > these headers and note that they SHOULD use the X-Device headers at > least initially for backwards compatibility reasons > > <jo> objections? > > <EdC> -0.5 > > jo: that counts. How would you like to fix this up? > > <EdC> Is there a criterion to phase out the X-device fields? > > <EdC> Are there W3C deprecation criteria or rules? > > jo: not that I know of. Anyone know enough about the use of X- > convention, to determine what IETF think about this? > ... Eduardo, can you take an action to research what ??? X- ???? > > <jo> ACTION: EdC to establish what best current practice is with > regard the withrawal of use of X- once the non X- form is agreed > [recorded in > [17]http://www.w3.org/2009/01/13-bpwg-minutes.html#action02] > > <trackbot> Sorry, couldn't find user - EdC > > <EdC> ok. > > <jo> ACTION: casais to establish what best current practice is with > regard the withrawal of use of X- once the non X- form is agreed > [recorded in > [18]http://www.w3.org/2009/01/13-bpwg-minutes.html#action03] > > <trackbot> Created ACTION-897 - Establish what best current practice > is with regard the withrawal of use of X- once the non X- form is > agreed [on Eduardo Casais - due 2009-01-20]. > > jo: we'll come back to this later. > > re-consider our position regarding the use of Cache-Control extension > mechanisms > > jo: we did look at this, there were some suggestions wrt extending > Cache-control in the first drafts of the document. We decided > unequivocally that any such changes would be a substantial change to > HTTP, so these were dropped and moved to a discussion at the end of > the document as "an area for further work". I feel relatively > strongly that we should not reopen this point. > > tomhume: this was an area of HTTP specifically written with future > extensibility in mind, as opposed to a new header. I wasn't privy to > original discussions and not sure what HTTP profiling is. > > jo: we have had pushback from IETF... and we're not chartered to do > this. Whilst we do skirt narrowly around the border of "new > technology", though this feels firmly in that area. > > Francois: I remember having done some research on that and we had > extensive discussions in the past. The extensions don't solve the > entire problem, so aren't a satisfactory enough solution and doesn't > add much to the no-transform directive (it does fix cases where it > can't be used safely, but doesn't do much more). For this reason on > top of the ones Jo mentioned, I don't think it's a good idea to go > down this path. > > <jo> PROPOSED RESOLUTION:We will not reconsider the question of > extending the cache-control directive for CT usage > > <jo> +1 > > <francois> +1 > > <rob> +1 > > <EdC> It is more: we have reconsidered and decided against it? > > <EdC> +1 > > +1 > > <jo> [yes, EdC we will not reconsider the previous negative on this, > it remains negative] > > RESOLUTION: We will not reconsider the question of extending the > cache-control directive for CT usage > > Included resources of a non transformed resource should not be > transformed. > > jo: there's no practical mechanism to put no-transform onto included > resources, and it may be difficult to put this onto resources > referenced from html > > edC: does everyone understand the proposal? > ... this applies to stylesheets, images > ... the first one is a subtle point: cache-control isn't attached to > a document, but to an HTTP request or response, so we're subtly > tweaking a part of the HTTP stack. In essence the sub-parts of the > document will provoke further HTTP requests and responses. But here > we're making an aggregation and shifting the association of the > cache-control directive to a set of documents. It's a subtle thing > but if people are complaining about profiling HTTP they might compla > > jo: I (regretfully) agree > > <francois> [I agree too] > > jo: we may be extending the meaning of http in a way they don't like > > edC: we're effectively closing the door to an (unimportant?) use > case. You might have a document you want left alone, with images > converted. If you extend no-transform to apply to everything below > you close the door to this. > ... I'm also afraid this kind of functionality will impose a very > specific architecture for CT proxies. You have 2 choices: a proxy > grabs the first HTTP request from the terminal, collects document, > collects sub-parts, then decides to transform or not. > ... or you just get the first HTTP request for markup, send it back > (untransformed in this case) then the terminal sends another HTTP > request at which point you have to be able to associate this with > the earlier request. This means you have to implement sessioning, or > change the way the proxy works and fall back on the first mechanism. > > <Zakim> tomhume, you wanted to wonder about resources not referenced > from markup > > tomhume: images may not be referred from a page (e.g. wallpapers, > screensavers); also requests might include sub-requests (HTML > references SVG document references sub-document etc etc.) > > rob: a CT does have to have some concept of browsing sessions to > work in the way they do. There may be simpler transformations which > don't need sessions, but if you're going to adapt HTML (partic. with > scripts) you do need a session concept. > > <jo> PROPOSED RESOLUTION: We will not say anything about > transforming included resources [that was not your best ever idea > Jo] > > francois; in the case of cache-control: no-transform, I agree with > edC. In the case of explicit heuristics, here we have some semantics > saying the main document is for mobile, therefore sub-documents can > be assumed to be mobile too. > > scribe: if we mandate some heuristics we should caveat that it's not > easy to link a request for an embedded resource to the request for > the main document. > > jo: aren't we saying that for all the reasons listed here, it's not > workable. To link it back in as a mandatory heuristic... would not > be wise, surely > > francois: I think it can be worked out in some cases. We can't say > you must not transform in ????? > > <jo> PROPOSED RESOLUTION: We will not say anything about > transforming included resources [that was not your best ever idea > Jo] > > jo: we're in danger of having heuristics upon heuristics. I'd prefer > we not mention this. Any strong objection to moving ahead > w/resolution? > > <francois> +1 > > <EdC> +1 > > <jo> +1 > > <rob> +1 > > +1 > > RESOLUTION: We will not say anything about transforming included > resources [that was not your best ever idea Jo] > > Request for last call comments [$1\47], from WebApps WG on Widgets 1.0: > Packaging and Configuration > > jo: We've already sent them some comments > > francois: yep > > <jo> [19]Call for LC Comments from WebApps > > [19] > http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0002.html > > jo: anyone else moved to take on preparing this response, or shall > we note this and note folks should respond individually? > > francois: we haven't reviewed (???) > > bruce: this was written by friends so I might not be impartial > > jo: the BPWG should we aware this is related to what we do. If > anyone has a view they should raise it with the WG > > bruce: I could contact some people I think have been involved and > ask them for a heads up of where there might be items of contention > or interest? > > jo: there could be things in here that don't work well from a mobile > perspective, we should point this out. > > bruce: I imagine it's based on the opera widget spec which we put > fwd a while back... so should be mobile-friendly > > jo: notes Nokia involvement > > <jo> ACTION: Bruce to take lead on pointing out anything in the > WebApps doc that we should be aware of and/or comment on [recorded > in [20]http://www.w3.org/2009/01/13-bpwg-minutes.html#action04] > > <trackbot> Created ACTION-898 - Take lead on pointing out anything > in the WebApps doc that we should be aware of and/or comment on [on > Bruce Lawson - due 2009-01-20]. > > jo: AOB? > > <jsmanrique> bye > > Summary of Action Items > > [NEW] ACTION: Bruce to take lead on pointing out anything in the > WebApps doc that we should be aware of and/or comment on [recorded > in [21]http://www.w3.org/2009/01/13-bpwg-minutes.html#action04] > [NEW] ACTION: casais to establish what best current practice is with > regard the withrawal of use of X- once the non X- form is agreed > [recorded in > [22]http://www.w3.org/2009/01/13-bpwg-minutes.html#action03] > [NEW] ACTION: EdC to establish what best current practice is with > regard the withrawal of use of X- once the non X- form is agreed > [recorded in > [23]http://www.w3.org/2009/01/13-bpwg-minutes.html#action02] > [NEW] ACTION: Francois to stimulate discussion on the SHOULD NOT > question ref mobile heuristics [recorded in > [24]http://www.w3.org/2009/01/13-bpwg-minutes.html#action01] > > [End of minutes] > > >
Received on Wednesday, 14 January 2009 12:31:11 UTC