W3C home > Mailing lists > Public > public-media-fragment@w3.org > June 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 22 Jun 2010 10:11:36 +1000
Message-ID: <AANLkTinVGw2zdylZKcwqtWaF_u6YXoqqjjqNtzLp4rPq@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: raphael.troncy@eurecom.fr, Media Fragments Working Group WG <public-media-fragment@w3.org>
BTW: I also just noticed that we should add to our analysis list of
appropriate formats for media fragments and analysis of the WebM


On Tue, Jun 22, 2010 at 9:01 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 8:07 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> On 21 jun 2010, at 15:49, Silvia Pfeiffer wrote:
>>> Hi all,
>>> I have re-read the complete document - it has actually turned into
>>> quite an enjoyable read! But there are many small inconsistencies.
>>> I will go ahead and fixed some of the smaller issues - you will see
>>> them in the commit messages and can reply there if you disagree. But
>>> there are still some open issues that we need to discuss and resolve
>>> to make the document consistent.
>>> Here they are:
>>> 1. RTSP
>>> We had at some places mentioned that we support RTSP as well as HTTP
>>> in this specification, but in particular section 5 (media frag
>>> processing) we are completely focused on HTTP and do not mention how
>>> the frag resolution could work over RTSP. We should either remove it
>>> or add a section in 5 that explains how it is done with RTSP.
>>> mention in:
>>> * section 1
>>> * section 2.2.2
>>> * section 5.1
>> Our spec consists of two somewhat-separate parts:
>> - URL fragment syntax
>> - HTTP implementation
>> IMO the first one has a wider validity than http, it can be used with file: and rtsp: URLs as-is.
>> This is already mentioned in passing at the end of section 1, but indeed a note either in the preamble of section 5 or in secrtion 7.2 would be a good idea.
> 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).
>>> 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.
>>> 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.
>>> 4. ABNF unclear
>>> Section 4.1 has the following bit of ABNF:
>>> namevalues  = namevalue *( "&" namevalue )
>>> namevalue   = name [ "=" value ]
>>> name        = fragment - "&" - "="
>>> value       = fragment - "&"
>>> I am curious what the role of the dashes and the ampersands is in the
>>> name and value dimensions and why "fragment" is repeated there -
>>> wouldn't it make a lot more sense to list the different names of the
>>> dimensions? Also, these bits do not turn up in the summary ABNF at the
>>> end - that is rather confusing!
>> I interpreted the - as an ABNF construct: "name is like fragment, but can't contain ampersand or equals". But: this is pure guesswork. Yves?
> Oh, it's a minus? That might be what I was missing. We should then probably add
> fragment      = <pct-encoded, defined in RFC 3986>
> there, just for clarification.
>>> 5. Clarify "track" dimension
>>> I am rather confused right now: how did we decide to do multiple
>>> tracks? In some places we talk about several tracks being able to be
>>> defined, but only a single track per spec (see 4.3.3 and the
>>> examples), and in other places we talk about there only being one
>>> track dimension allowed (D.2 3c and 5.1.2, Can somebody
>>> clarify?
>> We decided on multiple tracks recently (I actually seem to remember that you suggested it,  because your contacts said that single-track-selection would be useless). But, indeed, most of the text was written when we still thought of single track selection only.
> Yes, multiple tracks. But how? Through multiple track parameters or
> through one with semicolon-separated elements? I cannot remember
> whether we made an actual decision on that. Once somebody clarifies
> this for me, I can fix it either way. I would personally prefer them
> all in one track parameter, since that will make the different
> dimensions more consistent.
>>> 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?
>>> 7. Error cases
>>> Section 6 is incomplete. We need to discuss Raphael's note on 6.2.1
>>> and my paragraph. We need to work on 6.3, 6.4, 6.5 for the
>>> non-temporal dimensions.
>> You're probably right.
> Could be added in the next revision after LC?
> Cheers,
> Silvia.
Received on Tuesday, 22 June 2010 00:12:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC