W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > September 2008

[minutes] CT Call 30 September 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 30 Sep 2008 17:52:16 +0200
Message-ID: <48E24B30.1090100@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

Hi,

The minutes of today's call are available at:
http://www.w3.org/2008/09/30-bpwg-minutes.html

... and copied as text below.

Resolved during the call:
- 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

The "out of scope" section was further defined by the following resolution:
- Mention the out of scope nature of the details of restructuring under 
4.3.6 somewhere (cf insertion of headers, footers etc.)

- 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."

- 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."

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

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

Francois.



30 Sep 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0059.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/09/30-bpwg-irc

Attendees

    Present
           Francois, tomhume, rob, jo, Bryan

    Regrets
           hgerlach, SeanP

    Chair
           francois

    Scribe
           rob

Contents

      * [4]Topics
          1. [5]LC-2090, LC-2091 on headers/footers
          2. [6]LC-2012: clarification of the introduction
          3. [7]LC-2068: on requests that contain Cache-Control:
             no-transform directives
          4. [8]LC-2009, LC-2010, LC-2011: the Link element strikes back
          5. [9]LC-2023: transformation across character sets
          6. [10]LC-2065: opting-out of CT
      * [11]Summary of Action Items
      _________________________________________________________

LC-2090, LC-2091 on headers/footers

    <francois> [12]heiko's comments

      [12] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0038.html

    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> [13]LC-2090

      [13] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2090

    <francois> [14]LC-2091

      [14] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/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> [15]Ping-pong on Link element

      [15] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0027.html

    jo: this needs more discussion

LC-2023: transformation across character sets

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

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

      [16] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0014.html

    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> [17]Bryan's comments on LC-2065

      [17] 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0155.html

    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

Summary of Action Items

    [End of minutes]
Received on Tuesday, 30 September 2008 15:52:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 September 2008 15:52:54 GMT