LC Review of "Media Fragments URI 1.0" from MAWG

  Dear Raphael, all,

you asked for review of your LC document "Media Fragments URI 1.0" 
(working draft from 24.06.2010). I had a look at the document and do not 
have any substantive or critical comment on it. As you, from the 
perspective of the MAWG, we are mainly interested in the capabilities of 
the spec to identify and point to fragments of a resource, therefore I 
focused reading on the syntax part of the document.
The MAWG suggests the usage of the Media Fragments URI 1.0 with its 
fragment-properties whose purpose is to identify a (named) fragment and 
its role wrt. to a media resource. I can not spot any defects or 
omissions in the syntax part of the spec - this part seems to be very 
well worked out!

Nonetheless I would like to ask you to take up some of my following 
points to improve the readability of the whole document:

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.

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.

Each section 2-7 would also benefit from short introductions themselves.

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.

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.

Section 3:

I strongly agree to the editorial note in Section 3.6 from Silvia: A 
table detailing the conformance criteria would be helpful.

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.

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.

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?

Section 6:

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

The headings in Section 6.1 could be more readable. What does "Empty" 
(6.2.2) mean?

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

6.2.1, third line says "t=a, or t=a" seems to cotain an error.
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?

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)?

Overall:

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...

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.

Best regards,

Tobias

PS: Tracker, this is action-265, 
http://www.w3.org/2008/WebVideo/Annotations/track/actions/265

-- 
================================================================
Dr. Tobias Bürger         Knowledge and Media Technologies Group
Salzburg Research                           FON +43.662.2288-415
Forschungsgesellschaft                      FAX +43.662.2288-222
Jakob-Haringer-Straße 5/III   tobias.buerger@salzburgresearch.at
A-5020 Salzburg | AUSTRIA         http://www.salzburgresearch.at

Received on Friday, 1 October 2010 03:50:59 UTC