- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 17 Jan 2008 11:32:18 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
Anne van Kesteren wrote: > > I was surprised that a large number of issues is still open. An attempt > to get some closed. > > > ISSUE-4 http://www.w3.org/2005/06/tracker/waf/issues/4 > > I don't think we need this distinction and I already replied to the > relevant comment. The specification is clear enough on this point. Agreed. > ISSUE-5 http://www.w3.org/2005/06/tracker/waf/issues/5 > > We have both black- and whitelisting for the following reaons: In case > the server and documents hosted on the server are in control by > different people it is necessary that the server people are able to > override the document people (if the document wants to share access) and > vice versa (if the server wants to share access). > > I suggest we close this issue because there's a good reason to have the > deny rule. Black lists are required to satisfy point 7 from [1] > ISSUE-11 http://www.w3.org/2005/06/tracker/waf/issues/11 > > The specification states: "User agents may optimize any algorithm given > in this specification, so long as the end result is indistinguishable > from the result that would be obtained by the specification's > algorithms." This seems clear enough to me. I suggest we close this issue. Agreed. > ISSUE-16 http://www.w3.org/2005/06/tracker/waf/issues/16 > > I have added more information to the introduction. Together with the use > cases and requirements document/appendix I think we'll cover this > adequately. I suggest we close this issue. Yep, the requirements doc satisfies this I think. > ISSUE-20 http://www.w3.org/2005/06/tracker/waf/issues/20 > > I think the current model is adequate and leaves the server in control > at all times. It has been explained on the mailing list why we have this > model by Brad and Ian mostly so I think we can close this issue. This is required by point 3 in [1]. Also, the client already is a PEP on he web today, as well as in all other proposals I've seen (such as JSONRequest) > I'm not sure what to do with ISSUE-21. It's not concrete enough to do > anything with and as far as detailing what needs to be done for security > I think that's already covered. I suggest we close this one. ISSUE-19 > will be dealt with when we publish the requirements document/appendix. I think [2] describes the threat model. If it's unclear we can expand it. [1] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0193.html [2] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0195.html
Received on Thursday, 17 January 2008 19:32:30 UTC