Re: ACTION-178: Review the complete document, remove unnecessary editorial notes before publication (Media Fragments Working Group)

On 22 jun 2010, at 01:01, Silvia Pfeiffer wrote:
> We could also just introduce a section 5.x that would describe how it
> can work with RTSP - I don't think there is that much to do, since all
> the protocol stuff should already work - it just needs to be put
> together (at least for the time dimension).

I'm slightly reluctant to do this, at this stage. I think we should just say "it's doable". The guidelines about the meaning of media fragments should make clear what needs to be done.

RTSP is really pretty much the same as file: here (and, actually, the same holds for mms: or any other scheme that could be used to transfer continuous media data).
>>> 2. Caching
>>> Section 3.4 states that in order to get the existing web proxy
>>> infrastructure to cache media fragment resources, we need to use byte
>>> ranges. In view of our recent changes - is that actually still true?
>>> And what happened to section 7.4 - it's completely empty!
>> No, it isn't. It says "This section intentionally left blank":-)
>> Seriously: we put the boilerplate in first, and then started adding things to the various subsections. So far, nothing has showed up for caches.
> Are you saying we are still missing sections about caching? I might
> have missed that from the last meeting, but if there are outstanding
> todos, then I am happy with that.

I don't think we're missing a section on caching, I think we don't have anything to say right now. The section should go. That is, unless something comes up in the next few days.
>>> 3. Requirements
>>> Section 4 has an editorial note from Jack with a list of requirements.
>>> I wonder if this list should go into the requirements document rather
>>> than here? Or what part of it should indeed be kept here?
>> This should go. I think we've fulfilled the requirements.
> It might be a good idea though to state them somewhere as design
> rules. I am happy to give integration a go.



>>> 6. Clarify "id" dimension
>>> I am again confused about "id". I was somehow under the impression
>>> that we only allowed its use for the time dimension, but section 4.3.4
>>> and 7.2 state that it can also be applied to tracks and regions. Also,
>>> section 5.1.2 contains a editorial note by Davy about the same topic.
>>> Did we actually clarify this and how it gets resolved?
>>> I think because track names are already names, "id" will actually best
>>> fit for temporal and spatial regions, but it would be cleanest to
>>> simply allow them only for one dimension - otherwise, how are you
>>> going to resolve it?
>> As far as I remember, we planned to explicitly say nothing about what id means. Note the "explicitly": the meaning can by temporal, or track, or whatever. Up to the underlying format and the implementation. Yep, this is stated in 4.3.4.
>> Does it need to be made clearer?
> The issue is that we didn't really discuss and decide on it. We didn't
> really discuss through how the HTTP requests would look like for id.
> Are we expecting a server to take an id and compare it with all
> namings it has for track, id and regions and then return the right
> reply? As said: I don't think id makes much sense for 'track' anyway,
> since it would just be a repetition of the track name. And if we allow
> it to be named for time and space, then we might want to allow 2 id
> tags for different dimensions to be valid at the same time?

I think you miss the "explicitly", still. If one implementation wants to assign a name to a set of tracks ("the french version of this movie"), that's fine. If another implementation wants to use it for DVD-style chaptering, also fine. Use of ID by an end-user requires knowledge of the underlying media (and the server that serves it). This is completely different from using t=npt:, which is rigorously defined.
Jack Jansen, <>,
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Tuesday, 22 June 2010 19:47:14 UTC