Proposed updates to Pending and Raised ISSUES, suggest "API Requirements and Design Decisions" document

I propose that the "API Requirements" document be renamed  "API Requirements and Design Decisions", and that we record in it  major design decisions (including the choices and rationale). This should allow recording resolution of ISSUEs in a meaningful way for later explanation. If we agree then I suggest Dom make this change as part of his ACTION-281. 

The following is a summary of ISSUES that we can consider closing (or in one case re-opening): 

(A) The following issues is marked as pending  but we may wish to  combine them and  have an open action to document cross-API security threats, countermeasures and  requirements as well as relationship to identity management and other work that is relevant to our work.

ISSUE-19 html5SecurityModel	PENDING REVIEW	What are key HTML 5 security model considerations that impact DAP Policy language and framework	2009-09-21	Security Policy Framework — General	

ISSUE-20	PENDING REVIEW	What are essential requirements for DAP security and policy	2009-09-21	Security Policy Framework — General	0

The following issues are also marked as Pending.  

(b) Requirements:

ISSUE-7 CalendarReq	PENDING REVIEW	Gathering requirements - calendar	2009-08-25	Calendar API	0

ISSUE-8 CameraReq	PENDING REVIEW	Gathering requirements for Camera API	2009-08-25	Capture API	0

ISSUE-10 ContactsReq	PENDING REVIEW	Gathering requirements for Contacts API	2009-08-25	Contacts API	0

ISSUE-11 FilesystemReq	PENDING REVIEW	Gathering requirements for FileSystem API	2009-08-25	FileSystem API	0

ISSUE-13  MessagingReq	PENDING REVIEW	Gathering requirements - messaging	2009-08-25	Messaging API	0

ISSUE-14 SysinfoReq	PENDING REVIEW	Gathering requirements for System Information and Events API	2009-08-25	System Information and Events API	0

[fjh]  We should close these issues as Dom has ACTION-281 to review and update the API Requirements draft  (dated from 2009).

http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/

(c) Policy Framework:

ISSUE-24 PENDING REVIEW	Policy, need to define semantics of capabilities or not	2009-09-30	Security Policy Framework — General	0

ISSUE-28 noModalPrompt	PENDING REVIEW	Requirement for NO security prompting	2009-10-06	Policy Framework Requirements	0

ISSUE-29 apiKeys	PENDING REVIEW	Should DAP APIs support "API Keys"	2009-10-07	Policy Framework Requirements	0

ISSUE-30 federatedIdentityReq	PENDING REVIEW	Is support/integration for federated identity required, e.g. OpenId, OpenAuth, SAML etc	2009-10-07	Policy Framework Requirements	0

ISSUE-31 callbackEventsPolicyReq	PENDING REVIEW	What are the special DAP policy requirements and issues elated to events and callbacks, if any	2009-10-07	Policy Framework Requirements	0

ISSUE-36 domainBasedTrust	PENDING REVIEW	How far can we go with domain based trust model given constraints of HTML5 security model	2009-11-02	Policy Framework Requirements	0

ISSUE-83 warp	PENDING REVIEW	Note relationship of WARP to DAP policy work	2010-04-28	Policy Framework

[fjh]  I suggest these can be closed given our decision not to progress a policy framework

(d) ReSpec

ISSUE-61	PENDING REVIEW	Enable note regarding Reference versions	2009-12-23	ReSpec	0

[fjh]  This is in use by XML Security WG. It can be closed.

(e) General API Mechanisms

ISSUE-1 param-style	PENDING REVIEW	Pick parameter passing style (list or object)	2009-07-29	APIs — General	0

[fjh]  Dom notes duplicates ISSUE-55 so we can close...

ISSUE-2 error-handling	PENDING REVIEW	Error handling style	2009-08-25	APIs — General	

[fjh]  Dom notes "using error callbacks when using callback-based APIs" - I suggest this should be documented in the renamed "API  Requirements and Design decisions" document as Part of Dom's ACTION-281

ISSUE-42	PENDING REVIEW	Able to use of MMI for user interactions	2009-11-02		0

[fjh]  Is this an issue of allowing user interactions to occur other than via browser windows? If so, wouldn't that be a generic issue for all browser interaction, thus beyond being a DAP issue?

(f) The following ISSUES are marked as RAISED, but I think we can close them now as moot given the direction of the WG:

ISSUE-18 compareSecurityStartingPoints	RAISED	Determine security policy starting points for review and comparison	2009-09-21	Security Policy Framework — General	0

ISSUE-21 FeaturesCapabilities	RAISED	Is policy/access control on both features and device capabilities needed, do all submissions include both of these	2009-09-23	Policy Framework Requirements	0

ISSUE-23 defaultPolicy	RAISED	Should policy framework support notion of default policy?	2009-09-29	Security Policy Framework — General

ISSUE-35 deadlockPolicy	RAISED	How to handle malformed policies, policy validity and intentional abuse of policy? How is policy deadlock handled? e.g. Only dial +39 numbers + Never dial +39 numbers	2009-11-02	Policy Framework

ISSUE-94 powerboxPolicy	RAISED	How do Powerbox and Policy interact and integrate	2010-07-15	Policy Framework

ISSUE-104 trustedOrCurated	RAISED	Find a better name for "trusted environments"	2010-11-04	Policy Framework

[fjh]  These are from early work on policy framework and I suggest we close them as moot.

(g) I also suggest we move all remaining  "RAISED" issues to "OPEN" and not use the "RAISED" category going forward.

Comment? Hearing nothing on the list or at this week's call I suggest we then close the ISSUES as noted before next week's call.

regards, Frederick

Frederick Hirsch, Nokia
Co-Chair, W3C DAP Working Group

Received on Tuesday, 4 January 2011 01:17:13 UTC