W3C home > Mailing lists > Public > public-p3p-spec@w3.org > June 2003

UA: MINUTES: 12 June 2003 UA TF call

From: Lorrie Cranor <lorrie@research.att.com>
Date: Thu, 12 Jun 2003 15:08:48 -0400
To: public-p3p-spec@w3.org
Message-Id: <4C2560E7-9D09-11D7-9EB8-000393DC889A@research.att.com>

12 June 2003 User Agent Task Force Call

Lorrie Cranor
Giles Hogben
Brooks Dobbs
Rigo Wenning
Dave Stampley
Ari Schwartz

The full WG discussed the user agent guidelines document 
http://www.w3.org/P3P/2003/ua-guidelines.html on their call yesterday 
and decided it should be part of the P3P 1.1 spec. Lorrie proposes to 
include it as section 6 and will edit it accordingly. Rigo is concerned 
that the the user agent guidelines should make it clear that the plain 
English translations are not a substitute for the normative 
definitions. Rigo will check the language currently in the document and 
propose changes if he finds it inadequate.

We began discussion of the 2 June translation matrix and discussed the 
ENTITY and ACCESS elements and some high-level issues, as follows.

We have a preference for headings that do not appear in the form of a 

We have a preference for referring to the user as "you" rather than "I" 
or "me".

We don't like the use of the phrase "this site" throughout. Here are 
some options (no consensus was reached on which to adopt): (a) "this 
provider" - but may be confused with ISP  (b) "this entity" - but 
people aren't going to know what that means (c) use passive voice and 
avoid phrase - passive voice is wishy washy (d) "we" - there may be 
confusion about who we refers to? (e)  insert name from entity element 
- could be legnthy (f) use "we" with a hyperlink to where the entity 
name is displayed

ENTITY element: The group did not like either Lorrie's or Jeremy's 
proposal because they talk about contacting the site, which is not 
really what ENTITY is about according to the normative definition. The 
consensus was to use the phrase "This policy is issued by" instead.

We had a discussion about whether a site should be able to have more 
than one ENTITY element. The current P3P syntax does not prohibit sites 
from declaring multiple duplicate entity fields, and effectively having 
multiple entity elements. However, there is no grouping mechanism, so 
user agents do not know how to display this information. W3C is an 
example of a site that is declaring multiple entity fields (we haven't 
seen others). We may want to recommend to the full WG that we (a) 
prohibit multiple ENTITY elements, or (b) add some sort of grouping 
mechanism and/or advice user agents what to do if a site has multiple 
ENTITY elements. Technically, it is probably easier to prohibit this. 
Some task force members also felt it was confusing to users to see 
multiple entities and that one entity should be designated to be 
listed. Rigo was concerned that in the case of a consortium or joint 
venture, multiple entities might be equally responsible. Dave said that 
the entity element doesn't indicate responsibility, only who the 
speaker is, and that it is common for joint ventures to designate a 
single entity as spokesperson. Rigo also said it would be convenient 
for users to see contact information in multiple countries so they 
could pick the phone number to call where they were likely to get 
someone who speaks their language. But others pointed out that ENTITY 
is not supposed to be used as a way for consumers to contact a company 
-- just a way to identify who the company is. The disputes element is 
used for contacting, and it allows multiple addresses to be listed. We 
need to discuss further. Lorrie has opened this on bugzilla as issue 

ACCESS element: The group did not like Jeremy's phrasing this in the 
form of a question or using "I" but they liked the fact that it made it 
clear that the information was about the user. The consensus was to use 
the phrase "Your access to information about you" instead.

Lorrie will post revised versions of the matrix and guidelines document 
shortly. Please review and provide feedback on the mailing list. 
Discussions of the other points we didn't resolve on the call today 
should also continue on the mailing list.

Our next call will be on Monday, June 23 at 11 am US Eastern.
Received on Thursday, 12 June 2003 15:07:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:17 UTC