- From: Francois Daoust <fd@w3.org>
- Date: Tue, 03 Jun 2008 17:56:22 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
Hi,
The minutes for today's call are available at:
http://www.w3.org/2008/06/03-bpwg-minutes.html
... and copied as text below.
Resolutions:
- keep it simple for the VIA header comment format: http://[ct
namespace] and no mention of properties + the possibility to replace the
URI with a link to a POWDER-like resource
- if an HTML response includes a <link rel="alternate" media="handheld"
type="[content-type]" href="[uri]" /> tag, the CT-proxy SHOULD request
and return the resource pointed to by [uri] instead of the current one.
- don't recommend the addition of a "Warning" HTTP header to the request
- leave the "2 CT-proxy on the line" tricky issue out of scope and
reference it the "Scope for Future Work" appendix
- Final name for the "X-Device" header is "X-Device"
- do not say anything on "Content-Location" and other generic caching
techniques
Jo is to provide an updated draft by next week.
We'll review the updated draft next week, with a view to progressing to
Last Call.
If there's any topic you want to address, now is the time!
Francois.
03 Jun 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2008/06/03-bpwg-irc
Attendees
Present
andrews, SeanP, Jo, francois
Regrets
Murari, rob, Pontus
Chair
francois
Scribe
andrews
Contents
* [4]Topics
1. [5]Via header format
2. [6]Link element
3. [7]Vary, cache efficiency and Content-Location
4. [8]Warning header in requests
5. [9]X-Device- header: final name
6. [10]name of x-device header
7. [11]Vary, cache efficiency and Content-Location
8. [12]What's next
* [13]Summary of Action Items
_________________________________________________________
Via header format
<francois> [14]discussion on via header format
[14]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0036.html
francois: Is there an easy way to identify CT proxy capabilities in
the via header?
... Suggest we keep it simple. Nothing to prevent anyone putting
anything in the header.
<francois> [15]http://www.w3.org/2008/04/ct#active
[15] http://www.w3.org/2008/04/ct#active
<francois>
[16]http://www.w3.org/2008/04/ct#active&intend_to_transform
[16] http://www.w3.org/2008/04/ct#active&intend_to_transform
francois: Suggested URLs above
... so either have uri that says "I am a proxy"
... or a uri that relates to POWDER or similar.
SeanP: We have not defined what the values after the "#" should be.
Maybe we should limit to say 4 values?
... but agree - keep it simple
francois: It is useful to have the flag that there is a CT proxy
<francois> PROPOSED RESOLUTION: keep it simple for the VIA header
comment format: http://[ct namespace] and no mention of properties
<francois> PROPOSED RESOLUTION: keep it simple for the VIA header
comment format: http://[ct namespace] and no mention of properties +
the possibility to replace the URI with a link to a POWDER-like
resource
andrews: Is this to be mandatory?
<SeanP> me I'm back
francois: don't think so - it is a "should". Could be stripped by
other proxies.
<SeanP> +1
<francois> +1
RESOLUTION: keep it simple for the VIA header comment format:
http://[ct namespace] and no mention of properties + the possibility
to replace the URI with a link to a POWDER-like resource
<francois> Close ACTION-750
<trackbot-ng> ACTION-750 Investigate how to add multiple
property/values to the URI closed
Link element
<francois> [17]link element
[17]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0021.html
francois: No clear support for use of link element to indicate
handheld content
... i.e. to indicate that a page *is* handheld content.
SeanP: There are other ways to do this.
francois: But we can still have guidline that CT proxy will redirect
user to a handheld version of the page
... that is indicated in the link element
<francois> PROPOSED RESOLUTION: if an HTML response includes a <link
rel="alternate" media="handheld" type="[content-type]" href="[uri]"
/> tag, the CT-proxy SHOULD request and return the resource pointed
to by [uri] instead of the current one.
<SeanP> +1
+1
<francois> +1
RESOLUTION: if an HTML response includes a <link rel="alternate"
media="handheld" type="[content-type]" href="[uri]" /> tag, the
CT-proxy SHOULD request and return the resource pointed to by [uri]
instead of the current one.
Vary, cache efficiency and Content-Location
francois: Would like Jo's contribution for this so move to next
topic
Warning header in requests
francois: CT proxy could add warning header if it alters an HTTP
request
... to show that request has changed
... But changes could be shown in other ways
... We would have to register a different code for warning (214 is
used for responses)
... I don't see added value in using warning.
SeanP: Agree, doesn't seem worth doing.
francois: Intent was to use warning instead of the x-device headers
<francois> PROPOSED RESOLUTION: don't recommend the addition of a
"Warning" HTTP header to the request
<SeanP> +1
<francois> +1
andrews: Keep it simple - don't adopt it
+1
RESOLUTION: don't recommend the addition of a "Warning" HTTP header
to the request
X-Device- header: final name
francois: 2nd problem, what should a CT proxy do if it receives such
a header
... this would indicate that a CT has already happened so CT proxy
should not perform another CT
<francois> PROPOSED RESOLUTION: If the HTTP request defines a
"X-Device" header, the proxy MUST NOT apply further transformation.
<SeanP> +1
francois: Could produce asymetry in priority between requests and
responses
... Downstream (nearer handset) CT proxy will add x-device header,
upstream CT proxy sees this header
... upstream CT proxy should not change header and should not change
response
jo: Presence of which x-device headers indicates that a CT proxy is
there?
... answer is probably that we can not say precisely
... If network has a CT proxy but user is talking to an upstream
proxy, which should be transforming?
... Maybe this needs to be moved to an informative appendix as known
future work
SeanP: Agree that this is a complex issue. Some cases are out of
scope of Guidlines. Example, operator had CT proxy and request is to
a search engine which has a CT proxy
<francois> PROPOSED RESOLUTION: leave the "2 CT-proxy on the line"
tricky issue out of scope and reference it the "Scope for Future
Work" appendix
jo: x- headers are experimental. This is probably an area of
heuristics.
... Can imagine an upsteam proxy "undoing" x- headers.
+1
<francois> +1
<SeanP> +!
<SeanP> +1
RESOLUTION: leave the "2 CT-proxy on the line" tricky issue out of
scope and reference it the "Scope for Future Work" appendix
name of x-device header
francois: No preference.
jo: Argument for x-device is that it is currently used. Argument
against is that we do not necessarily understand the exact context
of the use today.
... Stricly, a proxy does not know what the device is.
... Favours x-received as being more precise
francois: Agrees that x-received is more precise.
<SeanP> +q
andrews: Favour x-device because it is used today. Guidlines can be
used to better define meaning of x-device.
SeanP: Agrees with Jo's point but does not feel that it is worth
changing from x-device headers.
jo: Maybe other vendors with other headers.
<francois> PROPOSED RESOLUTION: Final name for the "X-Device" header
is "X-Device"
+1
<SeanP> +1
<francois> +1
<jo> 0
RESOLUTION: Final name for the "X-Device" header is "X-Device"
francois: Add note that this name was kept since it is used in
practice.
<jo> ACTION: Jo to add note describing the circumstances of choosing
the X-Device prefix and explaining that it's not necessarily the
actual device headers and other weasel words, yada yada [recorded in
[18]http://www.w3.org/2008/06/03-bpwg-minutes.html#action01]
<trackbot-ng> Created ACTION-766 - Add note describing the
circumstances of choosing the X-Device prefix and explaining that
it's not necessarily the actual device headers and other weasel
words, yada yada [on Jo Rabin - due 2008-06-10].
Vary, cache efficiency and Content-Location
francois: Comment on mailing list
<francois> [19]Vary and Content-Location
[19]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0022.html
francois: If content providers use vary: user-agent this would
create many cache entries
... so not cache friendly. Usually there are a limited number of
representations.
... CT proxies will typically generate content dynamically so
probably not a problem.
<francois> PROPOSED RESOLUTION: to promote the use of the
Content-Location header, complete the part on the "vary" HTTP header
in 4.2 with a note along the lines of: "When varying representations
based on received HTTP headers, cache-efficient techniques should be
used. For example, if the total number of representations is limited
whereas the number of values for a HTTP header used for varying
representation is high [typically the case when varying
representations based on
<francois> the User-Agent string], the different representations
should be made available at specific URIs and the request to the
generic resource should return the specific representation along
with a Content-Location header that identifies the representation
being served."
<francois> Future requests MAY specify the Content-Location URI as
the request- URI if the desire is to identify the source of that
particular entity
jo: Not clear how this relate to vary header or caching?
... /I am a little bit lost in this discussion
<francois> PROPOSED RESOLUTION: do not say anything on
"Content-Location" and other generic caching techniques
francois: Suggest that this could potentially confuse the Guidline's
readers so we should not add anything.
<SeanP> +1
+1
<jo> +1
<francois> +1
RESOLUTION: do not say anything on "Content-Location" and other
generic caching techniques
What's next
francois: Please look at remaining actions. All topics and issues
have been addressed. Please raise any more topics now.
jo: Will update draft document by next Tuesday.
francois: Target is to update draft and review next Tuesday. Next
Thursday, present draft to working group. Pubilish at next
face-to-face in Sofia.
Summary of Action Items
[NEW] ACTION: Jo to add note describing the circumstances of
choosing the X-Device prefix and explaining that it's not
necessarily the actual device headers and other weasel words, yada
yada [recorded in
[20]http://www.w3.org/2008/06/03-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 3 June 2008 15:56:57 UTC