- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 15 Jun 2010 15:39:55 +0200
- To: public-device-apis@w3.org
Le mercredi 09 juin 2010 à 17:15 +0200, Robin Berjon a écrit : > The draft can be read at: > http://dev.w3.org/2009/dap/policy/Framework.html My comments below, the most important ones prefixed with "**" * I would recommend changing the title to "Policy Framework for Device APIs" * the abstract could use some fleshing out * the introduction talks about the status of the document, which it shouldn't; that's what the status of the document is for :) * 2.2.2 refers to "all JavaScript APIs exposed by the Web runtime" — I'm fairly sure we aren't actually considering all JavaScript APIs, but only a subset of them that would need to be qualified ** 2.2.2 refers to "features identified uniquely by URI", but doesn't define what constitues a feature, nor how/where features URIs are defined; I remain convinced that this should be our first step before specifying a framework on top of that concept http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0169.html * 3.1 "website-bind" make a reference to "requestFeature()" — I don't think that's defined anywhere * 3.2 says "subject attributes are determined for the applicable application execution phases: widget-install, widget-instantiate" — that doesn't say anything about how this applies to web sites * 3.2.1 should probably reference normatively "Digital Signatures for Widgets" http://www.w3.org/TR/widgets-digsig/ * 3.2.1 uses "widget-attr:name" as an attribute name, which seems to suggest a "widget-attr" namespace prefix that isn't defined * 3.2.2 doesn't define attributes based on the web site certificate itself, only on the root certificate — that seems much more limited than what the widget attributes allow * uri-top in 3.2.2 should probably have a normative ref to http://www.w3.org/TR/widgets-uri/ * as previously noted param:name uses an undefined "param" namespace prefix; ** the examples in http://dev.w3.org/2009/dap/policy/Examples seems to assume that param:name is actually going to be used as e.g. param:recipients when there is a "recipients" parameter; reading the current table, I was thinking this would be param:name="recipients" — which is it? and if the latter, it would be good to see the rewritten examples to get an idea on how the premium number abuse cases would actually be handled; if ther former, this should be clarified * 3.3 the feature-* attributes seem quite far fetched; * 3.4 It's mildly inconsistent that sysinfo doesn't distinguish between roaming/international while the roaming environment attribute does; but that's probably not a big deal ** 3.4 makes a reference to DCO for bearer-type; that seems to make DCO a normative reference, and given that the chances of this work going forward seem rather low, this is likely problematic; beyond that, I don't know how to interpret "one or more of the bearer types given as examples in W3C DCO" even after having looked at the DCO spec * 3.4 the environment attributes seem rather ad-hoc, and very mobile-specific; * there should be somewhere presumably a reference to the XACML profile doc ** the document doesn't have a conformance section, which makes it hard to assess what is supposed to conform and how; also, there doesn't seem to be any conformance requirements in that document, which is somewhat unexpected for a normative Rec-track document. Dom
Received on Tuesday, 15 June 2010 13:40:03 UTC