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 18:38:10 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST