W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

Re: media fragments (Re: Draft minutes from 2012-05-03 TAG telcon)

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 05 May 2012 21:45:10 +0200
To: Thomas Roessler <tlr@w3.org>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <fogaq71t9c17301ist14e9q1h0642ose03@hive.bjoern.hoehrmann.de>
* Thomas Roessler wrote:
>To put this snippet (and the discussion at the Web conference) in
>context, I recommend a look at the charter of the media fragments WG:
>> The mission of the Media Fragments Working Group, part of the Video in
>> the Web Activity, is to address temporal and spatial media fragments in
>> the Web using Uniform Resource Identifiers (URI)
>	-- http://www.w3.org/2008/01/media-fragments-wg.html
>In the conversation at WWW 2012, I took Larry's critique of media
>fragments to be against a W3C working group defining semantics for
>fragment identifiers.  I pointed out that that was the very purpose of
>this working group, and said that if people thought this basic approach
>was a mistake, then that would have been a point to discuss at
>chartering time, not at PR time.

The word "fragments" in the quote above refers to "media fragments" like
a region of an image; it does not refer to URI fragment identifiers. The
Working Group was to investigate URI fragment identifiers as option, it
"will investigate the several possibilities in the URI syntax, such as
URI fragment identifier or query parameters" per the charter, but that's
it. Anyone saying during chartering time using URI fragment identifiers
is the wrong idea would likely have been told that the group will inves-
tigate and ascertain that if so, so that would not have been the time.

I don't know anyone is actually arguing that using URI fragment identi-
fiers is wrong for this, but in any case, the fundamental problem with
that is that the interpretation of URI fragment identifiers depends on
the media type of the resource. So without updating media type specifi-
cations, the Media Fragments specification cannot actually define seman-
tics for URI fragment identifiers. And it doesn't, it just offers people
who define media types to reference the Media Fragments specification
for their fragment identifier syntax.

>There's a separate question what the exact coordination needs are at
>this point, how they are best dealt with, and what communication needs
>to go back to the IETF.   As W3C liaison to the IETF, I re-iterate my
>request that TAG members put coordination issues on the agenda of
>W3C/IETF liaison meetings, where these belong.  Interfering in the work
>of the liaisons is not helpful.

Well, very early on the Working Group had an issue "Does our MF URI
syntax imply that we need to update MIME Type registrations?" That one
got resolved by a new issue "Write a IETF draft for proposing how to
register the fragment scheme for all media types" which a year later
was merged into the issue "Create a IETF draft at CR stage explaining
what the media fragment semantics will be for video/*, image/*,
audio/*", see the "IETF and TAG updates" section in the minutes here,


I note that this issue isn't new to W3C's IETF liaisons, see e.g. the
thread at <http://www.w3.org/mid/1271782569.4466.7439.camel@pav.lan>.

Then, after the document got approved for publication as Candidate
Recommendation, the Working Group decided they would rather not write
such a document during the Candidate Recommendation phase after all,
and specifically asked W3C's IETF liaison how to handle the matter,


I am not aware of any response or reaction.

Dan Connolly had this to say, "It doesn't seem responsible for W3C to
Recommend the media fragments spec without some plan in place to get
the IETF/IANA registrations updated." and "It's not polite for W3C to
unilaterally encourage implementations to deploy certain designs that
will constrain updates to IETF RFCs." That's what the W3C is doing.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Saturday, 5 May 2012 19:45:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:44 UTC