This document records the Media Fragments Working Group's response to comments on both the June 2010 Last Call Working Draft and the March 2011 Second Last Call Working Draft of Media Fragments URI 1.0.
The "Status" column indicates Media Fragments WG's disposition of the issue:
accepted: originator's suggestion (if any) was accepted substantially as proposed.
accepted with modifications: MFWG accepts that originator's issue is valid, but we implemented something else than what (if anything) was suggested.
not accepted: originator's comments and/or suggestions were not accepted.
| Issue | Originator | Description | Resolution | Originator's reply |
|---|---|---|---|---|
| Clarification regarding the sending of Range headers | Chris Double | The Media Fragments WG needs to specify whether it is expected that for every URL request with a fragment that matches the syntax of media fragments that the user agent will attempt to send the Range header. | The following paragraph has been added in the section 5 Media Fragments Processing: "The User Agent MAY also implement a so-called optimistic processing of URI fragments in particular cases where the MIME TYPE of the resource requested is not yet known. Hence, if a URL fragment occurs within a particular context such as the value of the @src attribute of a media element (audio, video or source) and if the time dimension is requested in the media fragment URI, the User Agent MAY follow the scenario specified in section 5.2.2 Server mapped byte ranges and issues directly a range request using custom units assuming that the resource requested is likely to be a media resource. If the MIME-type of this resource turns out to be a media type, the server SHOULD interpret the RANGE request as specified in section 5.2.2 Server mapped byte ranges. Otherwise it SHOULD just ignore the RANGE header." | accepted |
| Improving the readability of the whole document | Tobias Bürger (on behalf of the MAWG) | Based on some given points to improve the readability of the whole document, the Media Fragments WG is requested to update the document. | The whole document has been updated taking into account the received comments for improving readibility. | accepted |
| Issue | Originator | Description | Resolution | Originator's reply |
|---|---|---|---|---|
| Pixel-based clipping areas on multi-resolutions visual media | Fantasai | The Media Fragments WG needs to specify what happens when the fragment identifies coordinates that are not within the image bounds. | The following paragraph has been added in the section 4.2.2 Spatial Dimension: "If the clipping region is pixel-based and the image is multi-resolution (like an ICO file), the fragment MUST be ignored, so that the url represents the entire image. More generally, pixel-clip an image that does not have a single well defined pixel resolution (width and height) is not recommended." | accepted |
| Spec clarification (temporal addressing) | Franck Denoual | In section 4.2.1 Temporal Dimension, you indicate that "t=10," (with comma at the end) leads to interval [10, end). It seems that the ABNF grammar just below does not allow this since it is the whole pattern ["," npttime] that is optional in npttimedef definition. Moreover in your test cases [2], you propose to consider "t=3," as invalid syntax. I think there is a need for clarification here. | This was indeed an invalid fragment and the specification has been edited as suggested. | accepted |
| Concerns about backwards compatibility of media fragments | Boris Zbarsky |
The section 2.2.1 URI Fragments says: An analysis of all media type registrations showed that there is not a single media type registration in the audio/*, image/*, video/* branches that is currently defining fragments or fragment semantics. I'm not sure how this analysis was conducted, but image/svg+xml is defined to be SVG and SVG does in fact define fragment semantics. This means that applying media fragments to SVG images, at the very least, would cause behavior changes in current UAs. |
This issue has been extensively discussed on the mailing list and a decision was made to bring it up to the Hypertext Coordination Group. This issue has been further discussed within HCG on July 1st 2011 where the minutes MFWG's intuition that SVGview having a XPointer like syntax while the Media Fragment URI having always an equal sign tend to demonstrate that there will be no syntax clash. Furthermore, CSS co-chair agrees that that the problem of multiple images of different sizes or no clearly defined size (and #xywh dimension) should be stated as a border case and undefined for media fragments (or let to be defined for MF 2.0 or something). | accepted |
| ABNF definition of NPT temporal fragment times | Chris Double | Are the ordering of the clause in the formal definition of the URI syntax important? For example, the 'npt-sec' clause is the first item in the alternates amongst 'npttime'. Given a temporal fragment of '#t=20:10', I see that 'npt-sec' will successfully match, but 'npttimedef' will fail since a ':' instead of a ',' follows the first number. | No editorial changes but clarifications on the mailing list that from a formal specification to an implementation, one has indeed to do backtracking. | accepted |
| Use of 'behind' when referencing URI portions | Chris Double | Editorial comment in the section 2.1 Terminology where the word 'behind' is used and seems ambiguous. | Change the wording to adopt the RFC3986 terminology. | accepted |
| Splitting out the Section 5.2 of the specification | Yves Lafon | The entire section 5.2 Protocol for URI fragment Resolution in HTTP describes various recipes for processing media fragments URI over the HTTP protocol between a user agent and a server. However, it is likely that some of these recipes will not be sufficiently implemented. The group needs more implementation experience before recommending which recipe is more appropriate. This section should be taken out of the specification and be edited in a separate document. | This has been a contentious issue for four months. A formal questionnaire has been issued and the results were slightly in favor of keeping this section within the specification. The rationale was that keeping this section in the main document will increase awareness of the various recipes in the developer community and therefore helps the working group to choose the ones that could finally be recommended. Due to the risk of non interoperability between the various immplementations, the chairs have decided to revisit this decision and split out the section 5.2 into a separate document. | accepted |
| Minor editorial comments | Thierry Michel | Minor editorial comments (typos and links broken) for passing pub rules. | All typos have been fixed. The document passes pub rules. | accepted |