W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2009

Re: ISSUE-2: What is the mime type of a media fragment? What is its relation with its parent resource?

From: Michael Hausenblas <michael.hausenblas@deri.org>
Date: Tue, 27 Jan 2009 14:36:12 +0000
To: David Singer <singer@apple.com>
CC: Media Fragment <public-media-fragment@w3.org>, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Message-ID: <C5A4CC5C.1496%michael.hausenblas@deri.org>


Dave,


> a) the MIME type of the requested fragment is the
> same as that of the original resource;  yes, that
> might result in one-frame movies, and so on;

Sounds good. Didn't think about this one yet. But how do we technically do
this? I fear I don't understand. Could you be more precisely on this option,
please?

Cheers,
      Michael

-- 
Dr. Michael Hausenblas
DERI - Digital Enterprise Research Institute
National University of Ireland, Lower Dangan,
Galway, Ireland, Europe
Tel. +353 91 495730
http://sw-app.org/about.html


> From: David Singer <singer@apple.com>
> Date: Tue, 27 Jan 2009 15:30:29 +0100
> To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
> Cc: Media Fragment <public-media-fragment@w3.org>
> Subject: Re: ISSUE-2: What is the mime type of a media fragment? What is  its
> relation  with its parent resource?
> Resent-From: <public-media-fragment@w3.org>
> Resent-Date: Tue, 27 Jan 2009 14:32:53 +0000
> 
> 
> At 15:21  +0100 27/01/09, RaphaŽl Troncy wrote:
>> Dear Dave,
>> 
>>> I think this is a confused question.  When a fragment is specified on a URI,
>>> 
>>> http:/www.example.com/silvia.mov#chapter=vienna
>>> 
>>> the user-agent separates the fragment from the
>>> URI and requests the main part of the resource
>>> over HTTP, and then interprets the fragment
>>> locally.  The HTTP server, which gives the MIME
>>> type, is unaware of the fragment.
>> 
>> True, the UA will separate the fragment from the
>> URI. We think of having smart UA that will also
>> take the fragment, and converts it into some
>> additional http headers when making the request
>> to the server. The http server will therefore in
>> this case be aware of the fragment requested,
>> and even can decide to serve just this fragment
>> ... When serving the resource, the server writes
>> in the http header the type of the resource is
>> serving. What should it write when it is serving
>> a single key-frame of a video corresponding to a
>> media fragment request where a single time point
>> has been specified?
> 
> OK, that would be a subject for the HTTP
> extension that allowed this, wouldn't it?  I see
> a few possibilities:
> a) the MIME type of the requested fragment is the
> same as that of the original resource;  yes, that
> might result in one-frame movies, and so on;
> b) the UA can indicate what MIME type(s) it would like in response;
> c) the server can decide;
> d) the specification for the base MIME type could
> be revised [but that way we go mad revising RFCs].
> 
>>> Even if it gets the fragment in the URI GET, it
>>> is (I think) supposed to ignore it.  So the
>>> MIME type of a fragmented resource is the MIME
>>> type of the resource, isn't it?
>> 
>> This is what I would think too. But I would like
>> to get the confirmation, since it is not crystal
>> clear (for me).
>> Best regards.
> 
> Well, let's step into another realm.  Suppose
> that we extend HTTP to allow asking the server to
> extract a piece of a ZIP archive;  it makes some
> (but not much) sense for the server to re-zip
> just that piece.
> 
> 
> Overall, I have to say that the simplest is still (a)...
> --
> David Singer
> Multimedia Standards, Apple Inc.
Received on Tuesday, 27 January 2009 14:36:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT