W3C home > Mailing lists > Public > public-appformats@w3.org > October 2006

Re: [AC] proposal on how to move forward

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 29 Oct 2006 01:35:19 +0200
To: Brad Porter <brad@tellme.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-id: <op.th5ns5o264w2qv@id-c0020.oslo.opera.com>

On Sun, 29 Oct 2006 00:49:21 +0200, Brad Porter <brad@tellme.com> wrote:
>> [...]
>
> The problem with letting other specifications define how to use the  
> mechanism is that unless we specify some way to specify  
> access-control-for-function-X, then two specifications might declare two  
> different purposes for the header which conflict.
>
> For instance, a specification might say "if access-control is deny for a  
> document to be displayed in a sub-frame, the contents of that document  
> must not be displayed in the sub-frame."   Another specification might  
> say "if access-control is deny for a document to be requested by  
> XmlHttpRequest, the contents of that document must not be parsed and  
> made available to the application."
>
> As an author, if you want to allow your content to be displayed as a  
> sub-frame, but not allow your content to be accessed via XmlHttpRequest,  
> what do you do?

I don't really see what the use case is for that, actually. Also, the  
specific examples you cite don't really seem to match the real world.


> As I said, I could go either way, but if we just want to say "this is a  
> mechanism independent of function, here you go, you must specify the  
> functional behavior in its context", then I think we need to enable a  
> way to say "access-control-for-function-X". Currently, the specification  
> states "

Was something dropped here?


>>>> [...]
>>
>> In the case of <img src=""> the whole access control policy probably  
>> doesn't apply at all. (Unless you want it and in that case you'd have  
>> to define that in the relevant specification...)
>
> Right, I'm suggesting we either want to consider those potential use  
> cases, or we should state that this is not intended for that purpose and  
> it isn't appropriate to reference/use this mechanism for anything other  
> than XML-read

I'm suggesting it's out of scope. I don't think we should try to tackle  
all potential use cases and their respective problems. If we want to go  
there, fine, but I think it will take a lot of time to come up with all  
the potential scenario's and how they apply to those. Not to mention that  
it wouldn't address anything for new specifications.


>> I suppose that's a valid issue. I'm fine either way so I suggest the  
>> specification says to take both into account and only HTTP for HEAD  
>> requests.
>
> The specification does currently say that rules may be specified in both  
> places and that all rules must be used.  Consequently, the most  
> appropriate reading is that HEAD-only requests are insufficient to make  
> a determination.  Do we have a use-case for HEAD-only requests?

Checking if the document exists without having to download the whole  
document. Not sure what you mean with "HEAD-only" by the way...


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Saturday, 28 October 2006 23:36:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC