On Wed, 12 Dec 2007 12:21:23 +0100, Williams, Stuart (HP Labs, Bristol)
<[EMAIL PROTECTED]> 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/>
