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

Content Transformation Guidelines 1m (Rev 13) [was Re: Content Transformation Guidelines 1l (Rev 12) and Change List]

From: Jo Rabin <jrabin@mtld.mobi>
Date: Tue, 22 Jul 2008 18:00:48 +0100
Message-ID: <48861240.5060301@mtld.mobi>
To: public-bpwg-ct <public-bpwg-ct@w3.org>


I started this draft [1] in the hope of having it ready for today's 
meeting, but in the event was not able to. The following update notes 
are based around Sean's notes some typos and clarification I spotted.

I've also added notes regarding changes arising from today's meeting and 
last week's too. Read below for the full and gory details.


Diffs are linked from within the document.

@@TODO - Add examples [that means YOU!]
@@TODO - Conformance Statement [Francois, please? pretty please?]
@@TODO - Final references for BP Guidelines and mobileOK
@@TODO - Anything else that you spot and that I have missed :-(


On 18/07/2008 21:47, Sean Patterson wrote:
> Comments on the draft 1l:
> Section 2.1:
> --Bracket and quote nesting problem.  In the definition of
> non-transparent proxy, there is a left bracket ([) followed later by a
> double quote.  However, the closing right bracket (]) appears before the
> closing double quote.  I'm assuming that the closing double quote should
> actually appear right immediately before the closing right
> bracket--right after "anonymity filtering."
Yes, it's a mess. I'll do something about sorting out the mess that
XMLSpec's default <termdef> leaves in its wake.

> Section 3.1.3
> --Missing right parenthesis after "see 3.1.2 no-transform directive in
> Request".

> Section 3.1.4
> --Response to the editorial note:  For responses that are paginated, the
> CT proxy will need to cache the response for a finite amount of time in
> order to be able to return subsequent sections of a paginated Web page,
> even for no-cache responses or responses the expire very quickly.
OK - as discussed on today's call.

> Section 3.1.5
> --Missing right parenthesis at the end of item 1.

> Section
> --In the second paragraph, "A proxy must not issue a POST/PUT..." should
> be "A proxy must not *reissue* a POST/PUT...".

> Section
> In response to the editorial note:  Isn't it good enough for the origin
> server to include the Cache-Control: no-transform header when the origin
> server wants to make sure that client receives the origin server's
> choice of representation?  (As mentioned in section
Yes, I think it is, on reflection. And as resolved today.

> Section
> --The word "should" in the first sentence should be in bold.

> Section 3.2.2
> --I agree with the suggestion in the editorial note that the note about
> the META HTTP-Equiv element should be moved to an appendix.  It doesn't
> really seem to fit here and since there is no explanation of why META
> HTTP-Equiv might be necessary, readers might be scratching their heads
> about this note.
Following discussion today, which resolved to move it to an appendix, I 
actually didn't do that I left it in under Proxy Forwarding of Response 
seems like more of the right kind of place for it to be, on reflection.
> Section
> --I had a bit of trouble comprehending the bullet list in this section
> because the sentence introducing the list seems to indicate that both
> bullets will be about LINK elements that refer to the representation of
> the page containing the LINK element(s).  In reality the second bullet
> is about representations other than the current representation.  Maybe
> this section could be improved by removing the bullet list and combining
> the introductory sentence and the first bullet into one paragraph and
> the second bullet into another paragraph (with some additional
> introductory text such as "To indicate additional available
> representations of the HTML content, [bullet 2 text]").  Seems like a
> small point, but I think this would make this section easier to
> understand.
Good idea, done, tks

> --I was going to suggest that there should be some examples of what the
> LINK elements would look like, but it looks like those will be covered
> in an appendix.  This is a good idea since it may not be immediately
> obvious how these LINK elements should look.  References to the relevant
> W3C recommendations (or a glossary at least) might also be in order for
> the definitions of fragment identifiers and media types.
good point, RFC 3986 is the reference in question.

> Section 3.3.4
> --In this section, it is stated that if a request from the CT proxy is
> made with altered headers and the origin server responds with a Vary
> header referring to one of the altered headers, unaltered headers should
> *always* be presented first on subsequent requests for this resource.  I
> don't think it is out of the realm of possibility that a lower traffic
> web site (for example) might create a mobile version of its site then
> determine that it is too much work for the amount of traffic received.
> Such a site might then just start sending back a 406 for all mobile
> requests.  The restriction of "always" means that heuristics of section
> can no longer be used to allow the CT proxy to send altered
> headers first even thought the CT proxy is going to send a 406 every
> time.  A statement that unaltered headers should be sent first unless
> the server modifies its behavior to no longer handle the unaltered
> headers would be a good idea here.
OK so I altered this hopefully to suit.

> Section 3.3.5
> --For consistency reasons, "SHOULD" should be lowercase and in bold.
thanks, done

> Section 3.3.6
> --The third bullet could use some improved formatting to make it easier
> to read.  Perhaps as a list.  Did we resolve to remove examples of
> content types?  Seems odd that we list several DOCTYPE examples but no
> content type examples.
OK have reformatted
ref content-type as discussed today.
> Section B.1
> --As mentioned by someone else (I can't remember whom), we should
> replace "bogus" by "unacceptable" since we haven't defined "bogus."
fair enough.

As discussed today, we need contributions to these examples.

> Section D.5
> --In response to the editorial note:  The last sentence makes more sense
> if you change "recoding" to "recording".  I am assuming that this
> sentence is referring to the fact that we had to resort to X-headers to
> send the original headers to the origin server.
yes, you are right. Clearly needs re-wording if the editor can't make
head or tail of it. Have tried new wording

> General comment:
> --I still think there should be some mention of how users can make their
> preferences known to the CT server.  Perhaps a non-normative appendix
> that mentions the stuff in the old 3.2.1 and 3.2.3 sections as examples
> of how a user would specify his/her preferences.

I've offered some text in a new Appendix.

> Sean
 From Today's Agenda/Call

1. Appendix B: Example Transformation Interactions
Awaiting examples

2. CT and direct choice of user experience

per above, dropped

3. HTTPS link re-writing
Note added per above

4. No mention of Content-Types in 3.3.6
reworded per above

5. meta http-equiv note in 3.2.2

removed from Server actions, retained in Proxy Actions, not added as a 
note in a non normative appendix - as described above

6. Pagination and caching directives

Text amended per above

7. Link element section structure (

reworded per above

8. Receipt of Vary HTTP header (3.3.4)

reworded per above

9. Typo fixes

per above

10. Allow/Disallow lists

PROPOSED RESOLUTION: allow/disallow lists fit in "heuristics of various
kinds" in Do not mention allow/disallow lists explicitly on the
grounds that we do not want to prescribe how a CT-proxy works internally.

No mention added. New Appendix on Admin Arrangements has some bearing 
on this.

11. Persistent expression of user preferences

PROPOSED RESOLUTION: mention Administrative arrangements as out of scope
in a non-normative appendix


 From minutes of 15th July

Resolution taken:
- Remove Caveat on WML from scoping statement (it appears further down 
in the document)


>> -----Original Message-----
>> From: public-bpwg-ct-request@w3.org
> [mailto:public-bpwg-ct-request@w3.org]
>> On Behalf Of Jo Rabin
>> Sent: Friday, July 11, 2008 5:36 PM
>> To: public-bpwg-ct
>> Subject: Content Transformation Guidelines 1l (Rev 12) and Change List
>> Please find Draft 1l at [1]
>> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
>> drafts/Guidelines/080712
>> I haven't linked to a diff as the changes are very extensive.
>> This draft is not as polished as I would have liked, but it is more or
>> less there. Some links missing and undoubtedly some typos, but I have
>> run out of time and wanted to get this out in good time for Tuesday's
>> meeting.
>> I hope to be able to attend that meeting but I'm afraid I am not sure
>> yet exactly what my availability is.
>> Extensive notes of things done follows.
>> Cheers
>> Jo
>> Changes to draft 1l
>> Section numbers per draft 1k
>> 1. In response to Sean's comments [1]
>> [1]
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0018.html
>> Editorial changes to 1.3, 2.1. Sean's comments on 4.4 overtaken by
> events.
>> 2. Minutes of CT Call 10 June:
>> a. Normative ... the document is to become normative so the section on
>> RFC2119 has changed.
>> b. Proxy vendors to determine when a 200 response is really a 406 -
>> editorial note removed, existing Note stands but remains silent on how
>> to detect. Overtaken by subsequent events in large part in any case.
>> c. Drop editorial note at end of 4.3
>> 3.
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0023.html
>> CT Namespace
>> a. Edited to become  http://www.w3.org/ns/ct
>> 4 http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0025.html
>> Insert new section on applicability to solutions that are not in
> scope.
>> 5. Remove section 4.3 and rewrite its contents to fit under 4.2 and
> 4.4
>> 6. ACTION-732 HTTPS link re-writing
>> 7. ACTION-766 Note on X-Device
>> 8. ACTION-770 semi-persistent (section has been restructured anyway)
>> 9. Resolutions from F2F
>> RESOLUTION: Restart rechartering process now, where the only changes:
>> would be the informative to normative change for this doc, as well as
>> extend the WG, 6 months into 2009
>> reword section on rfc2119, reword caveat text to refer to a proposed
>> normative Recommendation.
>> RESOLUTION: a Link header/element with media type of handheld and a
>> referring to a location within the resource indicates that the current
>> representation of the resource is intended for handheld presentation
>> RESOLUTION: Make the point explicitly in the document that an href
> which
>> refers to this resource but which does not have a fragment identifier
> on
>> a link header/element means that this resource is capable of being
>> rendered in a way that is suitable for handheld presentation, but that
>> without the above link element there is a question as to whether this
>> representation is or is not...
>>      RESOLUTION: Make the point explicitly in the document that an
> href
>>      which refers to this resource but which does not have a fragment
>>      identifier on a link header/element means that this reource is
>>      capable of being rendered in a way that is suitable for handheld
>>      presentation, but that without the above link element there is a
>>      question as to whether this representation is or is not...
>> RESOLUTION: Regarding ISSUE-261, adopt Jo's proposal for a process
>>      for a process for CT bogus 200 response detection (4.1.2) and
> close
>>      ISSUE-261.
>> ACTION-777 - Edit 4.1.2 according to above resolution
>> [as an illustrative appendix]
>> RESOLUTION: Adopt Jo's wording for 4.1.2 of the CT document (pending
>>      some editorial "tweaking")
>> ACTION-778 - Add the stuff on possible use of
>>      OPTIONS to the appendix
>> ACTION-779 - Transcribe points 7 8 9 and 11 of
>>      ISSUE-223 into Scope for future work
>> [done except for the stuff on DPE]
>> ACTION-780 - Add text to section 4.4 referencing
>>      above resolution on mobikeOK
>> RESOLUTION: Close ISSUE-243 and mention this topic in the appendix
>>      as scope for future work.
>> RESOLUTION: For CT guidelines, for included resources within a page,
>>      additional content tasting is not required.
>> RESOLUTION: For CT guidelines, except in the case of https, the
>>      content transformation guidelines document does not differentiate
>>      between URI rewriting and so-called "transparent" proxy
> operation.
>> [not quite sure where to put the above]
>> RESOLUTION: Regarding ISSUE-241, in the CT guidelines we agree that
>>      the proxy does not have to taste every linked resource (for the
> sake
>>      of clarity).
>> RESOLUTION: Regarding ISSUE-241, in the CT guidelines we should
>>      state that when the proxy makes a request for a linked resource
> to a
>>      new "web site", then what's in section 4.1.2 should happen
> (allowing
>>      for different heuristics for determining whether request is to a
>>      different or the same "web site" but giving "hitting a new domain
>>      name" as a good example. And remove the word "session" from the
>>      previous resolution on 4.1.2. And close ISSUE-241.
>> ACTION-781 - Enact changes sugegsted by the
>>      previous 4 resolutions
>> RESOLUTION: re. ISSUE-255, drop mention of examination of URI from
>>      4.1.2 as it's a heuristic to scope rejected 200 responses,
> detailed
>>      in 4.4, and 4.1.2 already precises to examine the response (with
> a
>>      link to 4.4)
>> RESOLUTION: Regarding ISSUE-258, move section 3.1 of CT Guidelines
>>      document into Scope section (and refresh to synchronize with the
>>      rest of the document) moving removed requirements into scope for
>>      future work (and close ISSUE-258).
>> RESOLUTION: On point 12 of ISSUE-223 (whether CT proxies should
> refrain
>> from transforming MobileOK content) we should allow for the
> possibility
>> that CT proxies should be able to transform MobileOK content but that
>> they should take into account MobileOK-ness as part of the heuristics
>> involved in determining whether content is mobile-friendly (but remain
>> silent on how you check if something is mobileOK).
>> [done under heuristics and added bibref]
>> ACTION-782 - Draft text on which aspects of the
>>      CT guidelines should be followed by e.g. Opera Mini
>> RESOLUTION: It is permissible for the proxy to offer the user a
>>      restructured desktop presentation on a 'site' by 'site' basis
>> RESOLUTION: Insert into the document a scoping statement that says
>>      that a proxy is a CT proxy in scope of this document only where
> no
>>      prior arrangement exists between the operator of the proxy and a
>>      content provider. One where an arrangement exists with the
> content
>>      provider is an adaptation solution, is considered to be part of
> the
>>      origin server and is therefore out of scope
>>   RESOLUTION: In the context of tasting content, if header comes back
>>      as cache-control no-transform, then CT proxies SHOULD change to
>>      transparent proxy operation (e.g. sending a http redirect)
>> [not sure where to put the above]
>>   RESOLUTION: If the response includes a Cache-Control: no-transform
>>      directive then the response must remain unaltered other than to
>>      comply with transparent HTTP behavior and other than as follows.
> If
>>      the proxy determines that the resource as currently represented
> is
>>      likely to cause serious mis-operation of the user agent then it
> may
>>      advise the user that this is the case and must .provide the
> option
>>      for the user to continue with unaltered content.
>>    RESOLUTION: If the server has alternative representations then it
>>      should indicate this using link header/elements
Received on Tuesday, 22 July 2008 17:01:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC