test cases - questions and discussion points for tomorrow

Here's various things that struck me. I've only glossed over the server test cases, as I'm a bit out of my water there and I need more time to review these.

TC0004-UA - why don't the second and third http example have "include-setup" in the range request? I would assume the setup bytes are needed? Similar question for a couple of the following test cases.

TC0007-UA - this suggests that time ranges should look at timestamps in the media, correct? (We went back and forth on this issue, so I don't fully remember what the latest outcome was). But this means that the suggestion in section 7.3 (external clipping should cascade) is a bit unlogical. After all, http://www.example.com/clip.mp4?t=3,10#t=3,4 won't cascade either (unless the server does remapping of timestamps on queries)

TC0009-UA The comment starting from "otherwise" isn't clear to me. I think it's meant to clarify that if the ua doesn't know the request will be out of range (and how would it know?) it will send a normal request, which happens to be out of range.

TC0013-UA The foirst http request has range: bytes ???-???, is this an editors comment? I think this alternative is impossible: if the ua has prior knowledge of the byte ranges it knows that it's asking for the whole resource, so it should simply do so.

TC0018-UA Unless I'm seriously mistaken this test case is wrong. After many discussions we decided that smpte timecodes would be content-based addressing, right? If that assertion is correct then the expected outcome and comment are incorrect, and would actually lead people to produce incorrect implementations. At the very least, the outcome should state something like "playback from the frame marked with timecode 00:00:03 in smpte-30" etc etc. Same for all other smpte tests.

TC0025-UA Same issue: this depends on data encoded in the media file (or metadata stored along with the mediafile) on the server.

TC0027-UA I think the comment is incorrect, and also the ua should not issue any request. Same for the other parse errors.

OFF-ON-A-TANGENT We state nowhere (AFAIK) whether our strings are case-sensitive. I assume they are, because of the BNF, but (a) we should state so somewhere, and (b) we should add a test that #T=1,3 doesn't work.

TC0034-UA and friends: we miss one interesting test case: for percent-escaping the "=" (which IIRC shouldn't work). Same for escaping ampersand (which should work for something like track but not t).

TC0044-UA the comment is misleading. '-' isn't in our BNF, so this isn't a "negative number", it's simply a syntax error like t=banana. We don't have the concept of negative numbers in our spec:-) Same for TC0049-UA.

TC0053-UA Is this indeeed what we specified, that duplicate axes are allowed as long as we only know the units on one of them??? If we indeed specified this that we should also test the reverse order (which is easier to get wrong:-)

TC0054-UA This test suggests that we proscribe to first split on &, then ignore any field that has syntax errors. Is that indeed what we specified?

TC0055-UA We should also test that t=npt:3&t=smpte:00:00:03 fails. Even though I don't like the inconsistency with ignoring unknown units....

TC0056-UA We should also add a couple of nasties here: tracks with a space or ampersand or some other magic character in their name.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Tuesday, 5 April 2011 22:02:29 UTC