RE: Content Transformation Guidelines 1l (Rev 12) and Change List

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

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.

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

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

Section 3.1.5.3
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 3.2.3.2.)

Section 3.1.6.1
--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.

Section 3.2.3.2
--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.
--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.

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

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

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.

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

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.

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.


Sean



> -----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
URI
> 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 Friday, 18 July 2008 20:47:49 UTC