Mobile Web BPWG Content Transformation Teleconference

Fat Tuesday

<Magnus> 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> 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> CT landscape

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.