Re: Requirements Document

At 11:31 PM -0400 8/24/01, Henning G. Schulzrinne wrote:
>I believe that one part of the communication problem we seem to be
>having is that different people seem to have very different models as to
>where and how various pieces are to be used. As far as I can tell:
>
>- Some seem to look at objects (presumably meaning pieces of text or
>binary information) carried in existing protocols, with the location
>object injected by the requestor ("client").

Implications of carrying location information in existing protocols
is certainly part of what we must do. We need to consider the
adoption of a different exchange protocol, as well.

>
>Here, the sender - human or its agent - primarily needs to be sure that
>it reveals the information it wants to the party it thinks it is
>revealing it to. As I tried to say before (and Brian has been arguing, I
>believe) is that this case is primarily a UI issue, once the identity of
>the object-receiving side has been verified. (I'm being very loose with
>the term identity here since it may well be the case that I don't care
>about the precise name, but rather some authorization or credential.)

When you're talking about the presentation of the information
exchange, I agree, it is a UI issue. But presentation issues need to
be excluded from what we require because presentation is not an
over-the-wire issue. The location object exchange is the
over-the-wire problem we're tackling.
>
>- others think of existing protocols, with location information injected
>into these by some intermediate entity (e.g., a proxy cache in the case
>of HTTP or a MTA in the case of SMTP or a proxy in the case of SIP);

This is a distinction I hadn't considered. It's not an approach I
favor, because it breaks end-to-end authentication and encryption.
Not to be too dogmatic, it's worthwhile considering what end-to-end
means. That gets into the scenario analysis you propose.

>
>- others seem to focus on entities being queried by third parties for
>their location, possibly as part of some larger exchange (e.g., HTTP
>request generates a separate query for location, rather than including
>the information in the original request).

How does this differ from the first case where the location object
exchange is embedded in an existing protocol (presumably by extending
the protocol to understand a location object)?

>I'm sure I'm missing other scenarios that are implied in people's
>responses. We want to be model-independent in our requirements, but
>without at least some common understanding, requirements tend to be
>colored by how people see this stuff working in practice.

Very true.

>
>The interesting part will be, I believe, for the first and to a lesser
>extent second case, is whether existing authentication mechanisms, for
>example, are sufficient or whether new mechanisms are needed.

This is the crux of the matter. Location coordinate systems are
pretty well understood. A corollary problem is how authentication
negotiation affects the precision of what is revealed about location.

>
>Since we seem to be talking past each other, maybe some example protocol
>scenarios (not details) might get everyone on the same page.

Sounds like a good idea. In fact, Kenji has already examined this to
some degree in
draft-takahashi-spatial-privacy-scenario-00.txt. I haven't given it
a thoughtful read, but it looks like a reasonable beginning.

-- 
john noerenberg
jwn2@qualcomm.com
   ----------------------------------------------------------------------
   Perfect authentication would mean that others know for certain all the
   facts about you.  Happiness comes from others knowing a good deal less.
   -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999
   ----------------------------------------------------------------------