[minutes] Tuesday 5 February 2008 Teleconf

Minutes from today's call:
http://www.w3.org/2008/02/05-bpwgct-minutes.html
... copied as text below.

I'll send an email to the mailing-list trying to summarize what we've 
been discussing and the issues that need to be addressed to move on.

Thanks,
François.


05 Feb 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Feb/0010.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/02/05-bpwgct-irc

Attendees

    Present
           francois, rob, Magnus, Bryan_Sullivan, SeanP, hgerlach,
           AndrewS

    Regrets
           Jo, Kemp

    Chair
           francois

    Scribe
           AndrewS

Contents

      * [4]Topics
          1. [5]Fat Tuesday
          2. [6]Next call
          3. [7]CT-proxy vs CT-gateway
          4. [8]HTTP Cache-Control extensions
      * [9]Summary of Action Items
      _________________________________________________________

Fat Tuesday

    <Magnus> [10]http://en.wikipedia.org/wiki/Semla

      [10] http://en.wikipedia.org/wiki/Semla

Next call

    francois: ... not available for next call

    Magnus: not available also

    <Magnus> +1

    Andrew: We will skip one week

    <francois> +1

CT-proxy vs CT-gateway

    francois: Re. discussion on mailing list
    ... Yves Lafon recommends that we use gateway since user-agent is
    being changed

    <Magnus> [11]http://www.w3.org/TR/ct-landscape/

      [11] http://www.w3.org/TR/ct-landscape/

    francois: using gateways could be confusing - we should continue to
    use proxy but define the term in the start

    Magnus: This is mentioned in the terminology section and this is
    accepted terminology

    <francois> [12]CT landscape

      [12] 
http://www.w3.org/TR/2007/WD-ct-landscape-20071025/#terminologyNote

    Rob: A CT- node can behave as either proxy of gateway. We could just
    call it a "proxy/gateway"

    francois: Wanted to draw this to the attention of the task force. We
    need to use terminology carefully when working with IETF.

    Bryan: Understands terminology but in reality most proxies do more
    than the strict IETF definition. We should use CT-proxy.

    +1

    Magnus: Could distinguish between a conventional proxy and an
    intercepting proxy (transparent)

    francois: Isn't a transparent proxy one that does not do anything?

    Magnus: An intercepting proxy typically does something to the data
    flow

HTTP Cache-Control extensions

    francois: Yves Lafon advised that there is no process to register
    HTTP header extensions and suggests that we use a draft IETF RFC
    ... But this has long time scales

    <francois> AndrewS: yes, I agree, it's not in the TF's charter. I'm
    a bit worried too on new HTTP headers as it doesn't address legacy
    browsers

    <francois> ... use of HTTP headers is fine with future browsers, but
    we have to address the legacy base

    Bryan: We are focused on mobile use case. Focusing on this area will
    help us achieve our time lines. But it is useful to remember the
    broarder case of any browser content access.

    francois: A draft IETF RFC for all content adaptation is more likely
    to have traction than one for just mobile access.

    SeanP: We should remember legacy handsets but se could consider IETF
    draft as well.

    francois: Writing a draft is not a problem but it would be difficult
    to present it to the HTTPBis working group.
    ... Validating the draft could take a long time since HTTP RFC is
    for a bigger picture than just the mobile world
    ... we need to take a decision: include IETF draft or not in our
    scope of work
    ... we will have to focus on what we can do without changing headers
    ... propose that we drop new cache-control headers.

    Bryan: We must be careful not to exclude custom headers which are
    already used in many cases.

    <francois> AndrewS: my understanding of HTTP RFC is that you can add
    some X- experimental headers

    AndrewS: We use "x-<header name>" already

    francois: What are these types of header used for?

    hgerlach: For example to get correct wallpaper for mobile device.

    AndrewS: We now need to decide whether we are going to include
    custom headers or not.

    SeanP: Custom headers or modified headers are similar.

    francois: Problem is with extending cache-control headers rather
    than with using x- headers
    ... we should try to restrict the use of x- headers.

    hgerlach: CT is normally used for non mobile aware sites so these
    sites are unlikely to understand custom headers.

    francois: Use of custom headers will only be understood by a few
    content servers.

    hgerlach: We should always use original user-agent and try to always
    use original headers.

    francois: We could use just x- headers which will not require us to
    register any extensions to existing headers.

    hgerlach: New headers could be useful for new content servers.

    Bryan: What is the market for CT-proxies which will use custom
    headers between the browser and the CT-proxy.

    francois: Headers are really needed between the CT-proxy and content
    servers.

    Bryan: Could we take a resolution to limit our scope to non-CT-aware
    browsers?

    francois: We should consider the interaction between the CT-proxy
    and the user rather than the browser.

    SeanP: We should stick to headers between the server and the proxy,
    not between the browser and the proxy.

    <francois> Regarding HTTP new headers use, this is what I think:

    <francois> - between the CT-proxy and the *browser*: no real
    interaction needed I would say

    <francois> - between the CT-proxy and the user: doesn't have to be
    HTTP-based, using some other magic such as web-based format should
    be enough

    <francois> - between the server and the CT-proxy: HTTP headers are
    the only way.

    <hgerlach> at least we should define a mobile OK header which can be
    "Mobile OK", "made for Mobile" or something else

    francois: This could be done in other ways, on the page or using
    POWDER.

    hgerlach: But POWDER always requires an additional fetch.
    ... We need a kind of "mini POWDER".

    francois: We will have to stop.

    <hgerlach> bye

    francois: We need to summarise this on the mail list. I will try to
    do so.

Summary of Action Items

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [13]scribe.perl version 1.133
     ([14]CVS log)
     $Date: 2008/02/05 16:25:12 $

      [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [14] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 5 February 2008 16:28:08 UTC