RE: draft backwards compatibility guidelines

Hi Lorrie,
Here are some comments on the compatibility guidelines.


Here is a draft of the backwards compatibility guidelines I was
actioned to document on yesterday's conference call. Please send your
comments and feedback. I would like to try reach closure on these (or
an amended version of these) at our conference call next wednesday and
document that it is the consensus of the working group to follow them.

Lorrie



BACKWARDS COMPATIBILITY GUIDELINES

The (draft) P3P 1.1 working group charter states "The P3P 1.1
Specification should be designed for backwards compatibility with the
P3P 1.0 Specification." Here are some details of what this means
and how we will apply this as the working group goes about its
business. This is not intended to be a comprehensive or absolute set
of requirements, but rather a set of guidelines to help the group
work towards a common goal. Working group members should keep these
guidelines in mind when making proposals to the working group and
avoid proposals inconsistent with these guidelines.

- P3P 1.0 user agents should be able to process P3P 1.1 policies and
   policy reference files. This implies both that the P3P 1.1 policies
   and policy reference files are fully compliant with the P3P 1.0 XML
   schema, and that the semantics of these files will not be
   misinterpreted by a user agent that interprets them according to
   the P3P 1.0 specification.

**Perhaps this is more restrictive than it needs to be. As no existing user
agents do compulsary schema validation, it is unlikely that any problems
would be caused by adding attributes and maybe even not by adding elements.
I admit it is conceivable but we could easily ascertain if it were the case.

Also it does not cover the case that we discussed last week for XML Schema
Data Schema where two alternatives are offered one of which would break
existing technology but the newer one is only sent to newer agents (that's
how I understood it anyway). I don't see that covered here.


- New vocabulary elements and syntax introduced in P3P 1.1 should be
   introduced as optional extensions using the P3P 1.0 extension
   mechanism.

- New or changed P3P HTTP headers that are not backwards-compatible
   with P3P 1.0 should use a new prefix to differentiate them from
   those used in P3P 1.0. They should be designed such
   that sites that wish to make their P3P headers accessible to both
   P3P 1.0 and P3P 1.1 user agents can include both the P3P 1.0 and P3P
   1.1 headers.

- Changes to requirements or definitions introduced in P3P 1.1. should
   add clarity where the P3P 1.0 specification is ambiguous, but should
   not cause a particular P3P vocabulary element to have different
   meanings in P3P 1.0 and P3P 1.1.

**What if we decide it was simply wrong and want to change something?

- New requirements or features may be introduced in the P3P 1.1
   specification if they do not impact the ability of P3P 1.0 user
   agents to process P3P 1.1 policies and policy reference files.

**This seems to be a repetition of the first point. Or have I missed
something.

 For
   example, a feature that would enable P3P policies to be referenced
   from arbitrary XML documents would not impact P3P 1.0 user agents,
   since those user agents do not attempt to find P3P policy references
   in arbitrary XML documents. Of course, P3P 1.0 user agents are not
   expected to comply with new requirements introduced in P3P 1.1.



- Features, vocabulary elements, or requirements may be removed in
   the P3P 1.1 specification as long as they do not cause a P3P 1.0
   user agent to be unable to process a P3P 1.1 policy or policy
   reference file.

Received on Tuesday, 6 May 2003 12:02:12 UTC