Re: MSE and in-band track registries

Hi Sam,

Thanks for the comments. I have a few more comments/questions inline.


On Fri, Jun 6, 2014 at 5:44 PM, Sam Ruby <rubys@intertwingly.net> wrote:

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


Ok. I see. If they do, my hope is that the process isn't too heavy weight.
It would be sad if this ended up being a disincentive for people to
contribute and register new byte stream formats.


>
>
>      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.
>
>
Ok. Perhaps I am misunderstanding something. The MUSTs just put
requirements on the contents of acceptable byte stream spec documents and
tries to ensure that if a UA claims to support something in the registry
then it MUST follow the requirements within that document. I think I see
how the byte stream specs can come under RF & patent policy restrictions.
I'm a little unclear on how specifying the requirements for the contents of
other documents does though.


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


Ok. I think I see. My intent here was just to point out that these sections
were just intended to provide rules for the contents of the formulation of
byte stream format specs. I understand that this is a somewhat murky area.
My intent in formulating things this way was to make it more difficult to
change the rules/requirements for byte stream specs, but make it relatively
easy to submit & collaborate on new formats that might be useful to people.
I understand that there is existing process and we need to determine what
to do in this case, but my hope is that we don't lose sight of the original
intent of this separation.


>
>
>      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 understand. I was just looking for clarification here. I'm just trying to
understand the preference for a wiki vs the version control system I am
already using for spec development.


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


Sorry if I wasn't clear about this. The editor's draft has always pointed
to a registry that is in the Mercurial repository
<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/byte-stream-format-registry.html>.
This reference was changed, when the CR document was generated, to the
location you provided above because it was determined that a "more stable"
reference was needed. I was just trying to determine if linking to a
version in the Mercurial repository, like the editors draft does, would be
acceptable instead of placing this in a wiki.


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

I understand and appreciate this. I was just trying to understand things
better and make sure it was clear why I made things the way they are. My
hope is we can find a way to preserve the original intent and comply with
the established processes. I fully admit I don't completely understand all
of the W3C process and appreciate your help.

Aaron