RE: Back to terminology

Jorge,

IMHO, this is the best shot so far at defining a consistent terminology. The only thing I have a problem with is the distinction between four different types of location recipients (4, 5, 6, 8). I may be a little out-of-sync here since I didn't participate in the SLC meeting, but I'll raise this point anyway:

- An entity that acts as a "location server" by your definition always takes on the role of a "(private) location recipient" at the same time (otherwise it wouldn't possess any location information to begin with). An "ultimate location recipient" is an entity that assumes the role of a "(private) location recipient", but not the role of a "location server". Therefore, one of these three terms seems to be redundant.

- Whether or not a "(private) location recipient" is "ultimate" or a "location server" (it has to be one of these two) seems to be mainly a question of roles and business models. From a technical point of view, what we should focus on is _policies_. Using policies, the "owner" could specify whether or not it allows a "(private) location recipient" to further pass on the location information to third parties, or not. Likewise, a "(private) location recipient" could specify what it intends to do with the location information (pass it on, use it for own location-based services, etc.). Therefore, I would opt for dropping the "ultimate location recipient" and putting more emphasis on what exactly a policy can specify.

- Number 6 is completely obsolete, IMHO. Why would you want to treat an access network operator differently from any other entity? The access network provider clearly is a "location data source" (it can't help knowing my location) and a "(private) location recipient" (could be "ultimate" or "location server", see above) that uses the location information for certain purposes (the most obvious being the mobility management in a mobile access network). Again, it will be up to the _policies_ specifies by the "owner" what the access network provider is allowed to do or not (i.e. pass it on to third parties, send location-based advertisement, publish it on the Web, etc.). There is little difference, for example, to a bank that happens to know - from the fact that I inserted my credit card into a teller machine - that I am in Stockholm (well, more precisely it knows that my credit card is in Stockholm, along with someone who knows the PIN, but that doesn't make any difference !
here). The bank will have to exploit this knowledge in order to provide the service that I have requested (i.e. checking my account balance back home in Germany and paying money to me in Stockholm), but I certainly wouldn't like the bank to further communicate this information to third parties without my explicit consent. In the future, I may not even use a credit card but a mobile phone or PDA to convince the teller machine to give me money, and then the borderline gets even more blurry. Therefore, I see no point in treating the access network operator any different from the provider of any other service that happens to be aware of my location.

- 5 has some justification, but again I am not sure this case needs to be treated separately. Let's call this a "lawful location recipient" just to give it a name. Any transfer of location data from a "location server" to any type of "location recipient" will require proper authentication (at least of the "location recipient" to the "location server") and authorization (e.g. enforcing the "owners" policies in some way). We could try to also treat this case via policies. These would specify that certain properly authenticated "lawful location recipients" are always authorized to get any location information they ask for. These policies would have a higher priority than those of the "owner", i.e. the owner cannot override them.

Best regards,
Axel
Received on Wed Feb 6 10:56:06 2002