feedback on UA test cases

Some input from me into the discussion for later today.

http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0001-UA
http://www.w3.org/2008/WebVideo/Fragments/TC/server-test-cases#TC0001-S
I think if we really want the t=, case to be equivalent to #t=s,e and
equivalent to a request of the full resource with a 200 reply, we have
to explicitly state that the browser knows that s and e are the start
and end time of the resource from a previous retrieval action.

http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0002-UA
http://www.w3.org/2008/WebVideo/Fragments/TC/server-test-cases#TC0002-S
A 416 error is correct for the server. It should never happen that the
UA sends this kind of request.
Rather, if the UA notices this request and hasn't got the setup
information for the resource yet, it will send a request just for the
header bytes (e.g. the first 200kb) and we should get a 206 reply. We
include Range: include-setup for the fragment-capable servers.
(same logic applies to
http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0003-UA)

http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0004-UA
http://www.w3.org/2008/WebVideo/Fragments/TC/server-test-cases#TC0004-S
The UA should never ask for byte ranges on this (other than as part of
its normal subsegmentation retrieval). If it knows that it is asking
for the full resource, it should not include byte ranges. Only if it
doesn't know that, will it do a npt request.
A situation like this:
  GET spatial_30fps.webm HTTP/1.1
  Range: t:npt=0-9.97
  Accept-Range-Redirect: bytes
should not happen - it should include the include-setup part, because
it obviously doesn't yet know about the setup information (otherwise
it would ask for the full resource).

Once you've answered these, the rest follows probably logically.

If you do decide to make multiple requests possible for the UA, please
include a description for the UA when to choose which one. It needs to
be clear.

Cheers,
Silvia.

Received on Wednesday, 6 April 2011 07:15:04 UTC