[ietf-provreg] Fd: Re: BH: Introducing the Beyond HTTP (BH) Task Force

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Anyone want this? I prefer not to "laze" (or however that is spelt),
since I do such a bad job of contributing. I've re-arrainged the p3p
mail to put my-take-on-epp (tm) first, for this list's benefit.


------- Forwarded Message

> List-Id: <public-p3p-spec.w3.org>
> 
> On Friday 21 March 2003 05:48, Eric Brunner-Williams in Portland Maine 
> wrote:
> > 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 ...
> 
>                       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.

[this isn't the first item]

> > 	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:
>   http://www.ietf.org/html.charters/provreg-charter.html
>   http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-09.txt
> 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 
> conversation?


[ this is where the first item begins]

> > 	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 
> taskforce.
> 
> > 	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
>   http://www.w3.org/P3P/2003/04-beyond-http#sec-Others
> 

[part #3 delted here, moved up]

> ------- End of Forwarded Message