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

Hi Sean,

Well, I think we agree then :-)

Two additional comments I extract for the sake of easy reading:

For 4.1.2
---------
The CT-proxy may send the altered headers first when, for example:
- the user explicitely requested the desktop-oriented version of the 
content as you mention
- the proxy already exchanged with the server on that particular 
resource and knows it needs to send the altered request.
-> both examples should be part of the analysis the proxy should do, and 
sending the unaltered headers first is to occur when the proxy still 
doesn't know what to do after conducting the analysis. It's what the doc 
says, but not clearly enough. I think we can come up with a more logical 
structure for that part, I'll give it a try...



For 4.3
-------
That's precisely why this part needs to be written more clearly. First 
case you mention yields to an infinite loop. Second case makes more 
sense, but the question is: why would that happen? If the user requested 
a desktop-oriented version of the resource, then the CT-proxy should not 
re-issue the request with the original headers. If the CT-proxy based 
its decision to send altered headers on previous interaction with the 
server, it's unlikely the server is suddenly going to change its mind. 
I'm not saying we should remove that text, because it's an important 
exception to the rule (and flexibility for the content provider is 
indeed important here, I think), but rather clarify it. I was looking 
for a more generic case when this may happen if a CT-proxy follows the 
guidelines, and can't really find any.

There could be a case when:
1. the CT-proxy determines the server has no media-specific version of a 
page (request rejected) and so sends the second request with the altered 
headers.
2. the returned page links to an image.
3. the CT-proxy requests this image with the altered headers for 
consistency reasons.
4. the server actually has media-specific versions of the image, and 
replies with a Vary.
5. the CT-proxy sees the Vary header and re-issues the original request 
to get the media-specific image.
-> I'm not so sure that's a common practice.


François.



Sean Patterson wrote:
> Hi Francois,
> 
> Some additional comments/responses inline below.
> 
> 
> Sean
> 
>> -----Original Message-----
>> From: Francois Daoust [mailto:fd@w3.org]
>> Sent: Thursday, April 10, 2008 8:18 AM
>> To: Sean Patterson
>> Cc: Jo Rabin; public-bpwg-ct
>> Subject: Re: New draft 1h of Content Transformation Guidelines - Candidate
>> for FPWD
>>
>> 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?
> 
> It is certainly not my goal to postpone FPWD.  I'm just trying clarify some of the stuff in the document and make sure it is saying what I think it is.  (And hopefully help to improve it and make it easier to understand.)  I assume these things can be discussed and worked on post-FPWD.
> 
> 
>> François.
>>
>> 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).
>>
> 
> Although possibly redundant, I don't think it would hurt to have both the X-Device-* headers and the Warning header in the request.
> 
> 
>>>     * 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.
>> Yes.
>>
>>
>>> 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).
>>
> 
> Re-reading, I agree with your -1 (+1 to your -1 :-) ) since the part in parentheses is basically redundant (already stated in 3.2.1).
> 
> 
>>> 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.
>>
> 
> I guess I wasn't really saying that specific examples of persistent or semi-persistent preferences or administrative agreements were necessary.  I was saying that we could mention that a couple of the ways that the user could request a desktop presentation would be through preferences or administrative agreements with the carrier.
> 
>>> 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.
>>
> 
> Yes, it may need some tidying since there may be some confusion.  One thing that I didn't notice when reading the draft before is that in the last paragraph of 4.1.2 (the one starting with "If, as a result of carrying out this analysis the proxy remains unaware of the server's preferences..."), the bullet points make it look like a request with unaltered headers should always be issued first.  In reality, if the user is looking for non-mobile (desktop) content a request with altered headers will be issued first.
> 
> 
>>> 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).
>> Yes.
>>
>>
>>> 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.
>>
> 
> That's not how I read 4.3.  To me the non-editorial note part of 4.3 only makes sense if the altered headers were sent first (presumably because non-mobile content is desired or the proxy knows from previous dealings with the server that there is no mobile content to be had).  So the unaltered headers are sent in response the Vary header.
> 
> It wouldn't make sense to re-issue a request with unaltered headers after receiving a response with a Vary header if the second request has altered headers.  That would mean we are advocating the following:
> 
> Request with unaltered headers
> Response with 406 (for example)
> Request with altered headers
> Response with Vary header
> Request with unaltered headers
> Response sent to client (why wouldn't it be another 406?)
> 
> The following makes more sense (and is what I think section 4.3 is saying):
> 
> Request with altered headers
> Response with Vary header
> Request with unaltered headers
> Response sent to client
> 
> One could argue that the X-device-* headers make the response with the Vary header unnecessary here (since the origin server could figure out what the unaltered headers were from looking at the X-device-* headers), but maybe we are going for flexibility here and we want to give the origin server a couple of options for acquiring the unaltered headers.  (Is that the case?)
> 
> 
>>> 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.)
>>>
>> Yes.
> 
> 

Received on Friday, 11 April 2008 16:04:12 UTC