Mobile Web Best Practices Working Group Teleconference

 

 

<trackbot-ng> Date: 25 March 2008

Zakim aadd is me

<francois> Scribe: SeanP

<francois> ScribeNick: SeanP

Francois: Today we should go through our actions.

ACTION-682: Write a proposal on the HEAD request handling (§3.1.2)

Francois: Based on Martin's text

<francois> Martin's proposal

Francois: I simplified one of the sentences.

<francois> "Clients can issue HTTP HEAD requests in order to determine if a

<francois> resource is of a type and/or size that they are capable of handling. A

<francois> proxy may convert a HEAD request into a GET request if it requires the

<francois> response body to determine the characteristics of the transformed

<francois> response that it would return if the client issues a GET request. Where

<francois> this occurs, the proxy should (subject to HTTP cache directives) cache

<francois> the response that it receives so that if the client immediately follows

<francois> the HEAD request with a GET request for the same URI, the proxy is not

Francois: Any problems with the proposed text?

<francois> required to send a second GET request to the server."

<francois> PROPOSED RESOLUTION: use above text to resolve ACTION-682

<jo> subject to HTTP cache directives => providing in accordance with normal HTTP caching rules

<francois> PROPOSED RESOLUTION: leave above text to resolve ACTION-682 in the hands of the editor

<jo> +1

<MartinJ> +1

<rob> +1

<francois> RESOLUTION: leave above text to resolve ACTION-682 in the hands of the editor

<francois> Close ACTION-682

<trackbot-ng> ACTION-682 Write a proposal on the HEAD request handling. closed

ACTION-683: Inference on URIs (§3.1.2)

<francois> rob's contribution

Francois: Rob, you suggested we no change anything

Rob: I think the statement that is already there is all we can say.

Francois: I think that is fine. We'll leave it up to CT proxy vendors.
... Jo are you OK with that?

Jo: This is another "remaining silent" thing.
... It is worth mentioning that the server could give you some clues.
... If we are going to go with POWDER we should mention it in this section

Francois: Unsure about what we should say about POWDER.

Jo: Should say that these resources do this, those do that, etc.
... I think we have time. We've have time to find out how we should do the POWDER

Francois: Not sure how to put it in the document given that POWDER does not exist.

Jo: I think we are pretty close to resolving everything we want to put in the document except for the POWDER stuff.
... I think it is time to go to a FPWD and leave as editorial notes about the richer vocabulary.

<francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet 3 of 3.1.2

<francois> PROPOSED RESOLUTION: for ACTION-683, no change in bullet 3 of 3.1.2 save POWDER editorial's note

<rob> +1

<MartinJ> +1

<jo> +1

<francois> RESOLUTION: for ACTION-683, no change in bullet 3 of 3.1.2 save POWDER editorial's

<francois> Close ACTION-683

<trackbot-ng> ACTION-683 Raise an issue on inferencing from the structure of the URI what assumptions to make about another from the point of view of the CT Proxy closed

ACTION-684: Bad practice to strip comments in VIA header (§3.1.4)

Francois: Jo, you mentioned in 3.1.4 that this reverses HTTP
... HTTP says the proxy may strip comments.

Jo: It is probably worth finding out why HTTP says this.
... It seems kind of odd that HTTP says this.

Francois: Good point. I'll ask an HTTP expert.

Jo: Should say that if you are complying with transformation guidelines, you should not strip the comment.

