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

On Sat, May 2, 2009 at 2:44 AM, David Singer <singer@apple.com> wrote:
> At 12:31  +0200 29/04/09, Raphaël Troncy wrote:
>>
>> Silvia, Michael
>>
>> Indeed, we haven't scribed a formal RESOLUTION regarding this choice as
>> far as I remember, but we agree on that during the Ghent face to face
>> meeting, as the minutes let that suppose. Further,
>> http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Decisions have
>> captured the decision.
>>
>>> We never really captured the decision that was made for choosing "#"
>>> as the fragment identifying mechanism over "?". I think we will need a
>>> brief discussion about the advantages and disadvantages of these two
>>> approaches in the WD and an explanation of when to choose what. This
>>> needs to be more than the one sentence written in 6.1.
>>
>> Absolutely! More precisely, we need to specify what's happened if the
>> 'segment' is obtained with a hash ('#') or a question mark ('?') since out
>> grammar is now flexible.
>>  - In the case of the '#': the single or dual step partial GET as
>> described currently
>
> I think, rather
> ? -- it is the server's syntax and task to do the selection
> # -- it is the MIME type's syntax and UA's task to do the selection,
> possibly assisted by an enhanced protocol with the server
>
> That is, if the UA is asked to focus the user's attention on a certain
> portion of the resource, it should do the best it can
> a) to do said focusing
> b) to use the network and server wisely
>
> If the protocol is HTTP-1.1-enhanced, then there may be new commands or
> headers it can use.  In the lack of that (e.g. HTTP 1.1 or even 1.0) it does
> the best it can.

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.

I accept that during a transition phase there will be UAs and servers
that will not have this full protocol support. Such components cannot
then be called conformant to the media fragments WD.

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.

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.

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.


Taking a less hard-core stance:

Possibly, we can water down this stance by adding the requirement of
an additional notice (parameter) to the protocol if the fragment is
not resolved and a full resource is delivered.

Alternatively we can add a notice to the protocol if the fragment has
indeed been resolved and is being delivered, providing for a backwards
compatible way of dealing with non-conformant components. This will
then require additional effort in the UA, of course, but it may be
acceptable.


So, what should happen in the case of a media fragment URI in a fully
conformant environment where - for whatever reason - the URI request
cannot be resolved as a fragment. Opinions?

Cheers,
Silvia.

Received on Saturday, 2 May 2009 12:53:39 UTC