RE: domain relationships

Here's an attempt to be more explicit:

<p>The <i>OUR-HOST </i>element is declared in the <i>POLICY-REF</i> element.

    For URIs covered by the associated policy, the user agent can encounter
other 
    hosts in different domains serving embedded content, link, or action
requests. 
    The user agent may consider such a host to be owned by the same entity
or 
    one of its agents if its URI matches an associated <i>OUR-HOST</i>
entry. 
    Any number of <i>OUR-HOST </i>elements can be declared inside a
<i>POLICY-REF 
    </i>element.</p>
  <p>Embedded content is considered to be any content that is retrieved
during 
    the processing of the current document, such as images, documents in
frames, 
    script files, etc. Content embedded more than 1 level deep (e.g. an
image 
    inside a frame) is still considered embedded content and the our-host
declarations 
    at the top-level may still apply.</p>
  <p></p>
  <p>Any relationships inferred by this mechanism are valid only in the
context 
    for which they were discovered -- this is not a mechanism for declaring
globally 
    that two hosts have a relationship in all contexts. By extension, the
relationships 
    are not transitive. Suppose two distinct hosts A and C are matched by
<i>OUR-HOST</i> 
    entries in a policy reference file for host B. Even if the same policy
applies 
    to both, nothing may be inferred about the relationship between A and C
for 
    use in other contexts. The relationships are not transitive even in the
case 
    of multi-level embedded content -- the top-level host must declare
our-host 
    relationships for all levels of embedded content.</p>
  
Let me know what you think.

++Jack++


-----Original Message-----
From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu]
Sent: Monday, March 29, 2004 9:50 PM
To: Humphrey, Jack
Cc: 'public-p3p-spec'
Subject: Re: domain relationships



I think what is not explicit is the types of content to which you can 
apply our-host -- that embedded content includes both directly and 
indirectly embedded content. Maybe we need to include some examples 
like "images, frames, images embedded in frames, etc."

Lorrie


On Mar 29, 2004, at 10:32 PM, Humphrey, Jack wrote:

> Does this section of the proposal not clarify it?
> ---
> Any relationships inferred by this mechanism are valid only in the 
> context
> of the policy reference file and policy for which they were discovered 
> --
> this is not a mechanism for declaring globally that two hosts have a
> relationship in all contexts. By extension, the relationships are not
> transitive. Suppose two distinct hosts A and C are matched by OUR-HOST
> entries in a policy reference file for host B. Even if the same policy
> applies to both, nothing may be inferred about the relationship 
> between A
> and C for use in other contexts.
> ---
> (I think that first sentence needs to be rephrased: "in the context for
> which they were discovered"?)
>
> Brooks, in your example, publisher.com would definitely have to 
> declare both
> weathersite.com and adserver.com as our-hosts. There is no hierarchy 
> or any
> kind of transitivity.
>
> ++Jack++
>
> -----Original Message-----
> From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu]
> Sent: Monday, March 29, 2004 8:46 PM
> To: 'public-p3p-spec'
> Subject: Re: domain relationships
>
>
>
> Hmm... interesting question. So, my interpretation of the current
> proposal is that there are no transitive relationships. If
> publisher.com declares weathersite.com and adserver.com as our-hosts,
> then both of them can be treated as first party regardless as to
> whether they are embedded directly or indirectly. That should probably
> be made explicit.
>
> Lorrie
>
>
> On Mar 29, 2004, at 6:12 PM, Dobbs, Brooks wrote:
>
>>
>>
>> So something we may still need to clarify, if what we are trying to 
>> get
>> around here is implementers that have 1st and 3rd party restrictions.
>> Obviously IE makes some of its own defintions.  One such liberty in 
>> the
>> whole 1st third party thing is they rely on a "parent" request that
>> determines 1st partyness without ever really defining or even
>> mentioning
>> "parent".  I think we assume this parent to be the file that returns
>> HTML that tells the browser to go pull child assets (beacons, images,
>> iframes, whatever).  IE has the notion that these sub elements can 
>> have
>> either a 1st or 3rd party relationship with the parent.  I think you
>> have addressed how *that* relationship can be more expressive, but 
>> does
>> anything in current P3P talk to the notion of their even being a 
>> parent
>> asset?
>>
>> Imagine the following scenario.
>>
>> Weathersite.com declares an our-hosts relationship with adserver.com.
>> So now when adserver.com serves ads on weathersite.com there is a way
>> that weathersite.com can communicate that adserver.com should be
>> treated
>> as 1st party.
>>
>> Imagine however that there is another site publisher.com which embeds
>> content not only from adserver.com but also from weathersite.com.  
>> What
>> is a UA to do?  Is adserver.com an our-host of weathersite.com or of
>> publisher.com.  Unless there is a definition or hierarchy of parent,
>> things get messy no?
>>
>>
>> -Brooks
>>
>>
>> -----Original Message-----
>> From: Humphrey, Jack [mailto:JHumphrey@coremetrics.com]
>> Sent: Monday, March 29, 2004 5:25 PM
>> To: Dobbs, Brooks
>> Subject: RE: domain relationships
>>
>>
>> No, Rigo didn't update it. I've attached the latest version again.
>>
>> ++Jack++
>>
>> -----Original Message-----
>> From: Dobbs, Brooks
>> To: Jack Humphrey (JHumphrey@coremetrics.com)
>> Sent: 3/29/2004 4:06 PM
>> Subject: domain relationships
>>
>> Jack is this the latest version?
>>
>>
>>
>> http://www.w3.org/P3P/2004/03-domain-relationships.html
>>
>>
>>
>> Brooks Dobbs
>>
>> Director of Privacy Technology
>>
>> DoubleClick, Inc.
>>
>>
>>
>> email: bdobbs@doubleclick.net <mailto:bdobbs@doubleclick.net>
>>
>>
>>
>>
>>
>>
>