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

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


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!


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?


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!


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?


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?


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.


Cheers,
Silvia.


2010/6/17 Raphaël Troncy <raphael.troncy@cwi.nl>:
> Hi Silvia,
>
>> Thanks for pushing that onto me. :S
>
> Yeah, we have been very pushy on this one, sorry. We believe you're
> interested in having an overall look at the whole document although most of
> the content as been authored by you. The rationale is that the document has
> been edited for one year, so there might some part that are deprecated. Let
> us know if you cannot make the action.
>
>  Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Multimedia Communications Department
> 2229, route des Crêtes, 06560 Sophia Antipolis, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242
> Fax: +33 (0)4 - 9000 8200
> Web: http://www.eurecom.fr/~troncy/
>
>

Received on Monday, 21 June 2010 13:50:24 UTC