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

Cool. :-)
I made a minor change to that page - just clarifying some language. All is good!

Cheers,
Silvia.

On Thu, Jan 29, 2009 at 10:03 PM, Michael Hausenblas
<michael.hausenblas@deri.org> wrote:
>
> 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 13:20:09 UTC