Warning:
This wiki has been archived and is now read-only.

UserAgentMediaFragmentResolution

From Media Fragments Working Group Wiki
Jump to: navigation, search

User Agent Media Fragment Resolution and Processing

As of ISSUE-7 we need to explain what steps are necessary on the client side (UA) to resolve and process a media fragment.

Note that the current algorithms as described below are HTTP-only. Once we gather more implementation experience, this can be used as the base to create a generic resolution and processing algorithm, addressing other transport protocols as well.

Case: Full media fragments-conforming User Agent (UA++MF)

In case of a UA that is fully conforming to the MF specification (or UA++MF), the necessary steps to resolve and process a media fragment are as follows:

Error creating thumbnail: Unable to save thumbnail to destination
  1. URI FRAGMENT DETECTION
    1. The UA++MF performs a URI resolution as of RFC3986.
    2. IFF a URI fragment is PRESENT (that is, T.fragment as of the reference resolution is not empty) the processing CONTINUES, ELSE the URI can per definition not be a MF URI and the processing TERMINATES.
  2. URI FRAGMENT VALIDATION
    1. The UA++MF VALIDATES the T.fragment against the MF Grammar.
    2. IFF the T.fragment is VALID, the processing continues, ELSE essentially three alternative behaviors are possible: (i) fallback to default behavior, (ii) notify user and then fall back, or (iii) notify user and await instructions. One SHOULD take the Common User Agent Problems into account. Note: we have to decide what we do here.
  3. NETWORK COMMUNICATION
    1. The UA++MF GENERATES the HTTP header and sends it to the Server using the HTTP GET method; once the UA++MF receives the response it parses the HTTP Response header.
  4. RESPONSE VALIDATION
    1. IFF the HTTP Response header is valid the processing CONTINUES, ELSE the user is NOTIFIED and the processing TERMINATES.
    2. (OPTIONAL) As a fallback, the UA++MF MAY continue the processing with the entire representation. Note: we have to decide what we do here.
  5. RENDERING
    1. The UA++MF looks up the media type of the representation from the previous step.
    2. Based on the INVARIANCE PRINCIPLE (@@ref me), the media type determines how the UA++MF will RENDER the audio-visual octet-stream (the respective media fragment of the obtained resource or the entire resource).