RE: Requirements Document

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
>
Received on Fri Aug 24 15:47:15 2001