Subject: [Geopriv] RE: [Sip] Allowing sip: in location header not good

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jul 2006 16:45:37 -0700

At 6:19 PM -0500 7/20/06, James M. Polk wrote:
>
>If the INVITE has a PIDF-LO with this element
>
>        <retransmission-allowed>no</retransmission-allowed>
>
>Can a ESRP (emergency services routing proxy that does the LoST query for the PSAP URI) send location anywhere?  Geopriv might say no, because it violates one of its "priv" rules. Now what? Do we make an exception?  We have to get their buy-in for this. We don't have it yet.

Do you mean "send onward in the SIP signaling path" or "send to the LoST server"?

The problem here is that if the originating client has to allow all retransmission
in order to get the call through, their privacy protection has gone to nil; in
places where you have to be able to protect privacy during the emergency
call, that's a problem.  So just saying "it must be set to 'yes'" doesn't solve
the problem.  I think we really need to be able to distinguish between
using the location to route the call and forwarding the target of the call
forwarding the location; I believe that means we need to be able to break
the first out of "retransmission-allowed" into a separate permission.

My two cents,
				Ted

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 20 Jul 2006 18:55:44 -0500

I don't think that you need to preclude the use of SIP here, but there are a lot of things that need to be considered before SUB/NOT are allowed.

That is to say - the location conveyance document doesn't cover its use, and nothing else does...yet.  When someone does a using-protocol specification for SUB/NOT, then we have a place to describe how to use sip[s]: in the Location header.

Fact is - I don't think that we have ANY using-protocol defined, hence the problems we are having in deciding what goes in the header.

>                  (and I'm not so sure about 'pres')

A pres: URI is in effect a sip[s]: URI for these purposes.

Cheers,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Jul 2006 20:54:35 -0400

I think that ship has sailed.  PIDF-LO is precisely defined in presence, and
we don't need any documents that further describe how location is conveyed
in a presence subscription.  All this document would do is describe how you
might go about specifying a presence uri that would be a little less general
(provide less information) than the one you would get by using the "From:"
URI.  The ruleset for this presence uri would be different from the more
general uri.  

Now, it does occur to me that if we allow sip/sips/pres, then we have a
minimal resolution protocol for location by reference.  It might be then
acceptable to drop the whole raw GET idea completely, and leave that to the
L7 protocol.  I kind of like that idea, because the raw GET is really
defining a whole new protocol and I don't think we want to, or need to, do
that in this document.  We brought it up because without at least a minimal
dereference solution, the mechanism does not meet the requirements.  A
presence subscription would do that, with no need for more.

And if we do that, we could drop the resolution-protocol parameter and
registry, because sip/sips/pres doesn't need it.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 7:56 PM
> To: James M. Polk; Brian Rosen; [email-masked]; [email-masked]
> Subject: RE: [Sip] Allowing sip: in location header not good
> 
> I don't think that you need to preclude the use of SIP here, but there are
> a lot of things that need to be considered before SUB/NOT are allowed.
> 
> That is to say - the location conveyance document doesn't cover its use,
> and nothing else does...yet.  When someone does a using-protocol
> specification for SUB/NOT, then we have a place to describe how to use
> sip[s]: in the Location header.
> 
> Fact is - I don't think that we have ANY using-protocol defined, hence the
> problems we are having in deciding what goes in the header.
> 
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Jul 2006 21:14:40 -0500

> registry, because sip/sips/pres doesn't need it.

Brian's words here are the first to make me say "Aha! I think we have 
something new" that I've read so far this evening. There may be some 
merit in this approach -- please consider it carefully.

--
Dean