<francois> ACTION: daoust to check why HTTP RFC states comments MAY be removed from a VIA header. [recorded in http://www.w3.org/2008/03/25-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-722 - Check why HTTP RFC states comments MAY be removed from a VIA header. [on François Daoust - due 2008-04-01].

Francois: Jo, do you think you will come up with a note.

Jo: The answer about having the editorial note is yes.

<jo> PROPOSED RESOLUTION: Yes we should add a note, pending FD's ACTION-722

<jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad practice to strip comments from Via HEader (ACTION-684), pending FD's ACTION-722

+1

<MartinJ> +1

<jo> PROPOSED RESOLUTION: Yes we should add a note on it being bad practice to strip comments from Via Header (ACTION-684) and that this is not consistent with HTTP, pending FD's ACTION-722

<francois> +1

<jo> RESOLUTION: Yes we should add a note on it being bad practice to strip comments from Via Header (ACTION-684) and that this is not consistent with HTTP, pending FD's ACTION-722

ACTION-685: how to embed original headers (§3.1.4)

Francois: I sent an email on Friday about this.

<inserted> I do not see any possibility to embed original headers in the generic case without requiring changes on the content providers side

Francois: Maybe we could address this next week since everyone was on vacation at the end of the week.
... HTTP doesn't say anything about bodies in GET requests.

Jo: I think it does.
... We could do some tests with real web servers.
... We can test whether if we put an extra thing in a request, existing servers fail.

Francois: We may have to make a test.

Jo: Agreed.

ACTION-706: Reword §2.5.1

Jo: We'll need to read your email about this and have a discussion next week.

Francois: We had a discussion about control by the user.

<francois> 2.5.1

Francois: Jo, you added an editorial note. Do we need to resolve on this?

Jo: The text of 2.5.1 as it stands was proposed by Bryan.
... I'm wonding if what is in 2.5.1 is strong enough.

Rob: My comment is that some of the CT servers are on particular web sites. They wouldn't bother to set up a session.
... It is probably best to leave it is "MAY".

Francois: I may agree.
... We agree that static settings are out of scope.
... What we are really talking about is session settings.
... We'll leave it as a MAY?

<francois> PROPOSED RESOLUTION: stick to "may" in 2.5.1, and change "persistent" to something less strong

Jo: I think we need to think about what a "session" is.
... not sure what we mean by session right now.
... I think 2.5.1 needs to be taken on the list.

<francois> ACTION: daoust to raise discussion on session settings vs persistent settings for 2.5.1 and 2.5.3 [recorded in http://www.w3.org/2008/03/25-bpwg-minutes.html#action02]

<trackbot-ng> Created ACTION-723 - Raise discussion on session settings vs persistent settings for 2.5.1 and 2.5.3 [on François Daoust - due 2008-04-01].

ACTION-707: Include examples in §2.5.1 bullet 3

Francois: Examples look fine to me.

<francois> Close ACTION-707

<trackbot-ng> ACTION-707 Include examples in 2.5.1 bullet 3 per the dicussion above closed

ACTION-708: Update 2.5.2

<jo> ACTION-708?

<trackbot-ng> ACTION-708 -- Jo Rabin to update 2.5.2 in accordance with discussion and Seoul resolution on preferences -- due 2008-03-18 -- OPEN

<trackbot-ng> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/708

Francois: Not sure I remember what this action was about.
... Was to rewrite section 2.5.2 given what happened a the Seoul F2F
... It was about if the user preferences contradict the server preferences.
... We do have a resolution on this.

Jo: Discussed this in the context of that this is the way CSS works.
... we need a better way to say this.

<jo> ACTION: Jo to raise discussion on list as to clarification of 2.5.2 "In cases where user preferences contradict server preferences, server preferences prevail, except where the user specifically requires their preferences to over-rule those of the server." [recorded in http://www.w3.org/2008/03/25-bpwg-minutes.html#action03]

<trackbot-ng> Created ACTION-724 - Raise discussion on list as to clarification of 2.5.2 \"In cases where user preferences contradict server preferences, server preferences prevail, except where the user specifically requires their preferences to over-rule those of the server.\" [on Jo Rabin - due 2008-04-01].

<francois> Close ACTION-708

<trackbot-ng> ACTION-708 Update 2.5.2 in accordance with discussion and Seoul resolution on preferences closed

ACTION-709: Write some examples for 2.5.3

<francois> fd's proposal

<francois> "The preferences of users and of servers MAY be ascertained by means

<francois> outside the scope of this document. These means include but are not

<francois> limited to:

<francois> - the use by transforming proxies of a disallow-list of Web sites for

<francois> which content transformation is known to be useless and/or to break

<francois> delivered content.

<francois> - the use by the transforming proxies of an allow-list of Web sites for

<francois> which content transformation is known to be necessary.

<francois> - user static preferences, e.g. provisioned by their CT service provider

<francois> or directly by the user through self-care web sites.

<francois> - terms and conditions of service, as agreed upon between the user and

<francois> the CT service provider."

Francois: This is where I had a chat with Bryan about static and persistent settings as opposed to session settings.
... The third point needs to be re-examined in light of the earlier discussion on this call.

<francois> PROPOSED RESOLUTION: remove user static preferences in above text for the time being, and use the resulting text for 2.5.3 under ACTION-709

Jo: These look pretty complete.

<jo> +1

<francois> RESOLUTION: remove user static preferences in above text for the time being, and use the resulting text for 2.5.3 under ACTION-709

ACTION-718: re Ajax/XHR requests and CT

<francois> fd's thoughts on this

Francois: I raised this problem.
... I tried to rephrase the discussion about this problem.
... the XHR request will use the same headers as a normal request, so there is no way to tell if it is XHR request.
... for simple calls in a web page; it it transformed the page, the CT proxy should know how to handle the request.
... the problem is for untransformed pages, it doesn't know that an XHR request should not be transformed as well.
... Martin said that requests and responses should only be transformed when the CT proxy knows that they originated from a transformed request.
... Bryan said that as a best practice, XHR request should change the UA.
... Good idea, will be hard to ask all developers to do this.
... Could recommend that developers add no-transform to XHR request.

Jo: no-transform is consistent with other things we have said in the document.

Francois: We've already said that elsewhere in the document.

Jo: We said we weren't going to discuss clients and users and we are drifting back to that.
... In this case it may we worth saying something.

Francois: I don't see how we can make it work.
... How can the proxy determine that calls originate from a page if it did not transform the page.
... Suppose you have a web page that contains too much JavaScript to transform. In the page there are some XHR calls.
... The CT proxy must be consistent.. It must not transform these XHR calls. There is no real way to detect that it is an XHR call.
... It will work in the future. We need to worry about legacy stuff.

Jo: Is this much of an issue. What are the chances that what comes back is in the form that needs to be transformed?

Francois: We may be creating an issue out of nothing.
... Let me come up with some smarter text on that.
... I'll come up with something along the lines of a warning about XHR.

Jo: I don't see anywhere in this document about what content types the CT proxy will intervene in.
... We should put something in about that.

Francois: We mention content types in the list of heuristics for determining whether a page is mobile.

Jo: It would be interesting to learn what is left alone.

<francois> ACTION: SeanP to send a list of content-types for which content transformation applies [recorded in http://www.w3.org/2008/03/25-bpwg-minutes.html#action04]

<trackbot-ng> Sorry, couldn't find user - SeanP

<francois> ACTION: Patterson to send a list of content-types for which content transformation applies [recorded in http://www.w3.org/2008/03/25-bpwg-minutes.html#action05]

<trackbot-ng> Created ACTION-725 - Send a list of content-types for which content transformation applies [on Sean Patterson - due 2008-04-01].

<jo> action- 4