Re: Requirements Document

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.

"Rosen, Brian" wrote:
>
> 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: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
> > Sent: Friday, August 24, 2001 2:40 PM
> > To: Rosen, Brian
> > Cc: 'John W Noerenberg II'; geopriv@mail.apps.ietf.org
> > 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
> >

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