Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol

Scott and Edward, thanks for your response!

On Thursday 03 April 2003 18:06, Edward Lewis wrote:
> Please note that I took "public-p3p-spec@w3.org" off the cc list - to
> avoid cross-posting and I'm not on that list.  If anyone wants to
> forward this message to that list, you have my permission.

While cross-listing is generally bad, I'm including w3c list in the cc 
because this is definitely a substantive in-scope issue for us, and since 
you guys didn't remove provreg I assume you thought it relevant there too 
<smile/.>


> At 18:20 -0500 4/2/03, Joseph Reagle wrote:
> On HTTP - one of the items in our charter has been to investigate
> "other transports" with "other" meaning "not TCP" in the context.
> But to date, there's been no sustained interest in pursuing any
> transport other than TCP (with TLS) but multiple members of the WG.
> It's not so much that HTTP was rejected, no one suggested doing it.

Understood.

> >2. What led you to make the changes to the vocabulary that you did?
> > (Some terms are removed, some are altered -- we're these casual changes
> > or did you have significant market/policy tensions in your app
> > context?)
>
> To some extent because our protocol is "business to business" and
> constrained in it's reach, as opposed to being "person to business"
> and in general use.

And as Scott said, it was a question of operational experience. However, 
since we, in the P3P context, are trying to figure out how to promote 
reuse, mind if I follow up on that? For instance, if we come to 
understanding of which parts folks keep, and which parts get dropped or 
modified depending on the context, perhaps we can provide guidance and 
better structures. I've included a table comparing P3P XML, Compact, and 
EPP with the following characterization of changes:

ACCESS
EPP uses a epp:null whereas p3p has a related p3p:nonident. epp:null means 
that only transient data was collected, but p3p:nonident is still a valid 
description of that, particular when used with p3p:no-retention is used. In 
this case, I'd recommend EPP converge with p3p:noident and support 
p3p:no-retention since the separation of those two axes is cleaner.

DISPUTES
EPP doesn't support how a dispute can be addressed. Is this because in P3P 
this is a representation to the consumer, and EPP isn't B2C? Is the 
regulatoriness <smile/> of it too scary? I'll also note the P3P Compact 
Syntax collapses this all into a DSP token with no p3p:{service, 
independent, court, law}.

REMEDIES
EPP doesn't support this, see question in DISPUTES.

NON-IDENTIFIABLE
EPP doesn't support this, not sure why.

PURPOSE
EPP supports p3p:{admin, contact, other} and epp:prov. I can see the PURPOSE 
varying widely across application contexts and I think it makes sense to 
drop and extend from this axes as appropriate.

REQUIRED
No ability designate whether data is required, opt-in, and opt-out. Again, 
probably because EPP is not B2C?

RETENTION
See ACCESS. I recommend you support "no-retention" and then both P3P and EPP 
will still sync up on these two axes.