Re: ACTION-123: Silvia to come up with ABNF for header syntax - FINISHED

On Thu, May 20, 2010 at 6:50 PM, DENOUAL Franck
<Franck.Denoual@crf.canon.fr> wrote:
> Hi all,
>
> I have some comments/remarks on the nice ABNF syntax for HTTP headers provided by Silvia:
> 1- Should each grammar be self-descriptive or not ? (I would personally think: yes)
> If yes, the following items (from MF URI and HTTP RFC) should be redefined:
> -> byte-ranges-specifier
> -> time-prefix, trackprefix, nameprefix
> -> trackparam, nameparam
> -> deftimeformat, smpteformat, clockformat
> -> npt-sec (only ? not npttime?), frametime, datetime
> -> token
> -> byte-range-resp-spec
> If no => at least a reference to the ABNF syntax for URI and to HTTP RFC should be inserted in HTTP ABNF syntax.


I don't want to redefine things that we have already defined earlier,
such as time-prefix, trackprefix, nameprefix, trackparam, nameparam,
deftimeformat, smpteformat, clockformat, npt-sec, frametime, datetime.
In the HTTP spec, things are also re-used across different sections
and not re-defined.

As for re-using some of the things from the HTTP spec: I have
referenced where they come from, so that should be covered. But you
are probably right in that I should add them to the condensed scheme
in the appendix - as Yves has done for the URI spec - with a reference
there. I'll do that now- it's not difficult.


> 2- Is the problem of introducing the new header "Content-Range-Mapping" fixed ? Was raised in : http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0155.html

Still waiting for feedback and an explanation from Yves there.


> 3- Wouldn't it be useful to allow: Range : "include-setup" ?
> Currently at least one fragment-range has to be provided.
> Otherwise, fragment specifier could be formulated as :
> fragment-specifier  = "include-setup" | fragment-range *( "," fragment-range ) [ ";" "include-setup" ]
> This also applies to Content-Range-Mapping.

Yeah, I guess that is part of the different error cases we discussed
in the last phone meeting. I will include this, too.


> 4- In the different xxx-mapping-options, shouldn't we let the possibility to put "/*" (or "/*-*") at the end, in case the start/end durations are unknown or the server couldn't get them ?

Make them optional? Yup, can do.

Thank a lot fo the thorough reading!

Cheers,
Silvia.

Received on Thursday, 20 May 2010 09:06:08 UTC