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

Re: BH: Introducing the Beyond HTTP (BH) Task Force

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 28 Mar 2003 15:21:46 -0500
To: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Cc: public-p3p-spec@w3.org
Message-Id: <200303281521.46064.reagle@w3.org>

On Friday 21 March 2003 05:48, Eric Brunner-Williams in Portland Maine 
> Here are a couple of things where I've attempted to take policies that
> are { similar to | derived from | stolen and wrecked | ... } P3P's and
> make mechanisms other than some set of HTTP methods transport apply.

Thanks Eric, does this mean you would like to be listed as a member of the 
taskforce? <smile/> I've briefly looked into each of of the apps below 
looking for salient requirements and/or features of a scenario that might 
be relevant. Please correct me if you think I've missed something.

> 	1. CPExchange, a customer profile exchange application-layer
> 	   protocol, with no transport binding. The DTD for this and
> 	   the pre-bubble bumpf are still available at
> 	   http://www.cpexchange.org/

This appears to be an extension of the P3P privacy vocabulary with a more 
extensive XML data profile based on XML Schema data types. It appears they 
have the significant portion with {Access, Purpose, Retention, Recipient}. 
Because it's based on a 2000 snapshot of P3P I can't discern any particular 
divergence in the privacy vocabulary because of this app's context. I can 
conclude that they felt there was a need for more extensive and XML Schema 
typed data structures that would perhaps be of interest to the P3P Schema 

> 	2. HTTP WG, an IETF WG (concluded). During the last year of the
> 	   WG, Dan Jaye contributed a draft that extended the Kristol,
> 	   Montulli draft on the state management mechanism, RFC 2965.
> 	   This draft has expired, but I have it (co-author). The IESG
> 	   published a note written by Moore and Freed (RFC 2964), on
> 	   the problem domain, observing that some uses of the mechanism
> 	   were harmful, and depricated policied cookies.

I followed this work back in the day and my conclusion would be that there 
was a requirement for terse expression. This appears to be satisfied with 
compact policies and I would expect other apps with a similar requirement 
to use them, or perhaps in the future a binary-XML representation of the 
complete markup...? I've included this in

> 	3. PROVREG WG, an IETF WG (current). The problem domain defined
> 	   by Verisign's RRP protocol, using EBNF as the formal syntax,
> 	   is slightly restated in EPP, using XML as the formal syntax.

I'm unfamiliar with this work but I've poked about on:
and see they have a :
  """   - A <dcp> (data collection policy) element that contains child
    elements used to describe the server's privacy policy for data
    collection and management."""
with an {access, purpose, retention}, elements based on P3P. Since this is 
active work, I think it makes sense to ask them why don't they use the 
elements from P3P itself? And if there are reasons, we'd appreciate the 
feedback. Do you have connections with this work, could you help start that 
Received on Friday, 28 March 2003 15:21:54 UTC

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