Re: Description of the 2-ways and the 4-ways handshake

At 22:52  +1000 2/05/09, Silvia Pfeiffer wrote:
>Ah, this is related to what you wrote to WHATWG. Rather than
>discussing it there, we need to come to an agreement here and be able
>to explain to outsiders only one view.
>
>Unless I missed something in Barcelona, I don't think we have actually
>defined it in the way in that David has described it.
>
>
>So, let me take the hard core standards stance on this:
>
>I think that ultimately a user should be able to expect from their UA
>that a media fragment uri of the form
>http://example.com/video.ogv#t=500,520 does not result in a full
>retrieval action, but only in a fragment retrieval. That is the aim of
>media fragment URIs. Even for spatial, track and named addressing.

If the UA claims to implement media fragments, for resources of that 
type, it should focus the user's attention on that fragment, agreed. 
So this is a conformance between the URI meaning and what the UA does 
with it, and we can say what that is.

But let's say I post a video on my site, and Sylvia posts a URI on 
hers pointing at a fragment of my video.  Legit., surely:  but does 
it suddenly mean that I have to have a media server in conformance 
with the fragment spec.?  I don't think so.

More, if the UA detects that my server is not very helpful, are we 
going to *require* it gives up?  I don't think anyone would write a 
UA that way;  it'd be non-competitive.  The UA is going to do its 
best.

The analogy was, for us, when QuickTime tried doing byte-range 
requests on HTTP 1.1 servers.  If we found  a 1.0 server, well, your 
seeks could take a while, as all we could do was ask for the whole 
file.

>When a user puts such a URI into a conformant set of components (UA,
>proxies, server, etc), he/she has to be able to rely on the media
>fragment being retrieved and not the full resource. The problem with
>allowing multiple different results to a single URI is that the UA
>ultimately doesn't know what it should do with it. If e.g. it cannot
>rely on the fragment being delivered, it cannot adapt the start time
>to the correct time offset or the spatial display coordinates to the
>correct ones.

We have to be careful what we are trying to put under a conformance 
requirement.  Since fragments are offered to, and interpreted by, the 
UA, I think that's where they are.  And they are a presentation 
requirement, and a 'best effort' on the network side.

>
>A standard that allows more than one possible resource composition to
>be returned for a unique resource identifier request is watering down
>what that URI means.

Disagree:  its meaning is clear, and if the UA supports media 
fragments, it must focus attention on that fragment.  To get good 
sales in the market, it probably wants to do that efficiently and 
pleasantly for the user.

>
>Thus, I think we need to write into the standard that, given
>conformant components, the delivered resource has to be the fragment,
>otherwise the retrieval action should fail.

'presented' not 'delivered', I think.

I have no problem with extending the HTTP protocol for servers that 
want to help more;  I just think that the link from URI to server is 
sometimes tenuous.

For *query* identifiers, which are indeed interpreted at the server, 
I'd better be sure that the server in the main part of the URI I 
write understands the query identifier in the query part of that URI, 
of course....and if the server claims conformance to some 
media-query-identifier spec., then I can use that spec. to write URIs.

Likewise if the server reports to the UA, 'yes, I can do all the 
assistance required of a server in the XXX spec." then it had better 
deliver:  it's making a conformance claim.

-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Wednesday, 6 May 2009 00:46:37 UTC