Changing <expiry> from Sören Preibusch

Comment:

In order to cope with policy update problems and the non-ambiguity problems during policy transition phases (cf. section 2.4.1), the element EXPIRY could be slightly modified and a new element LAUNCH could be introduced.

Actually, specifying relative expiry times longer than one day makes it impossible to switch to a new policy and to be sure that there are no cached policies no more identical to the newly deployed policy.

This issue could be addressed by allowing a simultaneous use of the ?date? and the ?max-age? attributes of the EXPIRY element with the semantics: ?this policy / policy reference file is valid for the duration specified by ?max-age? but not after the date specified by ?date??.

In addition, the introduction of a new element LAUNCH as a companion to EXPIRY could streamline the policy transition process. An attribute ?date? indicates since when the policy will be valid. In written text privacy policies, it is usual to indicate when they will come into effect. Multiple policies with non-overlapping validity periods could be specified for a same URI to handle policy transition.

DRAFT answer of the Working Group
The P3P Specification Working Group welcomes this feedback. Nevertheless, we note that this is a P3P 1.0 issue. At the time of P3P 1.0 this was already raised. The answer at that point in time was, that one would have to change the same policy from a relative date to an absolute date that is longer than the relative date indicated intially. On the day of the expiry, the new policy can be established. In light of this answer, the group believes that introducing a completely new element to help the transition for expired policies is too much overhead compared to the gain of smoother transition of expired policies.

Minor Typos from Sören Preibusch <spreibusch@diw.de>

Comment Typos:
  • section 1.1.1: In the 10th list item, "JURISDICTION" instead of "JURSIDICTION"
  • section 3.3.6.1: URI of 95/46/EC: http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML (the same URI could be used in Appendix 7, section "Information Privacy")
  • section 3.4: eventually capitalize the should in The Other category should be used only when ...
  • section 4.5: change policwoesy to policy
  • section 5.6: remove whitespace in tag in By using the < dynamic>
  • section 6.4: change in section 4 of the P3P 1.0 Specificaiton or section ?? of the P3P 1.1 specification to in section 4 of the P3P 1.0 Specification or section 4 of the P3P 1.1 specification
  • section 6.5: hyperlink reference to section 2.4.4 in first paragraph
  • section 6.5: change RATIONAEL to RATIONALE in list item 2.
  • section 6.6: change see section 1.3.3 Identity Definitions tosee section 1.3 Identity Definitions
Clarification
  • section 1.3: add 95/46/EC after Directive so that the quotation is more accurate
Draft answer from the Working Group
Dear Sören, thanks very much for carefully reading of the specification. Thanks for the better URI for the text of the European Directive on eur-lex. We will include the changes.

Issues of the ABNF from Sören Preibusch <spreibusch@diw.de>

Comment:
another minor issue with the ABNF rules: sg-extension is defined twice ( [23] and [38] ). Rule 23 might be renamed to sg-def-extension.
Draft answer from the Working Group
We will accommodate those changes and change the XML Schema accordingly

XML Error in <Jurisdiction> from Sören Preibusch <spreibusch@diw.de>

Comment:
I think there is a well-formedness error in the example for the JURISDICTION element (section 3.3.6.1). The closing quotation marks of the "short-description"-attribute seem to be missing.
Draft answer from the Working Group
This will be fixed in the next Draft

Comments from ANEC (PDF) Bruno von Niman <bruno@vonniman.com>

Draft answer from the Working Group
N/A but mostly this concerns specifying things in preferences. But preferences were out of scope for this charter. The other things concern less WCAG 2.0 and more the user agent guidelines. More coordination and review from WAI site will be needed. Concerning the translations, the group might consider asking for help from the European Commission.

Testing and support Matthias Schunter <mts@zurich.ibm.com>

Comment:
You did a great job finalizing the document. I did not find any substantial problems and I like the document. Some minor typos are enclosed.
One question I'd like to know is whether we tested the claimed backward compatibility with P3P 1.0 with some browsers. I know that in principle, P3P should be backward compatible. However, mainly out of curiosity whether older browsers may choke on our new format, I'd suggest to run some example P3P 1.1 policies through an existing browser.
Draft answer from the Working Group

Conformance Karl Dubost <karl@w3.org>

Comment:
The following section:
1.2 About this Specification
This document, along with its normative references, includes all the specification necessary for the implementation of interoperable P3P applications.
is supposed to define the conformance of the P3P Specification.
  • Please rename it as Conformance.
  • Define your class of products.
As defined in the QA Guidelines
Draft answer from the Working Group
The Working Group will explore the possible classes of products and add some wording to the renamed section.

Well-knwon location Karl Dubost <karl@w3.org>

Comment from 31 Mar 2006:
2.2.1 Well-Known Location:
Any specification MUST not encourage to squat the URI space. To be reviewed with the TAG.
Formal Objection.
Comment from 3 Apr 2006:
2.2.1 Well-Known Location:
After discussion with Rigo, I remove my formal objections but I still maintain my issue about this chapter.
  • 1. I would first remove (and, are strongly encouraged to). We are trying to teach people and specifically companies that it's not good to create a specific URI for a specific feature. Many people have always excellent reasons to do so, but I really think that we should not encourage this.
  • 2. We should first give all the possible methods to achieve the feature and as the last choice (if no other possible choices) to rely on the WKL.
  • 3. the P3P specification mentions it too. A Website is not a domain name. It can be a subpart of a domain or even a collection of URIs on different domains. I would encourage you to review and cross-check your specification with Authoritative Metadata (TAG). See also the message of Mark Nottingham about it.
Draft answer from the Working Group
This is a feature of P3P 1.0 and was not touched by the 1.1 works. Dan Connolly complained for the P3P 1.0 version of it. It was explained to him and to others that a P3P user agent will very only take into account files that carry the P3P namespace. So if a site has already used up /w3c/p3p.xml by some other format, it can't use the well-known location anymore, but has to use the http-headers. This was accepted in P3P 1.0.
It has to be noted nevertheless that over 90% of the sites using P3P use the well-known location. So as this touches on P3P 1.0, was cleared in the process of the P3P 1.0 Recommendation. As you are not part of the P3P Working Group, I don't see where the _formal_ objection should come from, but feel free to write down a minority view that can be attached to the Last Call report.
Note perhaps that I would have expected rather a comment on the P3P generic attribute from you. I would be more interested in your remarks on this new feature that allows to address privacy metadata in any XML dialect.
We should add the comment made to Dan Connolly for P3P 1.0