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

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

From: Sean Patterson <SPatterson@Novarra.com>
Date: Wed, 9 Apr 2008 14:48:12 -0500
Message-ID: <24889886D84B794A9259323D7354CF3305EE643A@novarrainet2.internalnt.novarra.com>
To: "Jo Rabin" <jrabin@mtld.mobi>
Cc: "public-bpwg-ct" <public-bpwg-ct@w3.org>
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
*	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.)





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







Received on Wednesday, 9 April 2008 19:48:48 UTC

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