Re: ISSUE-3: Does our MF URI syntax imply that we need to update MIME Type registrations?

Thanks a lot Silvia. Took your wording more or less verbatim. Please, all
see the proposed wording at [1] and hence claiming that my action [2]
('draft', right ;) is done.

Cheers,
      Michael

[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/Semantics
[2] http://www.w3.org/2009/01/28-mediafrag-minutes.html#action04

-- 
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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> Date: Thu, 29 Jan 2009 05:59:29 +1100
> To: Raphaël Troncy <Raphael.Troncy@cwi.nl>
> Cc: Media Fragment <public-media-fragment@w3.org>
> Subject: Re: ISSUE-3: Does our MF URI syntax imply that we need to update MIME
> Type registrations?
> Resent-From: <public-media-fragment@w3.org>
> Resent-Date: Wed, 28 Jan 2009 19:00:08 +0000
> 
> 
> On Thu, Jan 29, 2009 at 12:47 AM, Raphaël Troncy <Raphael.Troncy@cwi.nl>
> wrote:
>> 
>> ISSUE-3: Does our MF URI syntax imply that we need to update MIME Type
>> registrations?
>> 
>> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/3
>> Raised by: Michael Hausenblas
>> 
>> In [1] Michael argued that whenever we talk about URI semantics, we need to
>> start with RFC3986 section 3.5:
>> 
>> 'The semantics of a fragment identifier are defined by the set of
>> representations that might result from a retrieval action on the primary
>> resource. The fragment's format and resolution is therefore dependent on the
>> media type [RFC2046] of a potentially retrieved representation, even
>> though such a retrieval is only performed if the URI is dereferenced. If
>> no such representation exists, then the semantics of the fragment are
>> considered unknown and are effectively unconstrained. Fragment identifier
>> semantics are independent of the URI scheme and thus cannot be
>> redefined by scheme specifications.'
>> 
>> Further, from RFC2046 we learn that the MIME Type Registrations (taking a
>> JPG still image as an example) for JPEG 2000 (ISO/IEC15444) is specified in
>> RFC3745 where no fragments are defined, hence the general rules from RFC3986
>> apply.
>> 
>> Do we need to update all registries of targeted media types or are we fine
>> with sticking to the fallback rule from RFC3986 ('If no such representation
>> exists, then the semantics of the fragment are considered unknown and are
>> effectively unconstrained.')?
> 
> I'm glad we discussed this yesterday and I finally understood the
> particular issue that Michael was addressing.
> 
> Just for the record: my suggestion went along the following lines.
> 
> We have no authority to update registries of targeted media types. As
> far as we know there are only few media types that actually have a
> registered fragment specification - these include Ogg, MPEG-4, and
> MPEG-21 - for all others, the semantics of the fragment are considered
> unknown. The media fragment specification to be defined through the
> Media Fragment WG will be a recommendation to media type owners. We
> recommend to update or add the fragment semantics specification to
> their media type registration once a generic scheme has been
> determined. At minimum, those schemes that have an existing, diverging
> fragment specification should be harmonised. To achieve uptake of the
> scheme, updates to the server and client software for the different
> media types will be required.
> 
> Cheers,
> Silvia.

Received on Thursday, 29 January 2009 11:04:34 UTC