Re: MSE and in-band track registries

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 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
>     <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 Monday, 9 June 2014 17:37:20 UTC