Re: Terminology

Looks like I am comming late, but....

>
> I think we all agree on the term "target"; it's the device
> that has a location.

In most cases, yes. But I think human still could be a target. Human can,
of course, know where he is without any devices - I can tell I am at the
5the Avenue and 11th Street by just road signs, or at Tokyo station, or
Salt Lake City without GPS. And I may be able to manually input their
location in a descriptive format.

For example, consider the case that I
register my location/presence information in my location/Presence
Agent, which is located in my desktop PC in Mountain View office, that
I will go to Palo Alto office and stay there off line for the rest of
the day.

In this case, any device is collocated with me, the target.
In general, the entity that determines the location is not collocated
with the target - e.g. attacking the targets from the sky. In my opinion,
target is anything that a URI and the location. But I agree that people
often confuse that the location of the target. Besides that, I do not
think we should ignore the possibility of human as targets. And also
adding this does not affect the discussions we have so far. I just the
avoid the situation where the requirements document says "the target MUST
be a device but MUST NOT a human".

> We usually use the term "user", in two contexts. One is that
> the target is usually described as associated with the user.
> We really want the location of the user, but until we get
> implanted with GPS receivers and radios, we have targets
> that are separate from the user. The other context we
> use "user" is that the user is the source of the privacy
> concern. Ultimately, it is the user that grants rights to
> some other entity to learn the location of the target.

(snip)

> Now, let's look at scenarios. Please remember that these
> are logical functions, and a physical device can have
> multiple functions implemented in it.

The following scenario is just a "target device locating service" -
someone wants to locate something. I think there are lots of other
location services. For example, someone wants to send his location
data to someone even without requests. This is a kind of a location
"push" model - for example, I send my location data to police when
something emergent happens. Also another example is a service to
find anyone (who maybe is willing to anonymously disclose his
location) in a given area.

As a first step, focusing on a concrete type of services is a good
approach. But general terminology and framework should not be
confined to the concrete example.

In that sense, I like the terminology like "location receiver" over
"location requester".

Regards,

Kenji

> First is the simple case of the target actually knowing
> its own location (using, say, GPS), and it having enough
> horsepower to be a PDP/PEP. Then the target has the Server
> and the PDP/PEP collocated in it. A client gets authenticated
> by the server. The server consults its PDP to determine
> if location should be given to the client, applies the
> appropriate policy (PEP) and then sends the result to the
> client.
>
> Next, let's assume that the target knows it's own location,
> but does not have enough horsepower to do all the policy
> application. In such a case, we employ a Proxy Server.
> This is a back to back Client and Server. So, the target
> has a server that has exactly one client, the client side of
> the Proxy Server. The proxy server has the PDP/PEP and other
> clients authorized by the user's policy get location information
> from the server side of the Proxy Server.
>
> Now lets assume that the target doesn't know its location,
> but some other entity does. That entity is just a Server;
> it knows the location of a target, and provides it to clients.
> That server could have the PDP/PEP, or it could use a Proxy
> Server as above.
>
> Now take a translator. It is another instance of a Proxy
> Server that transforms the data between the client side
> and the server side. It, of course, could have the PDP,
> or just the PEP, or it could be, as above, serving only
> one client, which is another Proxy Server that has the PEP.
>
> Of course, in single client servers, PDP and PEP are implemented,
> they are just very simple. So, in reality, every server
> has at least a PEP.
>
> Now we can get arbitrarily complex. Suppose there was a system
> where there were a bunch of targets all served by a "carrier"
> (we don't really care what the thing that serves all these client
> is, it could be an enterprise device), where the server could
> provide a reasonable set of policies and enforce them. A user
> created a policy for that server that applied to a range of
> clients. However, suppose that the server is not all that clever,
> and some enterprising dotcom offers a service to the user that
> provides a more rich policy mechanism than the "carrier" does.
> So, the user authorizes the carrier server to supply location
> to the dotcom, which is another proxy server. The user then
> authorizes another set of clients to the dotcom server.
>
> Either or both of the "carrier" server and the dotcom server
> could provide translation or obfuscation services.
>
> I think that is all we need for nouns.
>
> Brian
Received on Fri Dec 14 21:51:02 2001