locating policy reference files

Hello,

I have got a question regarding the different mechanisms to locate a policy 
reference file. 

I would very much like to find a solution that relies on wellknow-location 
like mechanisms only; the p3p user agent could fetch the policy reference 
file (that covers a certain URI) *before* it sends the actual request to the 
webserver.

This would avoid safe zone practices in the first place and
- reduce software complexity of the user agent, and
- make the implementation much faster, 
because the actual "p3p-logic" could be seperated from the entire connection 
technique. Otherwise p3p issues and http issues would get mixed, leading to 
mixed responsibilities of the different "parts" of the software - at least 
from an object oriented point of view. 

The typical scenario that explains why the wellknow-location mechanism is not 
enough is: one company hosts some content on its server that it is not 
responsible for, therefor excluding the subtree with the foreign content from 
the own policy reference file. 
Responses to requests to a URI refering to some part of this subtree would 
then contain a reference (http header or html link-element) to the covering 
policy reference file - unfortunately the request has to be send first.

Now my question: why not oblige the foreign company to put a policy reference 
file in the root of "their" subtree? The foreign company is in charge of the 
subtree anyway. 
This would give us the possiblity to use a wellknow location like mechanism 
to fetch the apropriate policy reference file. The procedure for any request 
would than always begin as follows: 

extract host information from the URI, get the policy reference file from the 
wellknow location on this host, parse the file ... and maybe find out that 
the request's URI points to some subtree not covered by this policy reference 
file, get the policy reference file from the root of this subtree ....

Do you think that a modification of the specification would make sense? I 
would appreciate any comments.

Regards
Sebastian Kamp

Received on Tuesday, 24 April 2001 05:40:43 UTC