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

From: Eric Brunner-Williams in Portland Maine ^lt;brunner@nic-naa.net>
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.

Almost.

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)
                            and
        I'd like temporal representation format(s)
                            and
        I'd like representation peering mechanism(s)
                            and
             I'd like convergence mechanism(s)
                            and
          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 ...health records that could save countless
> lives. Think about that in the context of privacy requirements.

Maybe.

Eric
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