See also: IRC log
<francois> discussion on via header format
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> http://www.w3.org/2008/04/ct#active
<francois> 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
<francois> link element
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.
francois: Would like Jo's contribution for this so move to next topic
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
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
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 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].
francois: Comment on mailing list
<francois> Vary and Content-Location
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
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.