Re: Geopriv WG - meeting 5-6 Jun, other news

From: Eric Brunner-Williams in Portland Maine ^lt;>
Date: Thu May 16 2002 - 20:44:19 EDT

Howdy Richard.

> Now on to some particulars.
> IMHO these data elements look like XML objects and the Privacy Object
> should be an extension of the work already done in W3C on P3P. Where as
> P3P was designed as a PULL mechanism to define privacy policy for servers
> running HTTP ..what we are seeing here is more of a PUSH mechanism in the
> opposite direction. The Rule Maker defines what they want people should
> see not the Location Seeker defining what their policy is.


Up until November of 2000 P3P was as described, with the state management
drafts hanging in Massinter-shutdown-mode, with Ned-and-Keith doing their
little bit too.

At the November P3P f2f a vendor took the position that policy evaluation
was actually much more complex than advertized (true), and another vendor
took the position that policies should be expressed without reference to
a DOM tree, and be carried in-band. At the conclusion of that meeting,
compact representations on state management mechanism instances entered
the P3P spec.

This has been adopted with application of P3P to CC/PP, and Xforms, but
to be honest, although HTTP is commonly viewed as a retrieval mechanism
for HTML, it is really a retrieval mechanism for objects encoded using
MIME, and that isn't sufficiently general for the protocol, the event
model, or the data representation format.

In another protocol (onward-transport of customer profiles) developed at
roughly the same time (1999-2000) by another industry group (CPExchange),
P3P's vocabulary was adapted in DTD form.

In another protocol (onward-transport of domain registration data)
developed in 2001-2002 by another industry group (PROVREG WG), P3P's
vocabulary was adapted in schema form.

A representation format is useful. It could be in ASN.1, in XML, in BNF,
and it could even be expressed as a MIB. There are a lot of choices.

An event model is useful. It could be asymmetric. It could be symmetric.
There are a lot of choices.

A group or address-equivalence model is useful. It could be a GIPC built
on unicast, it could be multicast. There are a lot of choices.

Another bit of related tech is APPEL, spun off from P3P, November '00.

Now to take another salient para (out of order):

> Let be honest here .. though there are several applications where this
> architecture might be useful the clear and present need is in Internet
> Telephony and SIP in particular.

Half the time I don't know where I am. The other half the time I don't
know what time it is.

         I'd like locality representation format(s)
        I'd like temporal representation format(s)
        I'd like representation peering mechanism(s)
             I'd like convergence mechanism(s)
          I'd like interface(s) to AAA mechanism(s)

[Basically, I'd like an NLP that looks and smells like NTP, with simple and
 secure variants, having zippo to do with GPS or carrier network knowledge,
 except as one possible, non-authoritative, source of l-and/or-t data, and
 capable of supporting j-random policy requirements, as opposed to being
 just their weak pseudo-technical restatements.]

> I want this list to understand that we are laying the ground work for what
> is perhaps a once in a generation advance in the concept of a public
> service location protocol that if defined correctly could link not just the
> location of an individual in distress but also provide life saving links to
> other forms of data records that could save countless
> lives. Think about that in the context of privacy requirements.


Received on Thu May 16 20:51:37 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST