See also: IRC log
francois: this should run for 1 week.
jo: Please answer ASAP. London is in the lead, by a short head.
<francois> questionnaire on next F2F's location
jo: Dan has an action to find hosts for Boston etc.
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.
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 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].
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> 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
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 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 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.
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
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]
jo: We've already sent them some comments
francois: yep
<jo> Call for LC Comments from WebApps
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 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