Re: Review of section 7

Dear Silvia,

> Section 7
> 
> * Second paragraph: remove "n" in "an" of "an Web application"

done.

> Section 7.1
> 
> * proposal to rename to "1-step GET request"

Use now: Single-step partial GET

> * it might make sense to put an "aim" into the alternatives; this
> section would have an aim of "allowing a single roundtrip media
> fragment resource delivery"

I rather see these 2 sections as recipes, i.e. technical descriptions of 
the two foreseen solutions. But, yes, later on, it should be completed 
by a chapeau.

> * we need to mention that the replies are not cachable for the full
> resource, but cache only the fragmented resource, which can result in
> n copies of some subset of the resource in caching web proxies. Since
> it is typically expected that a fragment request will be used
> repeatedly (e.g. a fragment URI being shared around), this is
> potentially acceptable. But we have no experimental data to confirm or
> deny that this may pose a challenge to caching web proxies.

The section 7.3, discussion is meant to contains such information. Is 
that not captured yet?

> * further we need to mention that there are encapsulation formats
> (such as MP4) that have an index in their headers that can provide a
> seconds->byte mapping for any offset. For such cases, an optimisation
> is possible where a client retrieves the index part of the media file
> first and then uses that to make byte range requests rather than time
> range requests. These requests are cachable by any caching Web proxy
> without replication for differing fragment requests. This is in fact a
> third means of retrieving fragment URIs, which we might want to make
> explicit as a section 7.3.

Yes, this is what it is written (in a one line summary :-) in 7.3, point 
3 of the pros.

> * further I think we should remove the current section 7.3 and put at
> the end of section 7.1 and section 7.2 the advantages and
> disadvantages of that particular approach. I think that makes it a
> fairer assessment of the alternatives.

Hum, maybe yes later on, i.e. when we will have feedback on the various 
proposals. I think for now, it is better to have a very brief technical 
description of the solutions, and then let the reader think of each of 
them, and perhaps bring more pro and cons of each solutions that we 
would not have thing of ...

> Section 7.2
> 
> Even though this section is taking a different approach to temporal
> URIs, it still follows the basic principles of temporal URIs (as
> described in http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html#anchor6).
> I therefore have some change requests to this section, since it is not
> quite consistent as it is.

Should we put a reference here to the temporal URIs spec?

> * proposal to rename to "2-step GET request"

Use now: Dual-step partial GET

> * it might make sense to put an "aim" into the alternatives; this
> section would have an aim of "allowing reuse of existing byte range
> based URI fragment caching methodology for media fragments in caching
> web proxies"

See above.

> * (minor issue:) paragraph 3 (starting with "Origin Server
> converts..." needs an "s" at the end of "puts" in "and put all header
> data...".

done.

> * third example box says: "should it be a '204 No Content' response?"
> - no that response would be wrong because there is typically actual
> content in this response, which consists of the adapted headers (the
> control section) of the encapsulation format.

indeed, I have removed that.

> * The section from Origin-Server -> Proxy(4) -> UA (5) probably does
> not work in the way that it is outlined here.
>   - If the Origin-Server returns a "200 OK" and no other header that
> indicates that the client has to do another request, the client has to
> assume that the retrieval action is finished. So, we need to add some
> further request and response headers
>   - In temporal URI, we firstly created an additional request header
> called "X-Accept-Range-Redirect" which indicates to the server that it
> is to do a range resolution and a redirect.

Thanks, this is the review I was expected :-)
[snip]

>     Example:
>     HTTP/1.1 200 OK
>     Date: Fri Feb 11 14:47:12 EST 2005
>     Server: Apache/2.0(Unix)
>     Content-Type: video/mp4
>     Location: http://example.com/fragf2f.mp4
>     X-Range-Redirect: bytes=1113724-2082711
>     Vary: X-Accept-Range-Redirect
>     X-Accept-TimeURI: npt, smpte-25
>     Message body: control section of fragf2f.mp4#12,21 (if required)

I have modified both:
   - http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation and
   - http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/
Could you please check it is right now?

> * the rest of the transaction works the way in which it is outlined;
> however, the image has a problem since the response code of the second
> response is "200 OK" in the image, but "206 Partial Content" in the
> example, which is correct.

Image corrected.

> Section 7.3
> 
> * as mentioned above, I would like to suggest to move all the details
> of section 7.3 into section 7.1 and 7.2 and have
> advantages/disadvantages for each approach separately.

I agree that the section 7.3 is completely messy currently, but I would 
say, almost purposely :-) I would rather prefer have for now, two short 
technical descriptions of each solution and let the reader see what he 
thinks of each.

> * can somebody clarify why "2-way handshake allows to extract a
> spatial region from a Motion JPEG2000" while 4-way does not? I don't
> understand the reasoning behind this.

Does 
http://lists.w3.org/Archives/Public/public-media-fragment/2009Mar/0055.html 
(and the whole thread) satisfy you?

> * can somebody clairfy why "2-way handshake achieves what we want
> without needing HTTP protocol extension"? I think that both, 2-way and
> 4-way require a protocol extension - at minimum they require the
> creation of new range types.

I think it meant that, yes, we need to create new range unit, but no new 
headers in the case of the single-step partial GET.

> Also, I would suggest creating
> Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and Accept-NameURI
> headers such that the server can indicate to the client whether it is
> indeed capable of returning fragments and which type. (we could
> certainly turn this into a singe "Accept-FragmentURI:
> time,space,track,name" header, but then we cannot communicate which
> types of headers are supported).

Thanks for this suggestion: I put it on the agenda for the f2f meeting, 
first slot hour when we will discuss the single-step and dual-step 
partial GET (aka, 2-ways, 4-ways handshakes :-)

> Section 7.3, third paragraph (starting "Using HTTP byte ranges...")
> 
> I do not understand this paragraph and I think it is fundamentally
> wrong. I think there is a misunderstanding for the 4-way handshake
> between how to handle the control section that is non-cachable and
> transferred in the first GET action, and how to handle the data
> section which is transferred in the second GET action. All the data
> that is transferred in the second GET action is simply a byte range
> request on the original resource, which means it can be stored in the
> exact same way in which existing caching Web proxies store byte range
> requests, so there is no extra implementation cost. The control
> section is generally small and is returned with the first GET action.
> Indeed, there are not an infinite number of resources created in this
> way, but exactly only one in the proxies. This is a big advantage of
> the 4-way handshake and not a disadvantage.
> 
> Of course the whole idea of caching and reducing bandwidth use falls
> down when we need to transcode media resources. Those are never
> cachable other than for the exact same fragment URI. For those, the
> 2-way handshake is probably more appropriate.

Hum, I think the paragraph in the document says the same thing than your 
  explanation above, or at least, I don't see the contradiction. But I 
acknowledge as well that the whole story of caching these media 
fragments and the exact role of the proxies is still heavily discussed 
within the group. I would suggest to wait for our discussion during the 
next f2f meeting before doing more changes.

> OK, I hope I was able to explain myself well enough. I know I have
> made some change requests that may be quite substantial - this will
> make for good input to the F2F, I guess. :-) Not sure it can be
> attacked before the planned WD release on Tuesday...

Thanks for this discussion :-)

   Raphaël

-- 
Raphaël Troncy
CWI (Centre for Mathematics and Computer Science),
Science Park 123, 1098 XG Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/

Received on Tuesday, 14 April 2009 12:27:10 UTC