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

Re: New draft 1h of Content Transformation Guidelines - Candidate for FPWD

From: Francois Daoust <fd@w3.org>
Date: Thu, 10 Apr 2008 15:17:36 +0200
Message-ID: <47FE1370.9090507@w3.org>
To: Sean Patterson <SPatterson@Novarra.com>
CC: Jo Rabin <jrabin@mtld.mobi>, public-bpwg-ct <public-bpwg-ct@w3.org>

Thanks Sean!

Yes, good points, I made some comments inline and propose to address 
these points in next calls. Basically, I agree with most of this, save 
the fact that I thought administrative arrangements were out of scope, 
so I would say they fit in 3.2.3 as means that may ascertain the 
preferences of users and servers, but should not be mentioned elsewhere.

One question I wanted to ask (I'll ask during today's call anyway). We 
agreed to push the doc to publication as first public working draft. I 
personally don't see any of these comments as blocking, but are you 
asking that we postpone the publication to address these points?


PS: in Jo's absence, I'll fix the 2-3 syntax errors before moving the 
doc to its published state.

Sean Patterson wrote:
> 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.

We haven't really resolved anything on this. We may want to have the 
CT-proxy add a more direct Warning HTTP header, although that may be 
viewed as redundant info (since the X-Device-* headers already 
indirectly "carry" that info).

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

Merged with 3.2, this probably would be part of the current 3.2.1 
Control by User, where this should be listed as an example.

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

+1. It's a typical example, so we should be explicit about it. Besides, 
we mention it shortly after (in 4.1.2) and that's unclear why it 
suddenly appears there.

> 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)

+1 for the additional bullet point.
-1 to precise the parentheses. As mentioned above, we have yet to 
precise persistent and semi-persistent and administrative are out of 
scope IMO (going to 3.2.3).

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

Same here:
+1 to state things clearer
-1 to precise 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.)

"It wasn't me" ;-)
No idea where that comes from, we certainly can discuss that!

> 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?

Thanks for the typo.
Hmm, actually I wonder if this whole 4.1.2 section may not benefit from 
a bit of tidying up and re-arranging of sentences, to follow the 
supposed reasoning of the proxy and thus link sentences to the different 
bullet points of the beginning of the chapter.

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

I had missed the "header" word, thanks ;-)

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

And in that case, the CT-proxy will just ignore the Vary header I 
suppose (or warn the user that there may be a mobile version of the site 
available). Anyway, that's precisely the problem of that section: hard 
to make it clear with the rest.

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

Yes, I don't know what triggered that boxing, and why there's a box here 
and nowhere else...

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

Yes, we resolved to do that later on, but the whole list has to be 
clarified and re-worked, IMO (and part of it is indeed pending your 
action ;-))

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

Received on Thursday, 10 April 2008 13:13:54 UTC

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