W3C home > Mailing lists > Public > public-bpwg@w3.org > January 2009

Re: [minutes] Tuesday 13 January 2009

From: Tom Hume <Tom.Hume@futureplatforms.com>
Date: Wed, 14 Jan 2009 14:01:29 +0000
Cc: MWI BPWG Public <public-bpwg@w3.org>
Message-Id: <EC30CFAB-11F5-4395-B744-6F6EE9A5A608@futureplatforms.com>
To: Luca Passani <passani@eunet.no>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC