Mobile Web Best Practices Working Group Teleconference

LC-2090, LC-2091 on headers/footers

<francois> heiko's comments

francois: Heiko's not here but continuing on from last week
... headers/footers are out-of-scope
... and this should be made explicit in Scope section

jo: what was the original LC comment?

<francois> LC-2090

<francois> LC-2091

<francois> LC-2090: "Hi, I think that CTG should mention the fact that, in case of

<francois> transcoding, no extra content should be injected without the consent of

<francois> the original content owner. The idea is to avoid that W3C

<francois> protocols/guidelines implicitly endorse the attempt by those who

<francois> manage the transcoder to monetize on the effort/investment of other

<francois> people. Of course, there is also a point that injecting extra content

<francois> will invariably affect usability negatively and as such should be avoided.

<francois> I suggest the following addition:

<francois> "4.3.6.3 Injection of external content

<francois> In its effort to optimise the user experience of non-mobile optimised

<francois> sites, a proxy *should not* inject extra content into the transcoded

<francois> pages, where the term 'extra content' refers to text, links, banners

<francois> and other multimedia content which is not available on the original

<francois> untranscoded page. Addition of links aimed at implementing pagination

<francois> and navigational shortcuts is admissible.

<francois> Note: For clarity, it is emphasised that W3C does not endorse injection

<francois> of third-party content into a transcoded page without the explicit

<francois> consent of the content owner""

<francois> LC-2091: Consistently with my other comment that no extra content should be added

<francois> to transcoded web sites, I think that this should apply even more

<francois> strongly to mobile-optimised sites. Unfortunately, I see a lot of

<francois> transcoder deployments where operators and/or transcoder vendors feel

<francois> entitled to add advertisement and extra navigation bars to existing

<francois> mobile optimisec ontent. Because of this, I suggest the following

<francois> addition as a note to "4.3.1":

<francois> "Note: It should be stressed that, in case of a |Cache-Control:

<francois> no-transform| directive, adding any extra content (such as banners,

<francois> navigation bars and links not available in the original application) is

<francois> not admissable"

jo: this is really contentious, I don't think we can brush over it

tom: the LC comment is clear that they want no headers/footers added

francois: yes but there is also a wish to remark that a page is transcoded
... especially if opt-out links have to be supplied
... In sec 4.3.1 we state clearly that headers/footers are unacceptable with Cache-Control: no-transform

jo: so is this just for when transformations have been applied?
... Do we say "out-of-scope", "never at all" or "minimised"?

tomhume: what does minimised really mean?

francois: does it mean just minimal navigation to get around the adapted page but no branding or links away from the site?

tomhume: if we can't define "minimised" then "out-of-scope" is preferable

francois: yes, we shouldn't leave things open to interpretation

jo: OK, an "out-of-scope" note seems the way ahead

<jo> PROPOSED RESOLUTION: The manner in which transformation is carried out, when it is permitted, including any additional navigational or other material that is included, aside from where explicitly stated (insecure links etc.) will be noted in an "out of scope section" in the document. And resolve no to LC-2090 and LC-2091

francois: if the "out-of-scope" section is small enough it should go in the Scope section near the Introduction

<francois> +1

jo: yes, play it by ear

+1

<tomhume> +1

<jo> +1

RESOLUTION: The manner in which transformation is carried out, when it is permitted, including any additional navigational or other material that is included, aside from where explicitly stated (insecure links etc.) will be noted in an "out of scope section" in the document. And resolve no to LC-2090 and LC-2091

LC-2012: clarification of the introduction

<francois> PROPOSED RESOLUTION: re. LC-2012, replace the sentence deemed obscure by "Within this document content transformation refers to the manipulation of requests to, and responses from, an origin server. This manipulation is carried out by proxies in order to provide a better user experience of content that would otherwise result in an unsatisfactory experience on the device making the request."

<francois> +1

<jo> +1

<tomhume> +1

+1

RESOLUTION: re. LC-2012, replace the sentence deemed obscure by "Within this document content transformation refers to the manipulation of requests to, and responses from, an origin server. This manipulation is carried out by proxies in order to provide a better user experience of content that would otherwise result in an unsatisfactory experience on the device making the request."

<jo> LC-2012 therefore resolved yes

francois: I'm keeping LC tracker up-to-date in line with these resolutions

LC-2068: on requests that contain Cache-Control: no-transform directives

