W3C home > Mailing lists > Public > public-html-media@w3.org > June 2014

Re: MSE and in-band track registries

From: Aaron Colwell <acolwell@google.com>
Date: Thu, 19 Jun 2014 08:42:09 -0700
Message-ID: <CAA0c1bCjvzDxqg_PXky9abqO6O0b-yosdUz99H4Yh6i749jP1Q@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
Hi Sam,

I just remembered I forgot to respond to this. This plan sounds good to me.


On Mon, Jun 9, 2014 at 10:36 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> Sorry for top-posting, but my experience is that better outcomes with
> meetings such as the one we anticipate will happen with the Director are
> produced when there is a concrete proposal going into the meeting.
> There are three basic parts here.  MSE is clear; and has gone through
> FPWD, and gone into CR; and is intended to become a Recommendation, so the
> patent process clearly applies here.
> On the other side of the registry is documents which contain MUST
> statements (even if spelled with a lower case).  The IPR status of these
> are unclear.
> In the middle is a registry.  Currently it is a dated document, and points
> to stable references.
> The sum-total here is sub-optimal from a number of perspectives.
> Based on what I hear from your input, it sounds to me that an easier case
> to sell to the Director would be one where the individual byte stream
> formats DO go through the process; and we focus on the making the case that
> the registry does NOT go through the process.
> Put another way, all of the specifications that contain normative
> statements become Working Group Working drafts; but the registry which
> helps you find these specifications is not.  The dated copy of the registry
> would be marked as obsolete; and the hg master becomes the stable URL
> (actually, I would suggest that "cleaner" URL be minted that redirects to
> hg, but that's a detail).
> Thoughts?
> - Sam Ruby
> On 06/09/2014 12:56 PM, Aaron Colwell wrote:
>> 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
>> <mailto: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>
>>         <mailto: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
>>                "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
>>              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
>>     <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/
>>     <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/
>>     <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
Received on Thursday, 19 June 2014 15:42:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:03 UTC