- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 09 Jul 2010 09:42:01 +0200
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Yves Lafon" <ylafon@w3.org>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, public-media-fragment@w3.org
On Thu, 08 Jul 2010 18:20:04 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Thu, Jul 8, 2010 at 1:54 AM, Philip Jägenstedt <philipj@opera.com> > wrote: >> On Wed, 07 Jul 2010 23:31:29 +0200, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >> >>> On Wed, Jul 7, 2010 at 7:30 AM, Philip Jägenstedt <philipj@opera.com> >>> wrote: >>>> >>>> On Wed, 07 Jul 2010 16:19:31 +0200, Yves Lafon <ylafon@w3.org> wrote: >>>> >>>>> On Wed, 7 Jul 2010, Silvia Pfeiffer wrote: >>>>> >>>>>> I would agree to this analysis: #foo=bar is not a valid MF >>>>>> *dimension*. It is, however, a valid media fragment URI, since a >>>>>> media >>>>>> fragment URI is given as a URI on a media resource that has a >>>>>> fragment >>>>>> specified and we specify fragment through name-value pairs. The >>>>> >>>>> You can only know it's a media resource when you dereference it. >>>>> http://www.example.com/map#lat=-16.5&long=-151.7 is a valid Media >>>>> Fragment, but it may be a fragment indicating a point in a map (for >>>>> example, >>>>> it might even be something else). >>>> >>>> How is this relevant for unknown name-value pairs specifically? #t=10 >>>> could >>>> also be used on non-media resources [1]. A browser could simply not >>>> parse >>>> and handle the fragment component until after making sure that it's >>>> dealing >>>> with a whitelisted MIME type. (In practice I think that amounts to >>>> only >>>> considering MF when used together with <audio>, <video> or when >>>> directing >>>> the browser directly to a media resource.) >>>> >>>> [1] strictly speaking: resources with a MIME type that hasn't opted >>>> in to >>>> MF >>>> in its RFC >>> >>> >>> Maybe we can introduce the notion of URI fragment dimensions. Then we >>> can say that every resource can have several URI fragment dimensions. >>> The dimensions are then analysed wrt the mime type of the media >>> resource, which the UA has to determine first, e.g. through a head >>> request or something. At this point, it can be decided if a dimension >>> is recognized wrt a resource of a certain mime type and dimensions >>> that are not recognized are ignored. >> >> That sounds just about like what I had intended, although I don't think >> there's any need to do a head request. No matter what the beginning of >> the >> file will be needed to set up the decoding pipeline, and together with >> that >> data we also get the MIME type. >> >> It should be noted though, that in practice I doubt any implementation >> is >> going to wait for updated MIME registrations references MF before >> implementing this. > > I would hope they don't wait! But the point of finding out the MIME > type is to find out whether it's a video or audio type that their > application supports. Not really to check the MIME registration > document. ;-) Yes, the MIME type is already checked for <audio> and <video>. -- Philip Jägenstedt Core Developer Opera Software
Received on Friday, 9 July 2010 07:42:42 UTC