<francois> PROPOSED RESOLUTION: re. LC-2068, amend the text in section 4.1.2 with references to RFC HTTP sections. Final text: "If the request contains a Cache-Control: no-transform directive, proxies must not alter the request other than to comply with transparent HTTP behavior defined in HTTP RFC 2616 sections 14.9.5 and 13.5.2. and to add headers as described in 4.1.6 Additional HTTP Headers below."

francois: following a resolution next week, Jo you were worried about defining "transparent"

<jo> +1

<francois> +1

+1

<tomhume> +1

RESOLUTION: re. LC-2068, amend the text in section 4.1.2 with references to RFC HTTP sections. Final text: "If the request contains a Cache-Control: no-transform directive, proxies must not alter the request other than to comply with transparent HTTP behavior defined in HTTP RFC 2616 sections 14.9.5 and 13.5.2. and to add headers as described in 4.1.6 Additional HTTP Headers below."

<francois> LC-2068 therefore resolved yes

LC-2009, LC-2010, LC-2011: the Link element strikes back

<francois> Ping-pong on Link element

jo: this needs more discussion

jo: shall we put aside until TAG responds to our comments?

LC-2023: transformation across character sets

<francois> Tom's comments on CT and character sets

tomhume: seems unreasonable of forbid recoding of anything except UTF-8
... and there is clarity in the document already

francois: could include encoding in 4.3.6.1 examples
... could include a generic "don't break content" normative statement - but we already have one of those

jo: can weave in a reference to Character-Encoding
... this section is the only part of the document that states "if you've decided to transform content, here's how you do it"
... ie section 4.3.6 could contain a reference to Character-Encoding and any other transformation (eg headers/footers)

francois: Jo, what do you plan to say?

<jo> suggested text for a 4.3.6.3: Other than as noted in this section the nature of restructuring that is carried out, what is omitted and what is inserted is a copyright issues and is out of scope of this document

<jo> (plus something on pagination)

<jo> ack \

francois: I'm scared this opens the door to anything!

Bryan: could we say "what is inserted is out-of-scope"
... it's not particularly copyright issues, it's a can of worms

<jo> suggested text for a 4.3.6.3: Other than as noted in this section the nature of restructuring that is carried out, what is omitted and what is inserted may be a copyright issues and is in any case out of scope of this document

francois: still concerned this is very permissive

jo: are we happy leaving it at that?

<tomhume> +1

<jo> (could be a note in fact, rather than a separate sub-section)

<francois> +1

<Bryan> +1

<jo> PROPOSED RESOLUTION: On character encoding mention this under 4.3.6.1 and respond "Yes partial" to LC-2023

<francois> +1

+1

<tomhume> +1

RESOLUTION: On character encoding mention this under 4.3.6.1 and respond "Yes partial" to LC-2023

<jo> PROPOSED RESOLUTION: Mention the out of scope nature of the nature of restructuring under 4.3.6 somewhere

<jo> PROPOSED RESOLUTION: Mention the out of scope nature of the details of restructuring under 4.3.6 somewhere (cf insertion of headers, footers etc.)

+1

<francois> +1

<tomhume> +1

RESOLUTION: Mention the out of scope nature of the details of restructuring under 4.3.6 somewhere (cf insertion of headers, footers etc.)

LC-2065: opting-out of CT

francois: Jo replied to Denis

<francois> Bryan's comments on LC-2065

Bryan: intention was to keep it as simple as possible
... 1) original represantation must always be available
... 2) need ability to switch between the representations
... 3) it is useful to remember the user's preference but not essential
... So may be useful to include a section on user control of their preferences

francois: 1 and 2 are covered
... but what we say about 2 could be a bit too generic

jo: Appendix E has some user preferences text

francois: should this be upgraded to a normative statement?

<jo> PROPOSED RESOLUTION: Move content from Appendix E to 4.3.6 somewhere and reword appropriately (and yes, partial to LC-2065)

+1

jo: is 2 practical?

Bryan: yes, we've deployed systems with that capability

jo: but if the content-provider has more than one representation that's more complicated

Bryan: agreed, I meant switch just between CT-proxy transformation and untransformed
... the spirit of the comment is to give the user control over what's happening

jo: so we anticipate there may be preferences persisted but we don't want to mandate it

Bryan: I'm happy with that

<francois> +1

RESOLUTION: Move content from Appendix E to 4.3.6 somewhere and reword appropriately (and yes, partial to LC-2065)

jo: that's 6 comments today!!

francois: it takes time that's for sure