Re: minutes of 2009-09-17 F2F meeting, Day 1

2009/9/18 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Dear all,
>
>>>  - We agree on the respective role of '#' and '?'. The border will be
>>> whether a transcoding process will be needed or not on server side to
>>> satisfy the request.
>>
>> I recall that we simply agreed that both syntaxes are useful and
>> within scope for MFWG.
>>
>> We didn't pass any resolutions along the lines of "if not transcoding,
>> MUST/SHOULD use syntax X, otherwise MUST/SHOULD use syntax Y" (and I
>> don't think we should mandate such a distinction).
>
> Amendment validated. Indeed, my phrasing "We agree on the respective role of
> '#' and '?'" is (purposely) vague. I also think we should not mandate such
> distinction. I can see 3 (working) cases (among many others that will
> generate different behavior):

>  - UA send a media fragment request with a hash (e.g. temporal dimension),
> the server can satisfy the range request (without transcoding) and generate
> a response as expected.

As we discussed it, this is the preferred option and the optimal
solution to media fragment addressing. In future, it would be nice if
every possible media fragment request could be fulfilled through a #
request. This situation has the advantage that the user agent can
decide whether it already has the data to satisfy the fragment
addressing locally or whether it needs to retrieve some data from the
server to satisfy it. Assuming a server can satisfy such an
interaction, this would provide the least necessary delay for the
user.

>  - UA send a media fragment request with a hash (e.g. spatial dimension),
> the server would need to transcode to serve it. We _might_ mandate that in
> this case, it does not serve a fragment but the whole resource and let the
> UA decides what to do with the fragment part

I don't think we have much of a choice here since this request means
that the server cannot satisfy the content-range request header, will
therefore ignore it, and will therefore serve the full resource.
That's how http works, FAIK. I don't think we need to mandate anything
here - the HTTP spec already takes care of this - it's one of the
error cases we are looking at in the testing case.

>  - UA send a media fragment request with a query, and we don't care anymore
> if a transcoding operation is necessary or not, the server will serve a new
> resource, with optionally? a link header pointing to the parent resource.

Since not all types of fragment addressing that we will be defining
can be satisfied through a set of byte ranges that are a subpart of
the original resource, we allow the extension of the media fragment
addressing scheme to queries (?). This allows a user agent to replace
a #-based media fragment URI through a query (?) to retrieve a
transcoded version of the original resource to satisfy the user's
needs. A few things are different in this case, because we are talking
about a different resource,  e.g. be aware that putting a #-based
media fragment behind the ?-containing URL means the fragmentation
happens on the transcoded resource; e.g. to find out information about
the original resource will require a LINK header. However, we want to
provide a framework for doing these requests such that user agents and
servers that have a need to use query (?) will have a defined
process/protocol/specification for how to do this.

That was my understanding of the outcome of yesterday. And probably a
good start at the paragraphs I promised to add to the specification.
:-)

Talk soon (if I can get the voip setup working - I am at a friend's
place tonight).

Cheers,
Silvia.

Received on Friday, 18 September 2009 07:54:49 UTC