- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 15 Jun 2010 14:42:48 +0200
- To: public-device-apis@w3.org
Le mercredi 09 juin 2010 à 17:07 +0200, Robin Berjon a écrit : > The draft can be read at: > > http://dev.w3.org/2009/dap/policy/Profile.html Some comments on the draft — I'm not sure if they should be considered as blocking for publication as FWPD; some of them are quite important, I think (prefixed with **); my feeling is that most readers would be entirely lost when trying to read that document and understand how and if it apply to something relevant to them. * I think the title needs to be changed at least to "XACML Profile for Device APIs Policy" (rather than "Device API Policy Profile: XACML"), but an entirely different title might be in order * the abstract needs a better explanation than "a policy framework for device APIs" ** the document is called a XACML profile, is said to use XACML20, but there is absolutely no explanation as to what this means in practice, what are the difference with XACML 2.0 or how it relies on it; I guess some text from the framework could be moved to it or re-used, but I think some more explanation on the relationship would be needed in any case * the start of the document is very abrupt, with very little context to understand e.g. 2.1. "Values and Types" * the definition of the syntax for encoding certificate fingerprints isn't linked with anything, and the words "certificate" and "fingerprint" don't appear anywhere else in the document * the intro talks about the status of the document ("This document is an editors draft...") — that should be removed * there should be (presumably) cross-references to the Framework document ** having examples would help making the document readable * 2.3 "subject match" seems like a subset of "2.2 attribute match", and as such should probably be a sub-section of it; also, it's not clear why "subject match" need its own section when "resource match" and "environment match" don't * 2.11 "Signed Policy Document" is so vague about what a signed policy is that it's pretty much useless * The functions defined in 2.12 don't have actual names attached to their definitions; they seem to be defined as "equal", "glob", "regexp" in 3.1.8, but it seems it would be useful to add their names along with their definitions * in 2.12.1, "Thus an empty bag is not equal to anything" — the logical connection of the "thus" is not entirely obvious to me * defining the names of the modifier functions defined in 2.13 would be useful * the conversion from string to URI should probably mention normalization/canonicalization considerations * a normative reference for the URI components to the URI RFC would be seem to be in order * in 2.13.3, "Each URI in the bag is converted to a string by taking the URI’s scheme and authority components" - should this be "converted to a string bag"? if not, it's not clear to me how the two strings are supposed to concatenated ** the effects defined in 2.15 assume that prompts are the end game of the policy framework, when most of our work in APIs has been to avoid these prompts; does this means that the policy framework will only be used for APIs calls that would actually require prompts? * the definition of session, both for widgets and Web sites, seem rather brittle; the definition of sessions for Web sites should probably be aligned with the one in sessionStorage http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute * 3.1 "schema" would be usefully completed with an actual schema (XML Schema or RelaxNG) * 3.1 doesn't give any guidance on how an implementation would deal with documents that don't follow some of the rules defined in the schema ** the document doesn't have a conformance section, so it's really unclear what kind of tools and products are expected to conform to that spec, if there are several level of conformance, etc ** I'm concerned about the risk that this part of the work find willing implementers — interchange of declarative policy decisions doesn't seem to be widely asked for at this time, and most similar projects seem to focus purely on a manifest approach, leaving policy decision to another layer. I'm raising this now since this clearly informs the discussion on whether the scope of the document is appropriate or not; I would at least suggest calling this out in the SOTD or/and in an issue in the document. Dom
Received on Tuesday, 15 June 2010 12:43:07 UTC