- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 01 Feb 2008 15:02:01 -0800
- To: "T.V Raman" <raman@google.com>
- CC: jferrai@us.ibm.com, annevk@opera.com, ian@hixie.ch, mnot@yahoo-inc.com, public-appformats@w3.org, tyler.close@hp.com
The latest published Editors Draft includes this, and there has been quite a bit of mailing about it over the past few days. We hope to finalize the requirements at wednesdays conference call. I agree that it is unfortunate that these requirements haven't been formalized earlier. / Jonas T.V Raman wrote: > All of what Jon's nice-to-have will ensure that this spec gets > reviewed appropriately --- having reviewers guess at the intent > is usually a recipe for disaster. > > Jon Ferraiolo writes: > > > > My conclusion after going through various standards efforts that there > > tends to be a better end result when the working group takes some time at > > the beginning to write down and gain consensus on a set of target use cases > > (can be described briefly) and at least a general set of requirements. This > > gets the working group on the same page and allows the public to provide > > early feedback about whether the specification ultimately will deliver what > > the community needs. When I studied the Access Control specification a > > couple of months ago, I attempted to find things that even halfway > > resembled use cases and requirements, couldn't find anything, and then > > attempted to hazard a guess: > > > > * > > http://www.openajax.org/member/wiki/JonFerraiolo_Thoughts_On_W3C_Access_Control#Use_cases > > > > In terms of requirements, it is advisable to have a separate requirements > > document (possibly including use cases) or a separate requirements section. > > I have found that a good format for requirements is to use MUST/SHOULD/MAY > > terminology where the new language MUST do this and the new language SHOULD > > do that. For instance: > > > > * The Access Control mechanism MUST not broaden the attack surface for > > hackers, particularly with regard to CSRF > > * The Access Control mechanism MUST be architected such that servers must > > opt-in to the technology before their data can be accessed from a different > > domain > > * The Access Control mechanism MUST enable retrieval of information from > > other domains that allow such retrieval, and MAY enable posting data to > > other domains. > > * The Access Control mechanism MUST support popular data transmissions > > formats, including both XML and JSON > > etc. > > > > I would very much like to see at least the addition of a use cases section > > at the top of the specification, but it would be nice to also see a list of > > requirements. > > > > Jon > > > > > > > > > > "Anne van > > Kesteren" > > <annevk@opera.com To > > > "Mark Nottingham" > > Sent by: <mnot@yahoo-inc.com>, "Ian Hickson" > > public-appformats <ian@hixie.ch> > > -request@w3.org cc > > "Close, Tyler J." > > <tyler.close@hp.com>, > > 01/03/2008 12:54 "public-appformats@w3.org" > > AM <public-appformats@w3.org> > > Subject > > Re: Comments on: Access Control for > > Cross-site Requests > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 03 Jan 2008 02:26:57 +0100, Mark Nottingham <mnot@yahoo-inc.com> > > wrote: > > > Has the working group gained consensus on this requirements list and > > > documented it? > > > > As far as I can tell the Working Group has always worked with these > > constraints in mind, but we never put them in a document. > > > > > > -- > > Anne van Kesteren > > <http://annevankesteren.nl/> > > <http://www.opera.com/> > > >
Received on Friday, 1 February 2008 23:03:53 UTC