- From: Sean Patterson <SPatterson@Novarra.com>
- Date: Wed, 9 Apr 2008 14:48:12 -0500
- To: "Jo Rabin" <jrabin@mtld.mobi>
- Cc: "public-bpwg-ct" <public-bpwg-ct@w3.org>
- Message-ID: <24889886D84B794A9259323D7354CF3305EE643A@novarrainet2.internalnt.novarra.com>
Apologies for not sending this earlier, but I was out of the office the end of last week and until Tuesday of this week. (Although these comments were written in response to draft 1h, they apply to 1i as well.) Comments about draft 1h: Section 3.1: I'm not sure what the state of 3.1 will be after it is rewritten and integrated into 3.2, but here are some suggestions: * 2.d. states that the CT proxy needs to be able to tell the origin server "that the request headers have been altered (e.g. additional content types inserted)." We might want to change this to something like "the original values of any of the request headers that have been altered" since we have added the X-Device-* headers to section 4.1.4. * Add a new subpoint to point 5: 5.c. to allow the user to specify a preference for either mobile or non-mobile (i.e., desktop) content. Section 3.2.1: In the last paragraph (before the editorial note), another example of a persistent or semi-persistent preference would be "Preference for mobile/non-mobile content". Section 3.2.2: In the editorial note, "...such as [POWDER] to allow origin server to..." should be "origin servers" since the rest of the sentence assumes a plural. Section 4.1.2: In section 3.2.4, it is mentioned that user preferences can expressly override server preferences, so it seems that it would be a good idea to include an additional bullet point in 4.1.2: * any knowledge it has of user preferences (e.g., derived from persistent or semi-persistent preferences or administrative agreements that are in place) Section 4.1.2: Point 2 after "Proxies should not alter HTTP requests unless:" might be clearer if it was specified (or at least examples given) how the user requests "a restructured version of a desktop presentation." Examples would be through persistent or semi-persistent preferences or administrative agreements. Section 4.1.2: For some reason the paragraph: "Knowing that the browser has available a linearization or zoom capability and/or supports a broad range of content formats the proxy should not restructure or recode content." is confusing to me. I can't remember what point we're trying to make here and the sentence doesn't seem to quite make sense. (Maybe I'm just parsing it incorrectly.) Section 4.1.2: In the sentence "If, as a result of carrying out this analysis the proxy remains unaware of the servers preferences...", there should be an apostrophe in servers, i.e. "server's". Also, should we add "user's preferences" to this sentence since we are also taking into account user's preferences? Section 4.2: In the editorial note, in the second sentence, there is reference to the link header. This should instead be the link element. Also, as Francois noted, there needs to be a space between "Link" and "HTTP" toward the end of the second sentence (this wasn't fixed in version 1i). Section 4.2: In the parenthetical comment in the last paragraph, the first instance of the word "it" should probably be "a server" since the beginning of the sentence refers to "servers" (plural). Section 4.3: The editorial note in this section may not always be true. If a transforming proxy is in non-mobile content mode (because of persistent or semi-persistent preferences or administrative agreements) then the first request the origin server will see may have altered headers (if the CT proxy cannot determine from the request that it is dealing with a mobile site). In that case the transforming proxy will receive a Vary response without having previously received such a response to a request with unaltered headers. Section 4.4: I think that the second paragraph should make it clearer that the heuristics are in the box below. (Right now it mentions the heuristics, but doesn't say where they are.) Section 4.4: I don't know about anyone else, but the first heuristic ("The server has previously shown that it is contextually aware...") seems kind of vague to me. I'm having trouble remembering exactly what we trying to say here. Elaboration or an example may be in order. Section 4.4: The second heuristic ("the Content-Type or other aspects of the response are known to be specific...") mentions one example of a content type and one example of a document type. We could certainly mention more document types and more content types. (I realize that I currently have an uncompleted action on the content type part.) Section 4.4: Minor point: the second heuristic should start with a capital letter since the other two do. (Or alternatively, the third heuristic should not start with a capital letter since semicolons are used to separate the heuristics.) Sean ________________________________ From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Jo Rabin Sent: Thursday, April 03, 2008 11:35 AM To: MWI BPWG Public; public-bpwg-ct Subject: New draft 1h of Content Transformation Guidelines - Candidate for FPWD Please forgive the cross posting. There is now a new draft of the Content Transformation Guidelines [1] available. This draft, or one very similar to it, is the candidate for First Public Working Draft (FPWD) transition request. Although the work of the BPWG CT Task Force has been conducted in public, and each draft has been publically accessible, this transition request represents a formal request for comments from the public at large. The document has been cleaned to allow this to happen, though there are still plenty of editorial comments where the Task Force requests input or has concerns. Please take the time to read this draft, which will be the subject of a resolution to transition to FPWD on the members' call next Thursday (2008-04-10). Thanks Jo [1] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide lines/080403
Received on Wednesday, 9 April 2008 19:48:48 UTC