Re: [AC] proposal on how to move forward

All I'm trying to say is that if we're going to represent this as a 
mechanism that specifications can use however they like so long as they 
specify allow, deny, and default behaviors, then we run the potential 
that specifications which both use "Content-access-control" as their 
header might separately define allow, deny, and default behaviors that 
lead to conflicts on the same document.  My example was intended to be 
illustrative.  If we specify that each specification referencing this 
mechanism should also specify their own independent header and 
processing instruction name then there is no opportunity for conflict. 

I also understand that HEAD requests check for document existence.  I 
was asking if we have a use-case where user-agents need to establish 
allow, deny, and default for a document based solely on the HEAD 
information without consideration of the processing instructions.  As 
currently written the working draft doesn't support that case.

Feels like we're talking past each other at this point, so perhaps the 
two of us can chat by phone sometime this week? 

--Brad

Anne van Kesteren wrote:
> 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 Sunday, 29 October 2006 15:30:46 UTC