BPWG Content Transformation Task Force Teleconference -- 4 Dec 2007

<jo> Date: 2007-12-04

<jo> Scribe: Jo

HTTP Liaison

-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Dec/0000.html agenda

Jo: I dropped Mark Nottingham a note but no response yet
... dom suggested someone in W3C which I will follow up

Leader

Jo: still no volunteers - I _really_ don't have time to do this!

Magnus: I think you should carry on Jo

jo: :-(

Draft 1b

-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/071124 Draft 1b

Magnus: Stand by what I said last week to wit that Chap 2 is a little dry and needs some examples etc.

jo: I think we discussed that we'd want to extend HTTP Cache-Control to allow gradations of no-transform
... OK I don't know that we are ready to RESOLVE this
... let's put this to one side for now and look at the requirements

[Heiko joins call and introduces himself]

-> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/071124#Requirements REquirements Section

<Magnus> Example text for 2.1.1: Some CT proxy implementations may allow end-users to select personal preferences. For example, a CT proxy may allow a user to replace all embedded images with thumbnails.

jo: at 2.1 enable service features - need clarification of what service features means

andrew: select adaptation or not

jo: not sure that we are going to offer such a feature

magnus: sure, but this is an example of how it may be elaborated to ease the flow of reading

jo: service features probably means gradation of trancoding features
... 2.1.2 "highest quality representation" - this is subjective? no?

andrew: highest resolution?

seanp: what he is getting at is to exploit device capabilities rather than go for an LCD approach

heiko: need to set the bar as to whether this is a high tier or low tier which will vary
... need to decide whether to go for marketing or technical approcah
... not just rely on device capabilities
... is a mobile phone capable of rendering the content or not, sometimes this is to do with user experience and that is a marketing issue

<matt> ScribeNick: Matt

Jo: Yes, that's probably right, but I think the exact nature of how a transforming proxy lays things out is a different issue than say what Sean has construed it as. (?)
... In 2.1.2, we're saying if a device has capabilities that you can exploit that you should exploit them when you are transforming things.

s/magnus: what/sean: What/

Jo: 2.1.2 "compatible" results in a usable experience. In reflowing this text, I would construe compatible and usable to mean in terms of the DI glossary a "functional experience" -- the user can perceive what the author intended. (vs. a harmonized user experience.)

heiko: We use 'use case completion rate', a number of use cases that must be completed...

Jo: Yes, that's an interesting formalization. How would we get at that in this document? What we're looking for is something that probably doesn't have usecases as such.

heiko: In general you have a use case for any page, any time the user is accessing the page via content-adaptation that the user must be able to complete the use case for that page.

Jo: Yes, that makes sense, except that we have no control over the use cases. We have practically unlimited content -- that is, the Web. I don't think we are intending to write use cases here.
... Any suggestions for scoping as suggested by this sentence?

<jo> s/https/https or POSTs

heiko: Regarding 2.1.2, the 'highest quality' -- we're never going to give the highest quality, we have to reduce the image size for instance. In the end we're looking for the best on the phone. Never the highest quality.

Andrew: I take your point, but we should differentiate between optimization (speeding delivery) and content transformation (enabling pages designed for a large screen to be presented on a small screen device).

heiko: Did we define content somewhere before? Maybe this is required somewhere.

Andrew: In my view it's an important differentiation.

Jo: That's not necessarily the case in my view -- that's the heart of why we need relaxation on no-transform.

<jo> [note to change highest quality -> functional user experience]

Magnus: I agree with Heiko, in 2.1.2 it needs to be scoped out for different types of content. For example, image type makes perfect sense to deliver highest quality. Markup itself, we might want to reduce it in size for instance.

Heiko: Nevertheless, we should compress images.

<scribe> ACTION: Magnus to suggest some text for 2.1.2 [recorded in http://www.w3.org/2007/12/04-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-605 - Suggest some text for 2.1.2 [on Magnus Lönnroth - due 2007-12-11].

Jo: 2.1.3 CT-Awareness.

Heiko: What does CT awareness in browsers mean?

Jo: A browser can make it known to a CT proxy that it is capable of using the guidelines specified in this document.
... i.e. it knows how to do or not do things.
... I'm not sure this is a requirement, but let's leave it in for the time being.
... 2.1.4, user agent id and capabilities disclosure.

Heiko: If we are asking the user to configure the user for it's needs, then we don't need our solution. The user will always be able to solve "how would you like it?" -- if we have a tool it should work without user interaction.

Jo: I think Bryan is saying 'MAY'

Andrew: I agree with Heiko, we don't want to push all the decisions to the user. What we're talking about here might be more of a made-for-mobile page vs a desktop page and you might want to give a choice. The majority of the cases the page will be made for one device or another and the CT can be automatically applied.

SeanP: I took the 2.1.4 statement to mean that the user can tell the CT Proxy whether they want the desktop or mobile version.

Jo: That's not really what it says though here, is it? I think what Bryan is saying that the user can choose to either have the original user agent disclosed or not.

SeanP: Yes, it does mention user-agent. I was thinking more of the capabilities part, but yes...

Jo: There is a difference between the capabilities of the user-agent and the representation you're going to get.
... Because it's a mobile browser it doesn't mean you always want a mobile presentation, that's not strongly related to the user-agent (except that we know if the user-agent is capable of rendering a desktop representation). I don't think the text is representing that clearly.
... Perhaps a note saying we must be able to make a distinction between what the user wants and forcing a mobile presentation.
... 2.1.5 original representation availability

Heiko: If you are caching the CP response, it may already be depending on the user-agent, so maybe the response is not related when you resend the request. (?)

Jo: I don't think that's what this is saying.
... I think it's just saying if you've done some work on it, you should hang on to it, presumably in case it's required later. But I think I find this section questionable. I'm not sure why this is necessary.

Heiko: When the user goes to some portal and buys the wallpaper for instance. We optimize the wallpaper size, then he'll never have the wallpaper in the resolution he likes, so he must be able to request the original wallpaper.

Jo: Right, but what is missing from this is a mechanism for re-requesting.

Heiko: Well, if you have a one-time URL, it'll be expired...

Jo: For this to be viable I'd have to have a mechanism for "I requested this from you, please give me the original" -- which isn't in HTTP.

Heiko: Today it's done with a reload request.
... If the user hits reload it sends the original content.

Jo: This is achieved by the browser sending a cache-control: no request, right?

Heiko: The second time it must cache the original response.

<scribe> ACTION: Heiko to detail reload re: section 2.1.5 original representation availability [recorded in http://www.w3.org/2007/12/04-bpwg-minutes.html#action02]

<trackbot-ng> Created ACTION-606 - Detail reload re: section 2.1.5 original representation availability [on Heiko Gerlach - due 2007-12-11].

<jo> ACTION: Heiko to detail what he means by "reload" request on mailing list [recorded in http://www.w3.org/2007/12/04-bpwg-minutes.html#action03]

<trackbot-ng> Created ACTION-607 - Detail what he means by \"reload\" request on mailing list [on Heiko Gerlach - due 2007-12-11].

SeanP: I think we could combine 2.1.4 and 2.1.5 so the user could change their preferences, and re-request the document and get the original representation.
... But is that something we want to cover in the document?

Jo: I think it's getting a bit elaborate.
... I think what bothers me is that the proxy has to keep the original representation for some amount of time... there's a lot of complexity in there that we probably won't be able to address at this level.
... The wallpaper case could be handled by having the host know that this shouldn't be reformatted.
... Was hoping to not get into complex protocols...

SeanP: Agreed.

Jo: Let's each send detailed comments to the list on the remaining portions of section 2.

<scribe> ACTION: All to read and send detailed comments to the list on the remaining portions of section 2. [recorded in http://www.w3.org/2007/12/04-bpwg-minutes.html#action04]

<trackbot-ng> Sorry, couldn't find user - All

Jo: Adjourned.

<hgerlach> thanks, bye

<jo> Scribe: Jo, Matt

- DRAFT -

BPWG Content Transformation Task Force Teleconference

4 Dec 2007

Attendees

Contents

HTTP Liaison

Leader

Draft 1b

Summary of Action Items

Scribe.perl diagnostic output