Re: CfC: Policy Framework FPWD

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