W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 20 May 2010 19:14:01 +1000
Message-ID: <AANLkTimiA-IZgRHvhLojqu6VjjpCYEI1Wjd0Eyn7Zn89@mail.gmail.com>
To: DENOUAL Franck <Franck.Denoual@crf.canon.fr>
Cc: Media Fragment <public-media-fragment@w3.org>
Forgot to reply to this question:
>> -> npt-sec (only ? not npttime?)

We discussed this earlier and said we would only use one time
specification. We can replace npt-sec with npttime - which would
probably be more accurate. But we said we would not provide a choice
here. What have the implementations done? I'd be happy to include both
if we change our position on this.

Cheers,
Silvia.

On Thu, May 20, 2010 at 7:05 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> 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:14:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT