The W3C TAG meeting I attended in Boston went better than expected. I got to meet the rest of the group and we discussed a variety of interesting topics without ever getting too far into lalaland (although the Polyglot Markup discussion was pushing it). I did think it was a bit too formal, though fortunately Jeni and Tim supplied a healthy dose of comic relief.
I thought I would outline some of what we discussed here and quickly jot some thoughts down for further reflection later:
Authoritative Metadata: We know that the most popular user agents out there are not respecting this finding. We know that the HTML Standard is not respecting this finding. We know that developers do have not sufficient control over their server, even now (one of the issues with httprange-14, CORS, CSP, deploying new formats such as WebVTT). While authoritative metadata may be good in principle (and I think that in retrospect for Content-Type file signatures would have worked just as well with a safe fallback), it has not worked out in practice. We should at least indicate in the finding that what it requires is not what is practiced.
Capabilities: Over dinner we discussed URLs to a particular resource where the access rights to that resource were part of the URL itself by means of a token in the path and the various implications of using that over a more traditional access control list model. E.g. whether we should have an HTTP header that indicates part of the URL should be hidden just as we hide passwords today. Jeni is currently sole keeper of these notes, but they should be public soon. (This was part of a larger discussion on Web Intents, Web Activities, and unhosted.org.)
DRM: One contentious bit of standardizing DRM is that it standardizes the API to talk to the black box, but the black box is not standardized and will likely end up being highly proprietary. An argument in favor of standardizing DRM that has been made is that when we standardized the video element we also standardized the API and left the black box (the codec) as an open question for which we eventually found WebM as an acceptable solution. (Of course WebM is not universal so whether this is completely okay is to be seen still unfortunately.) As a corollary, standardizing the API for the DRM black box will bring more content out of plugins and may at some point lead to a standardized black box (presumably then a white box). A counter argument goes that while everyone would be happy with a open codec, not everyone would be with W3C-blessed DRM. And that even while you could envision an “open” black box, nobody would use it because it does not provide the protection deemed necessary.