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

BTW: I also just noticed that we should add to our analysis list of
appropriate formats for media fragments and analysis of the WebM
format.

Cheers,
Silvia.

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, 5.1.2.1). 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