Re: MSE and in-band track registries

[dropping public html]

On 06/06/2014 07:40 PM, Aaron Colwell wrote:
> Hi Sam,
>
> Comments inline...
>
> On Fri, Jun 6, 2014 at 1:33 PM, Sam Ruby <rubys@intertwingly.net
> <mailto:rubys@intertwingly.net>> wrote:
>
>     After initially recommending that In-Band registry follow the lead
>     of MSE, the co-chairs discovered three problems.
>
>     The first, and most easiest to solve, is that we don't have a
>     lightweight process for updating dated specifications published on
>     the web site.  This is the subject of an open bug on MSE[1].
>
>     The second is that the registry points to W3C specifications with
>     MUST requirements, and these specifications themselves have not gone
>     through the IPR process.  While this was previously overlooked, now
>     that it is known it will need to be cleared with the Director.
>
> What IPR issues do you expect here? These specs simply put constraints
> on what structures can exist in existing container formats and define
> how structures in the bytestreams map to MSE concepts. Don't the IPR
> issues only come into play if someone tries to implement a specific format?

Perhaps the Director will come to the same conclusion.  But the same 
argument you are making could apply to other format; perhaps even HTML. 
  Or canvas.  Or longdesc.

There is an IPR process for specifications at the W3C.  We are trying to 
figure out a rationale as to why these specifications shouldn't follow it.

>     Presuming that is OK with the Director, we will need to ensure that
>     no reference from MSE or HTML 5.0 to the registry does so as a
>     normative MUST.
>
> Why? The intent of the registry is to mandate required mimimal behavior
> for specific byte stream formats. An implementation does not have to
> support all of the formats in the registry, but if it claims to support
> one of the specified mimetypes, then it must do so according to the
> requirements in the byte stream format spec. This is intended to
> facilitate interoperability.

Facilitating interoperability is a valuable goal; but it is also a goal 
that is not one that is necessarily mutually exclusive with RF Licensing 
or the W3C Patent Policy.

>     This lead us to conclude that the "microformats wiki
>     existing-rel-values page" reference in HTML5 Section 4.8.4.14
>       "Other link types" [2] was a better example to follow.  This
>     material is characterized by the following characteristics:
>
>     a) the referenced material is on a wiki which makes it easy to update,
>     b) the reference to the registry (wiki) itself is Informative,
>     c) the referencing text uses the MAY term when pointing to the
>     material in the registry (wiki)."
>
>     This leads to the following recommendations:
>
>     MSE:
>     1. Change the text in Section 12 to use MAY (or at most SHOULD)
>     instead of MUST.
>
> The musts are there to ensure that the byte stream format specs contain
> the necessary information and constraints to be useful in the MSE
> context. Weakening these statements makes it difficult to determine
> whether the specs meet the minimum bar for usage w/ MSE.

It is exactly this line of reasoning that may cause the Director to 
conclude that these are specifications with normative requirements that 
need to go through the full W3C process.  Or may not.

>     2. Keep the MSE reference to the registry as Informative rather than
>     Normative.
>
> This is a noop right?

Right.

>     3. Move the registry itself [3] and its referenced documents to wiki
>     pages (thus resolving bug 25581), and update the MSE specification
>     to point to the new registry wiki page.
>
> This came up in the original CR meeting and it was deemed that the wiki
> wasn't "versioned/stable" enough which is why we had to snapshot the
> documents at CR time. Does this mean that opinion has been reversed? If
> so, then why is a wiki better than simply using the Mercurial repository
> where the editor's draft version of the registry lives today?

Note that what I described was a recommendation.

I'll also note that but 25581 isn't resolved:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25581

I'll also note that the Candidate Recommendation for MSE 
[http://www.w3.org/TR/media-source/] doesn't point to hg, but instead to 
a stable snapshot:

[REGISTRY]
     Aaron Colwell Media Source Extensions Byte Stream Format Registry. 
02 December 2013 URL: 
http://www.w3.org/2013/12/byte-stream-format-registry/

---

Finally, I'd like to unwind the stack.  In-Band track registries faces 
the same problem.  The chairs started out recommending that they follow 
MSE's lead, but in the process identified some concerns that we (in 
conjunction with PLH) feel require the Director's input.  While we don't 
yet have that input, we thought we would share some recommendations that 
may produce a more successful outcome.

>   Aaron

- Sam Ruby

>     In-Band:
>     1. Ensure that all references to the registry use MAY (or at most
>     SHOULD) instead of MUST.
>     2. Keep the reference as Informative.
>     3. Move the registry itself[4] to a wiki page, and update the HTML5
>     specification to point to the new page.
>
>     We believe the In-Band changes can be done during the upcoming HTML
>     5.0 LC.
>
>     Should the Director not be OK with the specs pointed to by the
>     registries containing MUST statements, we will determine how to
>     proceed based on the input the Director provides at that time.
>
>     - Sam Ruby,
>     on behalf of the HTML WG co-chairs
>
>     [1] https://www.w3.org/Bugs/__Public/show_bug.cgi?id=25581
>     <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25581>
>     [2] http://www.w3.org/TR/html5/__links.html#concept-rel-__extensions
>     <http://www.w3.org/TR/html5/links.html#concept-rel-extensions>
>     [3] http://www.w3.org/2013/12/__byte-stream-format-registry/
>     <http://www.w3.org/2013/12/byte-stream-format-registry/>
>     [4]
>     http://rawgit.com/__silviapfeiffer/__HTMLSourcingInbandTracks/__master/index.html
>     <http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/index.html>
>
>

Received on Saturday, 7 June 2014 00:44:47 UTC