o discuss Yves's proposal: a GET of the media header (so a few bytes, depending on how much is enough), and the server answers with that + one or more Link: headers linking to different mappings (time to bytes is an example) or at least a resolver URI, linking to the sub-resource, to parent etc...

08:24:14 [raphael]

o discuss the pro/cons of each solution

08:24:16 [raphael]

* check with the evolving link header draft;

08:24:19 [raphael]

* Yves: present the clarifications of HTTPBis.

08:24:20 [dsinger]

I have detailed comments, I'll try to get them to the group over these two days

in rfc2616, the text was open to new units, but without any way of doing it, in httpbis it has been clarified

10:09:46 [raphael]

Yves: summary, we understand the concern of Conrad: single step partial GET, with a 206 response works, but it is not cachable

10:09:53 [raphael]

... which we know, written in 7.3 !

10:10:08 [mhausenblas]

Michael: are we seeking a trade-of between cachability and round-trip?

10:10:09 [silvia]

in current web proxies not cachable

10:10:13 [mhausenblas]

jackjansen: yes

10:10:16 [mhausenblas]

Conrad: no

10:12:50 [mhausenblas]

jackjansen: let' ignore the No-Cache for now, different issue

10:12:51 [Yves]

things we can add is a header in the reply indicating where D2 is and its relationship to bytes in the original file

10:14:00 [silvia]

I agree with the addition of such a header

10:15:56 [mhausenblas]

jackjansen: we should optimise for the case where a URI is embedded in an Web page

10:18:30 [mhausenblas]

silvia: for example in youtube case, each time you click on a time-offset it's a different URI

10:18:59 [mhausenblas]

jackjansen: do I understand correctly: every time I click on it I get a new URI?

10:19:02 [mhausenblas]

silvia: yes

10:19:58 [mhausenblas]

raphael: let's move on

10:20:19 [mhausenblas]

... we seem to agree on the one-step process but the cachable part

10:21:17 [silvia]

in the YouTube case there is a special server and a proprietary client - we cannot really tell what is going on; but when you click on an offset, a new connection is opened and new buffering is started

10:22:46 [mhausenblas]

jackjansen: a super-clever proxy would cache the entire bits and handle the parts accordingly

10:23:12 [Yves]

and a not so clever proxy could return the same content when the same second range is requested

10:23:22 [raphael]

yes Yves

10:23:41 [Yves]

'second' or 'other unit then bytes'

10:23:47 [raphael]

Conrad would like to move on the 4-ways handshake

10:24:13 [Yves]

but ading a mapping header in the reply (if possible would be a good thing, and only 'informative', so nothing mandatory to implement on the receiving end

Silvia: can we modify the current draft and enhance it with Conrad's proposal?

10:45:58 [mhausenblas]

raphael: still need to understand better

10:46:45 [philipj]

is the proposal to allow either or both of these methods?

10:47:32 [philipj]

conrad's single and dual step GET

10:48:47 [silvia]

IIUC the one-step GET is preferrable, but it doesn't work with existing Web proxy caching infrastructure other than by keeping multiple copies; the two-step GET is for making media fragment URIs work with existing caching Web proxies