Re: Notes from Non-meeting

Some additional minor note: At various points, I noted that in many
practical cases, location information will be a part of some bigger set
of privacy-related information, for example in a session setup (user
name, organization, subject of conversation, IP addresses, etc.), an
email message or presence document or request. In many cases, these
systems will already have an overarching policy mechanism. As an
example, we have extended CPL for managing presence information and it
may well make sense to incorporate location policy in this. It would
seem odd to force a datatype-specific mechanism. Given that policy can,
in general, only be expressed by a Turing-complete program, complete
with various database interfaces, trying to agree on one subset seems
like an exercise in futility, as there is no natural stopping point
short of inventing another full programming language. (In another
context, floor control has suffered a similar fate, except that it's
been going on for five+ years.)

"Rosen, Brian" wrote:
>
> The geopriv meeting was, of course, cancelled as announced.
> There was however, a non-meeting, totally unauthorized,
> and totally informal.
>
> At the non-meeting, a small group discussed several aspects
> of the problem. Since I was talking, I didn't write, but
> here is what I remember we discussed.
>
> The first thing we had surprising (to me) agreement on
> is that what we want first is an object, and not a protocol.
> The first uses of geopriv is within existing protocols.
> So, we can, for a while, not talk about how we transport
> the object, but only about the object and the operations
> on it.
>
> One of the things that keeps getting us "wrapped around the
> axle" is that we can't seem to separate four different aspects
> of this work:
>
> 1. The format of location information. I believe we agreed
> that it won't be hard to agree on this. There seems to be
> reluctance to actually do this before we settle harder
> problems. I personally think this is wrong, and we should
> just go ahead and pick a format (or actually more than one)
> now.
>
> 2. The transport of the object. As discussed above, we should
> avoid dealing with this for the moment.
>
> 3. The policy that governs what can be done with the object.
>
> 4. The cryptographic operations needed to protect the object
> when it is transported, and possibly as part of the implementation
> of the policy.
>
> One of the things we also agreed on (almost too readily it seems)
> is that the latter is NOT going to be specified by geopriv.
> We probably will offer guidelines on appropriate choices, but
> because we agreed that transport was not on the table, precise
> crypto is not on the table. I think this is a very helpful thing
> if the entire group agrees.
>
> It would facilitate further discussion if participants tried
> to keep these concepts separated. Surely they are inter-related,
> but we can discuss them separately. I'd request that we try hard
> to do that. So, for example, you can talk about needing to know
> whom you are disclosing location information to, but it may or
> may not include cryptographic authentication (and in fact
> in some cases there would NOT be any form of cryptographic
> authentication, for example, with emergency calls).
>
> We also agreed that policy was the "messy" part of the subject,
> but we also agreed that policy would have several forms including:
> 1) Policy governed by contract or law
> 2) Very simple policy - the example given was: I will give
> my location only to a proxy server, which will apply
> a more robust statement of policy to any other users
> of my location. The policy of the first device is
> extremely simple. The policy implemented by the
> proxy server can be complex.
> 3) More expressive policy expressed in a variety of ways
>
> There was great reluctance to get geopriv into the business of
> devising new ways to express policy and in particular, we did
> not see the WG designing a new policy expression language.
> It was also observed that policy can be expressed by a user
> interface as well as a formal policy language.
>
> It was observed that the output RFC of the work could have
> a 1/2 page statement on policy that would be possible to
> agree on, but it was REALLY hard to figure out how to
> agree on a multipage document in less than infinite time.
>
> We had a really short discussion on terminology. The discussion
> centered around the word "target". The basic confusion is
> whether the target is an object like a cell phone, a collection
> of objects like a cell phone a pager and a PDA, or a person
> carrying all of the above.
>
> Henning observed that we should use "object oriented" language,
> and thus talk about the person object inheriting location from
> the cell phone object. The set of objects (cell/pager/PDA) problem
> was observed to be a case of multiple inheritance but unlike in
> computer science, not an inherently hard problem to solve :)
>
> Brian
Received on Tue Mar 19 19:21:29 2002