Re: P3P: General Comments

On 01-05-13 17:00, Sean B. Palmer wrote:

Dear Sean,
 
> Hi,
> 
> Here are some general comments on P3P - w.r.t. the P3P specifications
> and related materials - as it stands.

Thank you for those comments. As you can see, we took a little
time to respond. We took our time and discussed the remarks you
made. Some of the questions weren't that easy to answer. So here
are the answers, the group found.
> 
> Firstly, a few comments on the CR specification at:-
> 
>    http://www.w3.org/TR/2000/CR-P3P-20001215/
> 
> > 2.2.1 Well-Known Location
> 
> I think that the well-known location for any non-recommendation (and
> even possibly the recommendation) versions of P3P should be a date
> stamped area, to avoid confusion. It may already be too late, but if
> you start using "/w3c/p3p.xml" as the well-known location for all of
> the draft versions, there is no way that a user agent can know what
> version the file is until it dereferences it. You could cut out a step
> by asking people to use "/2000/12/w3c/p3p.xml", or perhaps
> "/w3c/2001-12-p3p.xml" as the CR version, and so on for all future
> versions.
> 
> It's difficult to keep track of previous versions of policies (as the
> spec. recommends) if different versions of P3P all use the same URI.

The group decided we don't want to do versioning of Working Drafts for
interoperability reasons. Working Drafts are not recommendations and may
change at any time. A Candidate Recommendation is supposed to be stable.
Currently, there is no change pending for the Policy Reference File
(possibly located in the well-known location). The goal of this
standardization effort is to assure interoperability. We expect after
recommendation that there will be a fixed well-known-location with a
well defined format. Another argument in favor of not changing is that
it is not probable that user-agents would look into locations from older
working drafts. So the proposal would weaken the force of the well-known
location.

The Group discussed possible conflicts with possible P3P Version 2
changes. We found that we could handle the changes inside the file by a
Namespace-Declaration. If, for some unknown reason, the format would not
be XML, we would be able to define another file-name. (p3pv2.whatever)

> 
> > 2.2.2 HTTP Headers [...]
> 
> > `policyref="` URI `"`
> 
> Why aren't relative URI references permitted? It seems to me that
> allowing this would allow people to cut down on data, and also save
> time on some requests.
[...]

Our definition of URI's refers to RFC 2396[1]. This means, that also
relative URI's are allowed in headers, as relative URI's are also
valid URI's in the sense of RFC 2396. 

To improve our specification and it's wording, it would be very
interesting to know, from which sentence you derived, that we
would not allow relative URI's in http-headers?

> 
> 
> > 2.2.3 The HTML link Tag [...]
> > <link rel="P3Pv1"
> >     href="http://catalog.example.com/P3P/PolicyReferences.xml">
> 
> Error: this link form is illegal in HTML 4.01 onwards; list of link
> types is clearly enumerated [1] in HTML 4.01, and "P3Pv1" isn't in
> there. The only way to extend the list of link types is to point to a
> metadata profile by setting the "profile" attribute on the <head>
> element. I suggest you simply define the namespace for P3P as being a
> metadata profile in (X)HTML and use that, so that the code becomes:-
> 
>    <head profile="http://www.w3.org/2000/12/P3Pv1">
>    <link rel="P3Pv1"
>         href="http://catalog.example.com/P3P/PolicyReferences.xml">

The enumaration in the HTML 4.01 Specification on Link-Tags[2] is
not exclusive. That means, that the list mentioned there doesn't
exclude other link-types. So having a P3P-Link-Tag is not illegal
with regard to the HTML 4.01 Specification[3]. 
The definition of a profile in the HTML 4.01 Specification is a
SHOULD. The profile - element in HTML is underspecified. As the 
link-tag is specified in the P3P-Specification, we don't see the 
need to specify an additional profile thus arguing for an exception 
to the SHOULD in the HTML 4.01 Specification. Furthermore, there
is a Note on XML in HTML Meeting Report[4], which contains a
remark on exactly that issue[5]. 
 The link-element is specified in the
P3P Specification. 
http://www.w3.org/TR/NOTE-xh#link
http://lists.w3.org/Archives/Member/w3c-p3p-syntax/1998JulSep/0010.html
http://lists.w3.org/Archives/Team/w3t-ui/1998JulAug/0043.html
> 
> > 2.3.2.5 The INCLUDE and EXCLUDE elements
> 
> The exact cascading of these elements is not specified - do the latter
> elements always take precedence over the earlier ones?

