See also: IRC log
-> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0154.html fd's no-comment comment
<hgerlach> http://cgi.w3.org/member-bin/irc/irc.cgi works
<francois> IAB message
Francois: may be some comments coming from W3C internal review of the CT guidelines.
Francois: these offer W3C staff the chance to comment given they are very busy
<francois> - Content Transformation Proxies: Guidelines
<francois> - Guidelines for Mobile Web Content Transformation Proxies
Francois: on the doc name, we can narrow the choice between two
<hgerlach> b) +1
Francois: we are more about web browsing than web, but browsing may be a confusing term to include; mobile web seems fine
<andrews> I favour the second
<francois> PROPOSED RESOLUTION: The title of the spec will be "Guidelines for Mobile Web Content Transformation Proxies"
<andrews> +1
Bryan: recommend to leave out mobile as this is whole web content
<andrews> Good point - I agree
<hgerlach> Guidelines for Content Transformation Proxies in Mobile Networks
<tomhume> +1
<andrews> +1
<hgerlach> -1
Heiko: proposes "in Mobile Networks"
<francois> PROPOSED RESOLUTION: The title of the spec will be "Guidelines for Web Content Transformation Proxies"
<francois> +1
Bryan: we are not limiting this to mobile networks; limited capability devices in general
+1
<andrews> +1
<hgerlach> +1
<tomhume> +1
<rob> +1
Francois: suggests we come to agreement to close this item as we could spend a lot of time on it
RESOLUTION: The title of the spec will be "Guidelines for Web Content Transformation Proxies"
Heiko: for new people, it may be hard to know that a key use case is in the mobile network context
Francois: the abstract of the title could include mobile and a proposal can be sent to the mailing list for that
<francois> close ACTION-831
<trackbot> ACTION-831 Continue discussion of the title on the list closed
<francois> heiko's comments
Francois: what can we resolve to do on this?
Heiko: this will come out of the whole comment resolution process; dont want to question the whole objective, this just provides general guidelines on how to improve the doc
Francois: we can include better examples and will come back to this in the end
<francois> Close ACTION-829
<trackbot> ACTION-829 Detail his thoughts arising from discussion of LC-2025 closed
<francois> Tom's proposal
<tomhume> Apologies all, I appear to have lost my telephone connection :(
<francois> "Within this document content transformation refers to the
<francois> manipulation of requests made to, and content delivered by, an origin
<francois> server. This manipulation is carried out by proxies with a view to
<francois> making content delivered more suitable for mobile presentation."
Francois: we should keep this for now, we do need to improve the intro, and can resolve to accept Tom's wording, about the 1st sentence of the intro
+1
<francois> PROPOSED RESOLUTION: re. LC-2012, use Tom's wording above, (and note we may have to further clarify the introduction for other reasons anyway)
+1
<francois> +1
<rob> +1
<hgerlach> +1
RESOLUTION: re.
LC-2012, use Tom's wording above, (and note we may have to
further clarify the introduction for other reasons
anyway)
... re. LC-2012, use Tom's wording above, (and note we may have
to further clarify the introduction for other reasons
anyway)
Francois: this one is a mistake; a bug in firefox
<francois> PROPOSED RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the document.
+1
RESOLUTION: LC-2064 is a mistake. There are no duplicated IDs in the document.
<francois> jo's proposal
<francois> PROPOSED RESOLUTION: re. LC-2003, stick to our position and use Jo's proposed response in public-bpwg-ct/2008Sep/0026.html
<hgerlach> -1
Francois: the essence is that this is an internal proxy issue
Heiko: don't agree, but can accept a team agreement
Bryan: we can consider content
management interfaces through other specifications or fora,
e.g. OMA
... OMA is working on content management interfaces for
example
Francois: agree that new technologies may be needed, if there is some clear work going on, we can mention it in the appendix
<Zakim> rob, you wanted to support Heiko's point that whitelists do exist - and won't go away just because we don't mention them
Rob: there is talk of mechanisms, but CP's are aware of the need to be on whitelists, so it is strange that we don't mention it in more detail
Francois: the rationale is that it is not needed for our guidelines, and is just the internal processing of proxies; we could add a note mentioning whitelists
Rob: a note should tell CP to contact the network operator if they are having trouble
Bryan: should be called the "proxy operator"
Francois: we could note that whitelist require CPs to submit some request to manage their handling
Rob: it should be the proxy operator who takes the action
Heiko: the diverging views here
indicate the need for clarity; the history of this is that the
use of lists in the proxy were to prevent adaptation; the same
concept can be applied to user-agents
... the only issue left is that 200 OK pages; for dedicated URL
we see issues with 200 OK instead of 406; human launguage
guidance of incompatibility cannot be used semantically and
thus we need whiltelists
Francois: proposes someone take an action to propose text so we can try to get agreement on it
Bryan: we could just list the
types of functions that could be controlled by whitelists in
tyhe document and leave the details out
... we can just list the functions e.g. don't modify this user
agent or that site
Francois: the listing of the functions is where the opinion divergence happens
Heiko: we had another item about the manipulation of other headers as well; we can expand the user-agent mod control whitelist text (if we had it) to include other headers as well
Francois: the relationship between whitelists and headers is unclear
Heiko: to control the changing of the user agent for specific pages
<Zakim> rob, you wanted to say we don't want to go into too much detail
Heiko: the decision on whether the UA is changed should be the site provider's
Rob: we should not go into too much detail about the purpose of the controls; just note that there may be functions that control the automatic behavior
Bryan: I can try to provide some more generic text that will hopefully be useful
<francois> ACTION: Bryan to provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 [recorded in http://www.w3.org/2008/09/23-bpwg-minutes.html#action01]
<trackbot> Created ACTION-850 - Provide some text on whitelists to see if we can include them somehow and come to an agreement re. LC-2003 [on Bryan Sullivan - due 2008-09-30].
<francois> Jo's proposal
<francois> "If the request contains a Cache-Control:
<francois> no-transform directive proxies must follow HTTP sections 14.9.5 and
<francois> 13.5.2."
Francois: HTTP RFC talks about
presence of the cache control header; we need to improve the
clarity of the text and would like to hear proposals for
that
... text in the CT guidelines of course...
<andrews> I think that we should leave the text unchanged.
<francois> "If the request contains a Cache-Control: no-transform
<francois> directive proxies must forward the request unaltered to the server,
<francois> other than to comply with transparent HTTP behaviour and as noted
<francois> below."
Francois: we could clarify the "as noted below" part.
<francois> "If the request contains a Cache-Control: no-transform directive proxies must forward the request unaltered to the server, other than to comply with transparent HTTP behavior and as noted below (see 4.1.6 Additional HTTP Headers)"
Andrew: would not suggest any changes; it would probably just make it less clear
Francois: we could ref the transparent HTTP behavior, but the whole spec is assumed to be on top of HTTP anyway
<francois> PROPOSED RESOLUTION: re. LC-2068, we think the text is as clear as possible. Stick to the text in the spec.
<andrews> +1
<francois> +1
+1
<hgerlach> +1
<rob> +1
RESOLUTION: re. LC-2068, we think the text is as clear as possible. Stick to the text in the spec.
<francois> Jo's proposal
<tomhume> Apologies to all, I'm unable to keep a mobile signal here and am about to lose net.connection :(
<francois> "If a server varies its representation according to examination of
<francois> received HTTP headers then it must include a Vary HTTP header indicating
<francois> the headers it examines in accordance with [ref].
<francois> "
Francois: The text is too long and thus obscure; Jo proposes to simplify the text
<francois> Current text: "If a server varies its representation according to examination of
<francois> received HTTP headers then it must include a Vary HTTP header indicating
<francois> this to be the case. If, in addition to, or instead of HTTP headers, a
<francois> server varies its representation based on other factors (e.g. source IP
<francois> Address) then it must, in accordance with [RFC 2616
<francois> HTTP]<http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#ref-HTTP>,
<francois> include a Vary header containing the value '*'.
<francois> "
Francois: fine with Jo's proposal; we don't need to restate the RFC; readers can go there to get details
<andrews> Agree
<francois> PROPOSED RESOLUTION: re. LC-2008, update the text according to Jo's proposal, as pasted above
<andrews> +1
<rob> +1
<francois> +1
RESOLUTION: re. LC-2008, update the text according to Jo's proposal, as pasted above
<francois> Heiko's proposal
Heiko: adpated pages could include headers/footers, for non-adapted pages we should not add these
Francois: these should be out ot scope of the document; there were comments on copyright issues
<Zakim> rob, you wanted to agree that just because it's possible does not mean it's recommended
Bryan: we should leave this off the table
<francois> PROPOSED RESOLUTION: re. LC-2090, leave headers/footers off the table. Out of scope of this document.
rob: agree that just because it's possible does not mean it's recommended
<hgerlach> -1
<francois> linked to http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0004.html
Heiko: with RC-2025, we discussed changes related to request for more details; now we are being less specific
<hgerlach> ok, bye
Francois: suggests that people think about this over the list in the meantime