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

Hi Silvia, all,

> I have re-read the complete document - it has actually turned into
> quite an enjoyable read! But there are many small inconsistencies.

Thanks a lot! My suggestion is to use this email to guide today's 
telecon discussion. These are my short answers:

> 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

I agree with Jack's opinion here. We have one one side the URL syntax 
which is common (Section 4) and on the other side the processing which 
is protocol dependent, nicely described for HTTP (Section 5). We could 
certainly add a section 5.3 (boiler plate to be filled) for processing 
media fragments on RTSP.

> 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!

Intentionally left blank :-)

> 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?

I like this bulleted points but it should refer back to the UC & 
Requirements document. I suggest to add a note 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!

Has the clarification you wrote bee included?

> 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 can have multiple tracks, see 
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax, 
resolution on 09/03/2010. All the places where we say we can have *only* 
one track should be fixed!

> 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?

We purposely want to say that "id" can be anything (not only temporal) 
and CANNOT be combined with another dimension. An "id" refer to a part 
that an author has delimited in the media file, it could be 
spatio-temporal, it could be track for a period of time, etc.

> 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?

No, we define the "id" as a convenient and human readable way of 
addressing fragment. Theoretically, there is nothing you cannot do if 
you remove this dimension. This is just a shortcut to a dimension or a 
combination of dimension that you might use so often that you want to 
give it a name.

> 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.

Agree. We will need to work on this in the coming weeks. During the 
Sophia Antipolis F2F meeting, we have even anticipate we might need a 
dedicated f2f meeting to progress on this in September/October. OVC @New 
York might be the good occasion!
Best regards.

   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 Wednesday, 23 June 2010 08:30:07 UTC