In the syntax of the Policy Reference File[6], we have the elements 
<POLICY-REF about="` URI `">. Their order in the Policy Reference 
File matters:

Section 2.3.2.1.1 Significance of order[7]
A policy reference file may contain multiple POLICY-REF elements.
If it does contain more than one element, they MUST be processed by user
agents in the order given in the file. When a user agent is attempting to
determine what policy applies to a given URI, it MUST use the first
POLICY-REF element in the policy reference file which applies
to that URI.

Inside the <POLICY-REF about="` URI `"> - element, we indicate
the URI-spaces by <INCLUDE> and <EXCLUDE> - Elements. Their order
is not significant:

2.3.2.5 The INCLUDE and EXCLUDE elements[8]
When INCLUDE (and optionally, EXCLUDE) elements are present in a
POLICY-REF element, it means that the policy specified in the
about attribute of the POLICY-REF element applies to all the URIs
at the requested host corresponding to the local-URI(s) matched
by any of the INCLUDEs, but not matched by an EXCLUDE element.

> 
> > 3. Policy Syntax and Semantics
> > P3P policies are encoded in XML. They may also be represented
> > using the RDF data model ([RDF]); however, an RDF representation
> > is not included in this specification. (Such a representation is
> > planned to be made available as a W3C Note prior to submitting P3P
> > as a Proposed Recommendation, together with a suitable RDF
> > encoding of the policy reference file).
> 
> I haven't yet been able to find any public justification for using a
> flat XML model to represent the P3P system over RDF (maybe I'm not
> looking hard enough; if there is one, please accept my apologies).
[...]
> Of course, I would raise this point, because I'm an RDF developer :-)

If you try to parse the Policy-Reference File with an RDF-Parser,
it works. We will also provide a description of RDF data models
representing P3P policies and policy reference files. 


> 
> > 3.2.4 The ENTITY element
> >
> > [...] `<DATA ref="#business.name"/>` PCDATA "</DATA>"
> 
> "business.name"? That might stop a lot of private entities from
> creating privacy polices - or do privacy policies only apply to
> registered companies? Judging by the list of compliant sites [4] even

While the business.name might be confusing people, the definition
of the Entity-Element is clear. We use the
business.name-structure in two places, that means that we don't
blow-up the Schema/DTD by adding just another structure. It is
actually used for the Entity-declaration and for Third-Party -
declaration. We feel, that the benefit of re-using a structure
outweighs by far the benefit of the additional semantics inside
an XML-Tag in this case. Additionally, you can always refer to
the definition of <ENTITY> in the Specification.

> 
> And more generally...
> 
> [[[
> Should this specification prove very difficult or impossible
> to implement, [...]
> ]]] - http://www.w3.org/TR/2000/CR-P3P-20001215/
> 
> Clearly not impossible because there are implementations, and perhaps
> not difficult as soon as there are multiple widely-available
> non-commercial software for doing so. After a couple of hours of
> reading the specification and all related materials, browsing through
> some P3P compliant sites, checking out tools and downloading them, and
> setting up my Website, I actually managed to produce a half-decent P3P
> policy for infomesh.net that validates correctly. Note that eventually
> I just hacked out my policies by hand.

This proves, that we made the right decision in 1999 to radically
simplify P3P. It is good to see, that one could be able to hack a
policy by hand. The WG though expects implementations of P3P
Policy Editors. 

> 
> What I think you *do* need is more in the way of tutorials and
> introductory material, although given the instability of P3P at the
> moment, you'll probably want to hold back until Rec. This is a neat
> project, and I have no doubts that tools and implementations will be
> forthcoming :-)

First of all, P3P is now in Candidate Recommendation and we
consider the Specification to be rather stable. Only feedback
from implementers is taken into account.

We are aware of that issue and there is work under way. As a
first result, Martin Presler-Marshal wrote the Platform for 
Privacy Preferences 1.0 Deployment Guide[9], which explains how
to configure your web-server. 

There is also a Policy and Outreach Working Group working on the
suggested education materials. We hope to accomplish this soon. 

Thanks again for your comments


Rigo Wenning            W3C/INRIA
Policy Analyst          Privacy Activity Lead
mail:rigo@w3.org        2004, Routes des Lucioles
http://www.w3.org/      F-06902 Sophia Antipolis

Received on Tuesday, 26 June 2001 12:05:15 UTC