RE: CfC: Policy Framework FPWD

 
Hi Dom,

Firstly, thanks for your comments. I have taken into consideration most
of your points and already made some changes to the Policy Framework
document. This is a link to the latest version:
http://dev.w3.org/2009/dap/policy/Framework.html

Please find my comments inline marked with [LAURA] tag.

* I would recommend changing the title to "Policy Framework for Device
APIs"
[LAURA] Agree - done.

* 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
[LAURA] "all" deleted. Does this make it clearer?

** 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
[LAURA] I have added definitions for features and device capabilities at
the beginning of section 2.2 (Layer Model). Besides, I've also made some
changes in to section 2.1 (Framework Overview). Please have a look at
the changes and let me know any suggestions you may have.

* 3.1 "website-bind" make a reference to "requestFeature()" - I don't
think that's defined anywhere
[LAURA] I've raised and issue for this. BONDI defines a
"requestFeature()" API, which is itself a feature and allows
programmatic expression of API dependencies. As it is stated in BONDI
(pages 38-39): "Websites have access to this API automatically and this
is the sole means of expression of feature dependencies by websites".
So we need to make a decision whether we want to include this feature in
the policy framework for device APIs. If, as it is the case, policy
should also be applicable for websites, we may need to define
"requestFeature()" as well. What do you think?

* 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
[LAURA] Agree - changed.

* 3.2.1 should probably reference normatively "Digital Signatures for
Widgets" http://www.w3.org/TR/widgets-digsig/
[LAURA] Reference to the latest version of the spec is missing in the
references database of ReSpec. I need to add this reference.

* 3.2.1 uses "widget-attr:name" as an attribute name, which seems to
suggest a "widget-attr" namespace prefix that isn't defined
[LAURA] Good point. I would suggest deleting the "widget-attr" namespace
prefix and just left "name". However, I also understand that having the
prefix  is good for clarification. I am not sure how/where this prefix
should be defined. Could you/anyone help out there?

* 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/
[LAURA] Reference to the latest version of the spec is missing in the
references database of ReSpec. I need to add this reference.

* as previously noted param:name uses an undefined "param" namespace
prefix;
[LAURA] Agree - In this case I think we need to define this 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
[LAURA] My interpretation was the former one, thus,
param:recipients="...". I have changed the "Value" field in the table.
Let me know if the usage of this attribute is not clear yet.

* 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
[LAURA] I agree it is not clear what it's meant in the document. In this
older version of the DCO we can see some examples of Bearer Types
(http://www.w3.org/TR/2007/WD-dcontology-20071221/#Network-bearer-exampl
es), but this is not the case in the version that is referenced in the
spec (http://www.w3.org/TR/2009/WD-dcontology-20090616/). I see the
functionality of these attributes in the mobile world, but we may need
to create policy examples that use environment attributes to prove the
use cases. We may need to decide if we want these attributes (in my
opinion, we do) and if so, we need to agree on how to represent their
values if refering DCO might be an issue.

* 3.4 the environment attributes seem rather ad-hoc, and very
mobile-specific;
[LAURA] Covered in the previous point.

* there should be somewhere presumably a reference to the XACML profile
doc
[LAURA] Agree - I haven't added the reference in the version attached in
this e-mail but it's coming... :)

** 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.
[LAURA] I've created a Conformance section, with no content still. I'm
not sure we have many "must" statements in this document as James
Salsman suggested, by I take his proposal.


Thanks again,
Laura

Received on Friday, 18 June 2010 15:09:23 UTC