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: Fri, 11 Apr 2008 18:10:19 -0500
Message-ID: <24889886D84B794A9259323D7354CF3305F4CC20@novarrainet2.internalnt.novarra.com>
To: "Francois Daoust" <fd@w3.org>
Cc: "public-bpwg-ct" <public-bpwg-ct@w3.org>

Hi Francois,

My comments inline below.

Sean

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: Friday, April 11, 2008 11:04 AM
> To: Sean Patterson
> Cc: public-bpwg-ct
> Subject: 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

I suppose the reason for re-requesting with unaltered headers is similar to the case you mention below--the origin server didn't want to serve up a desktop HTML page so it sent a 406 response with a Via header.  Of course, since the origin server received X-device-* headers with the first request (the one with altered headers), it really doesn't need to do this.


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

You're right--seems unlikely (but possible).  The case I mentioned above seems more likely.


> 
> 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 23:10:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 11 April 2008 23:10:10 GMT