- From: Francois Daoust <fd@w3.org>
- Date: Tue, 13 Jan 2009 17:13:08 +0100
- To: MWI BPWG Public <public-bpwg@w3.org>
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 Tuesday, 13 January 2009 16:13:44 UTC