- From: Tom Hume <Tom.Hume@futureplatforms.com>
- Date: Wed, 14 Jan 2009 14:01:29 +0000
- To: Luca Passani <passani@eunet.no>
- Cc: MWI BPWG Public <public-bpwg@w3.org>
Luca Look from the section "Included resources of a non transformed resource should not be transformed" downwards in the minutes. In short order we came up with a number of reasons why this wasn't as attractive an idea as it originally seemed, and voted against it: - resources may not be referenced from markup at all - this would shift HTTP from a request/response model to a document/ sub-documents model - dependencies on sub-documents may be recursive - content providers may wish to have documents transformed, but images not transformed Tom On 14 Jan 2009, at 12:30, Luca Passani wrote: > > > 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] >> >> >> > > > -- Future Platforms Ltd e: Tom.Hume@futureplatforms.com t: +44 (0) 1273 819038 m: +44 (0) 7971 781422 company: www.futureplatforms.com personal: tomhume.org
Received on Wednesday, 14 January 2009 14:09:02 UTC