WG Resolutions

Media Fragment Scope

• The WG resolved on 2008/10/21 that the media fragment URI syntax will primarily use the '#' and consider using the '?' for other use cases (see also the wiki page)
• The WG resolved on 2008/10/21 to consider only rectangle shapes for the spatial dimension in a first version of the media fragment URI scheme
• The WG resolved on 2008/12/09 to provide either informally or in the specification a mapping between the media fragment URI scheme and the standards covered in the Technological Survey
• The WG resolved on 2008/12/09 to consider four dimensions for addressing a fragment of a media resource, namely: time, space, track and name
• The WG resolved on 2008/12/09 that the track selection is limited to what the media container format is exposing
• The WG resolved that the protocols covered by the media fragments URI scheme are HTTP and RTSP
• The WG resolved on 2009/09/17 that the aspect ratio is NOT considered as a fragment and therefore remove from the syntax and features offered by the Media Fragment URI specification

Media Fragment URI Syntax

See also the decision on the syntax wiki page

• The WG resolved on 2009/01/28 to use '&' as the primary separator in the media fragment syntax (see also the poll results)
• The WG resolved on 2009/01/28 to use four schemes for defining a rectangle region and let the community decides (see also the poll results)
• The WG resolved on 2009/01/28 that single quotes are optional to specify the value of the track and the name dimensions but that double quotes are forbidden (see also the poll results)
• The WG resolved on 2009/03/11 to use 'segment' as the top-production rule in the media fragment syntax (see also the poll results)
• The WG resolved on 2009/07/22 that the comma is optional for specifying a temporal Media Fragment and if a one is provided, this means it is the starting time
• The WG resolved on 2009/08/12 to use the temporal-optional-comma specification syntax proposed by Franck
• The WG resolved on 2009/09/02 that the syntax will NOT allow editUnits for specifying the temporal dimension based on the following rationale
• The WG resolved on 2010/02/24 that the syntax will be formally specified in ABNF since the editors know very well the ABNF syntax and that we have tools to handle it
• The WG resolved on 2010/03/08 that the syntax of the temporal dimension (wall-clock time code) will be specified with RFC3339
• The WG resolved on 2010/03/08 that the media fragment syntax does not treat the single quote as a special character. Values for the track and id dimensions should be percent-encoded when necessary. Further, we should clarify and put a strong statement in the spec that the number of characters we can use non-%-encoded is very limited and point to them the RFC3986 for that. Most of the characters should be %-encoded.
• The WG resolved on 2010/03/09 that the media fragment URI will allow multiple values for the track dimension, using multiple occurrence of the keyword 'track' (e.g.: #track=audio&track=video). (Note that this explicitly contradicts a resolution we had on 2010/03/08 that is now deprecated).

Media Fragment Headers

• The WG resolved on 2009/09/17, in 2009/09/23 and during the 5th F2F (2010/03/08) that the syntax for expressing a Range request will use the HTTPBis clarification for having custom units.
• The WG resolved on 2010/03/09 that a new header named 'Content-Range-Mapping' will be introduced, which purpose is to expressed a mapping of a Content Range between 2 units (e.g. bytes and seconds)

The work in progress document specifying the syntax for the HTTP headers is at MediaFragmentHeaders

Test Cases

• Approval of TC0000 as per 2009/5/13
• Approval of TC0001 as per 2009/5/13
• Re TC0002-TC0007, the WG agrees that empty is not an error (as in 404) but a recoverable state
• WG agrees that empty representation means 416
• Approval of TC0007 as per 2009/6/24
• Approval of TC0002 as per 2009/8/12 with 416, would yield an empty resource, hence client must have erred
• Approval of TC0003 as per 2009/8/12 with 416, would yield an empty resource, hence client must have erred
• Approval of TC0004 as per 2009/8/12 with 416, would yield an empty resource, hence client must have erred
• Approval of TC0005 as per 2009/8/12, when changed to 200, the entire representation is returned
• Approval of TC0006 as per 2009/8/12, when changed to 200, the entire representation is returned
• Change and Approval of TC0007 as per 2009/8/12, because #t=, now refers to the full resource; therefore return just named fragment
• Add use cases as per 2009/8/12:
  • TC010: with #t=0,0&id='ID0' with 416, would yield an empty resource, hence client must have erred
  • TC011: with #id='none' for non-existing id with 416, would yield an empty resource, hence client must have erred
  • TC012: with #track='none' for non-existing track with 416, would yield an empty resource, hence client must have erred

Issues recorded in the tracker

Combining Media Fragment URI with other time-clipping methods

Specifying a time-clipping method, for example in SMIL, is relative to the (timeline of the) resource. Therefore, if one specifies:

<video clipBegin="5s" clipEnd="15s" src="http://www.example.com/video.mov#t=20,30"/>

what's happen?

The WG resolved on 2009/02/04 that in the cases where the media fragment is i) encompassing, ii) embedding, iii) disjoint or iv) partially overlapping the boundaries of another time-clipping method yield two possibilities:

• EITHER the media fragment is regarded as out-of-context and the clipping method MUST be done relatively to the media fragment but bound to the media fragment, i.e. the UA plays the video segment between the seconds 25 (=max[20,20+5]) and 30 (=min[30,20+15]).
• OR the media fragment is regarded as in-context and it depends on the application what the best solution is for the UA to do: some UAs may, for example, provide a timeline that encompasses the whole document, not only the time clipping. Implementors SHOULD follow semantics similar in spirit to the previous bullet, but adapted to their situation.

See also the ISSUE-1 and the ACTION-37

What is the mime type of a media fragment?

The WG resolved on 2009/02/12 that the mime type of a media fragment is the *same* mime time of its parent resource. Hence, a media fragment addressing a single frame of a video would be of mime type video. If the media format constrains the playability of such resource (e.g. MP4 or 3GP explicitly forbid to have video with a zero duration), then the selection of this fragment will fail. In other words, media fragment URI are bound to the limitations of the underlying coding and container formats.

See also the ISSUE-2

Publication of Documents

• The WG resolved to publish Use cases and requirements for Media Fragments as a FPWD on 2009/04/16