- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 31 Mar 2010 23:04:36 +1100
- To: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Cc: Media Fragment <public-media-fragment@w3.org>
Hi Raphael, 2010/3/31 Raphaël Troncy <raphael.troncy@eurecom.fr>: > >> Also, there are test cases >> missing for a and b being before the beginning of the media resource. >> Did you go through all the test cases that I listed in >> >> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#error-temporal >> ? > > Let's see: > . 6.2.1 is equivalent to Test n°26, 27a and 27b Yup, OK. > . 6.2.2 is equivalent to Test n°4 except we don't know if we should return > a 416 or a 200 ... while you wrote it should be 200 I think we may generally actually have to deal with both error codes for some requests, and none for others. If the UA is resolving it all without the help of the server, then there should never be an error code coming from the server and it would make little sense for the UA to pretend that such an error code exists. Only where we actually pretend as a UA that the request makes sense and package it in a Range request should we see such a problem. Specifically for the case of 6.2.2 it would make sense for the UA to notice that a>b and not even try to do a retrieval action. It should simply just do nothing, just like a request for a fragment on a HTML page where the fragment doesn't exist leads to no action. > . 6.2.3 is equivalent to Test n°1 OK. > . 6.2.4 is equivalent to Test n°2 and 3 except that we return a 416 and not > 200 See reasoning above for no HTTP activity and therefore no return code. > . 6.2.5 is equivalent to Test n°10, 11 and 12 except that we return 206 or > 416 and not 200 10, 11 and 12 have to be diversified based on whether a lies before or after the beginning of the media resource. In fact, we need to introduce something like s=start time and e=end time everywhere. Thus we need to adapt/introduce the following: no5: t=a,b with s<=a, a<b, b<=e => play a to b introduce no5a: t=a,b with a<s, a<b, s<b, b<=e => play s to b introduce no5b: t=a,b with a<s, a<b, b<s, b<=e => empty fragment (these include no6 now) no7: t=a,b with s<=a, a<b, a<e, b>e => play a to e no7a: t=a,b with a<s, a<b, a<e, b>e => play s to e no7b: t=a,b with a<b, a=>e, b>e => empty fragment (this last one includes no8 and no9) no10: t=a, with a>=s, a<e => play a to e no10a: t=a, with a<s, a<e => play s to e no14: t=,a with a>s, a < d => play s to a no14a: t=,a with a<=s, a<d => empty fragment > . 6.2.6 is equivalent to Test n°5, 6, 7, 8, 9, 13, and 14 except again you > always return a 200 while it is often a 206. Yeah, that's possible where we actually do a HTTP Range request. > In summary, I found our table much more complete. We differ in the response > code we should answer. I don't see which test cases we have forgotten. Could > you please tell me which ones are missing? Yup, listed above as a/b numbers and additional conditions to the ones in the existing list. Mostly related to missing out on defining the "start" time of the resource. Regards, Silvia.
Received on Wednesday, 31 March 2010 12:05:30 UTC