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

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

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

> 
> 
> 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.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Monday, 21 June 2010 22:07:59 UTC