Re: Feedback from FOMS

On Thu, Jan 28, 2010 at 11:48 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 27 Jan 2010 23:38:39 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Wed, Jan 27, 2010 at 11:54 PM, Philip Jägenstedt <philipj@opera.com>
>>>
>>> My main point is that right now there are no conformance requirements, so
>>> it's impossible to test if a browser "supports media fragments" at the
>>> HTTP
>>> level, which 5.2.1 is about. If no-one objects, I'd like to mark 5.2.1
>>> and
>>> 5.2.2 non-normative unless there are testable requirements. (Note though
>>> that I don't believe it's very meaningful to define the requirements in
>>> terms of HTTP, but rather think it should be in terms of playback
>>> behavior.)
>>
>> I find the topic of non-normative vs normative a bit hard to grasp.
>> How does the URI spec become normative or non-normative?
>
> Presumably each spec can decide what is normative and what isn't, but I
> think all content in MF URI is normative unless it is explicitly marked
> otherwise (example, informative, etc). This is my assumption anyway, and why
> I marked some quite vague sections with "Note: This section is
> non-normative".
>
> What I would like is more clear requirements and less "specification by
> example" (examples are useful, but should be marked as such). Right now,
> 5.2.1 and 3.2 to which it refers is most in need of this, since they *only*
> contain examples and no requirements as far as I can see. If we want to
> require HTTP byte range requests to be used (rather than being protocol
> agnostic, which I would prefer) then a reference to the spec for HTTP byte
> ranges would be in order, for example.

It already has such as reference "In this case, the HTTP exchanges are
exactly the same as for any other Web resource where byte ranges are
requested [RFC 2616]." All the examples are only there to illustrate
the key points. In theory they are not required. Nothing wold need to
be stated other than the two first sentences: UA knows how to map the
URI fragments to byte ranges, see HTTP protocol. This part is
normative - the rest illustration.

I think we need to keep one thing in mind: the media fragment URI
specification is all about specifying a URI syntax - the rest is just
recommendations on how to resolve it. Nothing beyond the syntax is
really normative. It's just like the URI spec
http://www.ietf.org/rfc/rfc3986.txt, which also only specifies a
syntax and describes how to interpret it - nowhere is the word
normative mentioned there.

In fact, the whole media fragment spec could be reduced to section 4.
In practice that doesn't help anyone because it doesn't explain
expectations and how it should work with the existing Web. But it's
really all we have been chartered for.

> Finally, since we intend for other specs to refer to this spec, we also need
> to have clear hook definitions they can reuse and should also write an
> example of how other specs can refer to ours, unless it's obvious (it isn't
> to me at this point).

It's all about section 4 IMHO. You've already numbered through all the
production rules so IMHO that's already given.

I'm still struggling to see what you think is missing. You may well be
right, but I haven't really grasped what gaps you have identified. I
think there is enough there for people to know how to implement media
fragment URIs (once finished). No?

Cheers,
Silvia.

Received on Thursday, 28 January 2010 21:29:15 UTC