Subject: RE: Requirements Document

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Aug 2001 15:47:42 -0400

Hmmm, I'm sorry if I'm being dense.

Do I interpret correctly what you are saying is that:
1. The primary goal is to define an object meeting the privacy
and security requirements for a broad range of uses, of
which emergency services is but one example
2. Binding such an object to HTTP is secondary, and intended to
be (usefully) illustrative of how the object should be used

I have no intention of trying to go outside this group
to solve the emergency call problem.  What I want to do is
make sure the object as defined is useful in that environment,
and similar environments.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 2:40 PM
> To: Rosen, Brian
> Cc: 'John W Noerenberg II'; [email-masked]
> Subject: RE: Requirements Document
> 
> 
> > I'm sorry, but if this group can't generate a solution
> > for emergency calls in a SIP environment, we need to
> > spin up a group RIGHT NOW for that purpose.
> 
> Given the difficulty this group had getting chartered, 
> there's precious little
> chance of chartering such a group, regardless of how urgent 
> you believe the
> need for such a group to be. So I strongly recommend that you 
> try and work
> towards getting an acceptable solution here.
> 
> > I do not read the charter as anywhere near that limiting.
> > In fact, I read it as it will define an object suitable for
> > a wide range of uses, and illustrate it with HTTP.
> 
> The primary goal is to meet the privacy and security 
> requirements set forth in
> the charter. This is absolute and nonnegotiable, and while 
> this group may elect
> to (and IMO should) provide mechanisms for emergency calls, a 
> broader range of
> scenarios much be dealt with as well.
> 
> A secondary goal is to produce a binding of the 
> object/exchange mechanism this
> group comes up with to HTTP.
> 
> I suppose it is possible that whatever this group decides is necessary
> isn't well matched to HTTP. If that's the case then so be it 
> -- privacy
> and security concerns are paramount here.
> 
> 				Ned
>

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 24 Aug 2001 23:31:37 -0400

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").

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.)

HTTP is only one of many such examples, with SMTP, RTSP and SIP being
other obvious candidates, in addition to the various emerging
presence/IM candidate protocols. (DNS is not very interesting since it's
designed as a repository of public information, so worrying about the
privacy of information contained in DNS seems somewhat besides the
point.)

- 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);

- 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).

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.

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. I don't
think we need (or can) settle this now, but I wouldn't want to assume
that we need new mechanisms, given that most application-layer protocols
carry other information which also has concerns about privacy or
authenticity.

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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: [email-masked]
Date: Fri, 24 Aug 2001 15:23:04 -0700 (PDT)

> be (usefully) illustrative of how the object should be used

This is correct, more or less.

> and similar environments.

And you do this by making sure the requirements allow for the
emergency call case in addition to the other cases we must cover.

				Ned

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 30 Aug 2001 12:49:27 -0700

>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.

>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.
>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.

>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)?

>colored by how people see this stuff working in practice.

Very true.

>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.

>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
[email-masked]
   ----------------------------------------------------------------------
   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
   ----------------------------------------------------------------------