- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 12 Dec 2007 13:55:29 +0100
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "public-appformats@w3.org" <public-appformats@w3.org>
On Wed, 12 Dec 2007 12:21:23 +0100, Williams, Stuart (HP Labs, Bristol) <skw@hp.com> wrote: >> I tried making it a more clear by talking about "Web page" and "image" >> and "data of a resource" which seems more in line with AWWW while >> remaining >> relatively easy to read and understandable to myself. :-) I hope that >> helps. > > I'll review again in due course. > > A trouble with terms like "web page" and "image" when one is trying to > speak with some precision is that, at least for a "web page" there are > three things that could be being referred to: > > 1) What is rendered to the user on the screen - a visual presentation of > what was transferred over the net. > 2) The bits transferred (an HTML serialisation) - a > webarch:Representation. > 3) The web page in an abstract sense, a webarch:Resource, which could > have multiple representations (of the same page - .PS, .PDF, .HTML....). > > It is easy to write narrative where it is not clear whether one is > speaking of a "web page" in with as webarch:Representation kind of a > thing, or a webarch:Resource kind of a thing and it is easy to slide > between the two senses. /me has done it. I think it is clear enough for the introduction, but if you have doubts after reviewing the text again I guess we can change the text. >> The idea is that a Web page on domain A can use an image on domain B by >> means of <img>. The draft now clearly states this. > > Ok... though I guess that has always been the case with the web - eg. > Norm regularly uses flickr hosted images in his blog pages. Correct. Some types of cross-site requests are allowed and some are not. > I wasn't aware of there being enforced cross-site restrictions in such > usages or that they are a particlar design centre for this work. <img> is an example of something that already allows cross-site requests. >> Cross-site requests in the draft are not restricted to scripting. For >> instance, attaching cross-site XBL bindings does not have to involve >> scripting. > > I'm afraid I am largely ignorant of XBL :-(, but I take its as away of > binding things (including behaviours) to the presentation of a > document/web-page. > > I don't understand how a client would discriminate between references > that it would subject to access controls and those that it would not. That depends on the specification that defines the technology. XMLHttpRequest Level 2 defines for instance that for non same-orign URIs (basically comparing scheme, ihost, and the port component of the URI) you have to follow the algorithms defined by this specification. >>> 2) Re: 4.3 <?access-control?> PI >>> >>> The 2nd para has not been fully updated to cover the addition of the >>> "method" pseudo attribute. eg. three->four and the value of a "method" >>> is *not* an "access item". >> >> Actually, it is. It talks about three attributes of type X and one >> attribute of type Y. > > Mostly my bad re counting (doh!), though: > > "If an attribute is specified it must at least contain an access > item." > > could be a little tighter since the "method" pseudo attribute does not > convey an "access item". Fixed. >> Would moving this down help? Similarly to your suggestion for the >> processing model algorithm? > > I think so... ie 'unfolding' algorithm from it's top-level down it's > leaves. Done. >> Step 5 is not an otherwise clause. I'll assume that was a mistake. > > I was referring to the "Otherwise" clause at the *end* of step 5. The > para immediately before the section 5.2 heading: > > "Otherwise > Perform an access control check using the request method as > method. If it returns "fail" > remove the cache entry, then terminate this algorithm, and > return with the status flag > set to "network". Otherwise, if it returns "pass", terminate > this algorithm and return > with the status flag set to "success". Do not actually terminate > the request." Ah, I see. >> The access policy protects the information that is part of the response. >> The request itself is protected by the authorization request that is >> made before this one (or the authorization request cache). > > FWIW I think I'd agree that except around the the time of a change in > access policy the algorithm one should never reach this point. The > authorization check should prevent the networked operation happening in > the first place. The authorization request could return something different from the actual request. Now that is likely to be a mistake, but to be on the safe side it is better to not expose the data in that case. >> Yes, I agree it is kind of tricky. I can move the section around if that >> would make it better and maybe include your steps below as an >> informative guide to the algorithm. Would that help? > > I think so... the numbered 'statement' that I offered where (my) attempt > to capture what the algorithm is designed to accomplish - ie. they are > intended (roughly) > as a declarative (though possibly flawed) expression of what the > algorithm is > supposed to do rather than a set of procedures to follow - ie. they are > intend as factual or truthful assertions about the algorithm, not an > imperative process. I agree that it looks nicer, but I'm afraid to introduce errors using that kind of style. > Personnally, I think that such an expression (corrected if necessary to > accurately capture the design intent) is a powerful tool. It can provide > a basis on which to create test cases and to judge whether access > should/should not be denied so that > the algorithm itself as well as it's implementation can be road-tested. > In fact, without such an expression there really is no way to judge > whether the algorithm does what is required of it (because it isn't > stated). It is very clear what is required as the algorithm states that exactly. Writing tests against this also isn't too hard. I suppose it depends on what you're used to. Kind regards, -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Wednesday, 12 December 2007 12:54:53 UTC