Re: proposal to add grouping mechanism to CP

On Mar 30, 2004, at 11:11 AM, Rigo Wenning wrote:

> Nice draft!
>
> Am Wednesday 24 March 2004 21:23 verlautbarte Lorrie Cranor :
>> I propose changing it to say:
>>
>
>> policy. However, a site MUST make compact policy statements in good
>> faith. User agents that are unable to obtain enough information from
>
> This sentence is ambiguous as it can read:
> 1/ a site MUST make compact policy statements
> 2/ if a site makes compact statements, it has to do so
> in good faith.
>

OK, how about:

However, if a site makes compact policy statements, it MUST make these 
statements in good faith.

>>
>> User agents that use compact policies as part of their decision making
>> MUST include a mechanism that allows users to determine that a
>> particular decision was made based on a compact policy and to view
>> that compact policy. However, user agents that provide general
>> information about a site's P3P policies to users MUST use the full P3P
>> policy and MUST NOT use the compact policy for this purpose.
>
> The first requirement sounds really strange. It is raw access to
> the tokens as arrived at the user agent. This is normally done
> by experts using telnet or perl tools. But I think this was the 
> consensus
> we had. We should be clear that it is really only raw access.

I don't so much care about whether a user agent gives me an ascii 
string or whether it formats it in a pretty way, as long as all the 
information is there. I think the current wording captures that. In 
what way do you think it might be misinterpreted?

>
>>
>> I propose adding a section 4.2.10 Compact STATEMENT
>>
>
>>
>> Section 4.5, fourth paragraph, change MUST to MAY (as in "All of the
>> purposes, recipients, and categories that appear in multiple
>> statements in a full policy MAY be aggregated in a compact policy...."
>
> Why transform? The whole paragraph does not make too much sense
> anymore.

For backwards compatibility, the aggregation is still legal. We could 
change this paragraph to say:

The P3P 1.0 specification required that all purposes, recipients, and 
categories that appear in multiple statements in a full policy be 
aggregated in a compact policy, as described in section 3.3.1. With the 
addition of the compact STATEMENT element in P3P 1.1, this is no longer 
necessary, although it is still permitted. When performing the 
aggregation, a Web site MUST disclose all relevant tokens (for 
instance, observe Example 4.1, where multiple retention policies are 
specified.)

>
> Another thing is, does P3P 1.1 use mandatory extensions? In this case,
> the third paragraph is an issue too:
> Full policies that include mandatory extensions MUST NOT be represented
> as compact policies.

I believe we only include optional extensions in P3P 1.1. If we used 
mandatory extensions it would introduce backwards compatibility 
problems.

>
>>
>> Section 4.6 Transforming a Compact Policy to a P3P Policy should be
>> dropped.
>>
>>
> In the same direction, 4.7 could be integrated somewhere instead of 
> having
> an own point. I also wonder why we said SHOULD NOT while the above
> indicates that by inference it is supposed to read MUST NOT.

4.7 is entirely repeated as the first paragraph of section 6.4, so I 
think we could drop 4.7.

(Rigo, here is one typo in 6.4 - a ] that should be removed.)

At the time we wrote this we agreed to SHOULD NOT. However, I think 
MUST NOT may be appropriate given our other changes. So I would propose 
that the first paragraph of 6.4 say:

P3P user agents MUST NOT rely on P3P compact policies that do not 
comply with the P3P 1.0 or P3P 1.1 specifications or are obviously 
erroneous. Such compact policies SHOULD be deemed invalid and the 
corresponding cookies should be treated as if they had no compact 
policies. The following guidelines are designed to reduce the chance 
that a P3P user agent will accept an invalid compact policy.

Received on Tuesday, 30 March 2004 12:23:05 UTC