- From: Aaron Colwell <acolwell@google.com>
- Date: Thu, 19 Jun 2014 08:42:09 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <CAA0c1bCjvzDxqg_PXky9abqO6O0b-yosdUz99H4Yh6i749jP1Q@mail.gmail.com>
Hi Sam, I just remembered I forgot to respond to this. This plan sounds good to me. Aaron 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 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 Thursday, 19 June 2014 15:42:41 UTC