Re: LC Review of "Media Fragments URI 1.0" from MAWG

Dear Tobias,

[This mails is dated from 01/10/2010 and the Media Fragment 
specification has evolved significantly since this date but since we are 
moving to another short period of LC, I would like to answer to how we 
have addressed the comments from the Media Annotations WG].

Thanks a lot for your detailed review.

> Section 1 / Overall structure:
>
> What I miss in this section is an introduction to the structure and the
> content of the document that guides the reader through the document. It
> should briefly motivate each section, tell the reader what to expect
> from them, and also give hints on which section to read based on
> different interests in the specification (i.e. a reader might only be
> interested in the fragments URI syntax while another might be interested
> in the server implementation part of it). Having said that, the
> specification could more clearly seperate between the syntax and the
> implementation part.

Each section is now introduced with a paragraph that described what the 
reader will find.

> Furthermore I think the order of the sections could be changed as you
> could maybe group the sections related with the implementation. This
> means that you could move Section 4 (the syntax section) directly after
> Section 2. Another reason for the suggestions to move Section 4 is that
> in Section 3 you describe how your specification shuld be interpreted
> and implemented in both user agents & servers. However, the reader does
> not know the details of the specification yet.

The structure has slightly changed since your review. The Section 3 is 
mainly meant to be a discussion of the differences between URI fragments 
and URI queries since this is a question we frequently receive. The 
Section 4 is now only about the syntax of the Media Fragment URI syntax. 
The Section 5 is about how to process those media fragments, in 
particular if the UA will need to have some help from the server or not 
for requesting only byte ranges corresponding to the fragment. The 
Section 6 is about the semantics of Media Fragments with the typical 
errors implementer can come across. The Section 7 is non normative and 
meant to be notes for implementers. We do have a general conclusion and 
references and a number of annexes that collect all the ABNF syntax of 
the specification (for URI and for the HTTP headers) and how to process 
media fragments in the context of the RTSP protocol.

> You refer to RTSP in the first section without giving a pointer or
> explaining what RTSP is; this might not be known to all readers.

This is now in the Annex D.

> Section 2:
>
> The beginning of your terminology section was slightly confusing for me
> as you state that "you use the term 'URI reference' as defined in..."
> and in the next sentence say that due to simplicity reasons you don't
> call "URI references" like that in your report. Therefore I suggest to
> rather saying that you "use" the term as defined in RFC3986, you could
> say that you adher to the semantics of the term "URI reference" as
> defined in RFC3986.

We have clarified this paragraph.

> Section 4:
>
> Again, the editorial note from Philip in Section 4.2 makes a valid
> point. If you foresee or allow in your specification that vendors should
> be able to extend it, then you should provide details about the
> extension possibilities or how the group thinks extensions should be
> implemented and specified. This goes along with the conformance criteria
> point from Section 3.

The extensibility is now defined by the fact that a media fragment URI 
is a list of name-value pairs. The specification define a number of 
those name / values but future specification could define other ones 
that would be backward compatible.

> Here I miss a discussion of the possibilities for combined use of the
> different dimensions or at least a pointer telling the reader that you
> discuss this in your Section 6.

The resolution order of multiple dimensions is defined in the Section 
7.3 but we consider it as a note for implementers and it is therefore 
non normative.

> Section 5:
>
> Section 5.1.2 says that a user agent without knowledge of which bytes to
> request for a media fragment should "guess" what to request. How would
> this guessing look like?

The UA would typically asks for some metadata in order to start the 
decoding pipeline of the video. In the case where the container format 
would be MPEG-4 or WebM, the UA will have all the information for 
mapping a media fragment expressed in seconds to byte ranges. This 
mapping can therefore be done purely on client side and the UA will only 
issue a classic range requests.

> Section 6:
>
> Here you could give hints on how you expect user agents or servers
> generally should implement error handling.

This is still under discussion within the working group. We might strip 
out this section later on given the fact that a Test Suite report will 
be in preparation.

> You often write that sth. "results in 206" -> here you should make more
> explicit that you talk about HTTP Status codes.

This has been clarified.

> 6.2.1, third line says "t=a, or t=a" seems to cotain an error.

No, this is what we meant (the comma is important). Whether we have 
#t=2, or #t=2 if the start time of the video s is > 2, then the UA will 
get content from s to e (the end of the video).

> 6.2.1, eight line describes a case where b is beyond the end (e) of a
> media resource. You say that a 206 should be returned, however you might
> want servers or user agents to point out to this particular case, i.e.
> that the requested end of the interval is beyond the end of the media
> resource and thus cannot be requested. Do you foresee this somehow?

Test cases are currently being discussed within the group.

> Did you at any point in time think about the definition of specialized
> error codes that might be returned to different (mis-) usages of the
> syntax (similar to the status codes the MAWG defines in the API document)?

We rely on the HTTP status code and in particular in the 4xx error codes 
(e.g. 416).

> What I maybe miss in the spec are explanations on how the Media
> Fragments URI 1.0 should be used in the use cases you describe in
> another document or for purposes mentioned in the Introduction, i.e.,
> how should a "Semantic Web" guy use your URIs, why should he be
> interested in it, etc...

The conclusion adds a little bit more information.

> To conclude, as said above, I have no substantial comments on the
> content of the spec. I hope that my comments are useful and I am looking
> forward to re-visit the final version of your document in the near future.

Thanks a lot and apologies for this very late answer.
Best regards.

   Raphaël ... on behalf of the WG

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Tuesday, 15 March 2011 20:32:46 UTC