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

[minutes] Tuesday 13 January 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 13 Jan 2009 17:13:08 +0100
Message-ID: <496CBD94.5030507@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:58 UTC