Subject: [Sip] SIP Location Conveyance: dereferencing location-by-reference

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Jul 2006 08:53:40 -0400

In sip-location-conveyance, we allow a URI in the Location header to provide
for location-by-reference.  We must have some kind of text that says what
the recipient does with this URI.

Our proposal is to change the ABNF, which currently allows this URI to be
AbsoluteURI (meaning any scheme) and replace it with HTTP/HTTPS only.  Of
course, there would still be the cid: for message body identification.  We
would then define a dereference process as doing an HTTP/HTTPS GET, with no
parameters, on the URI, and expect to receive in return a PIDF-LO, exactly
as it would appear in a body.  The text would state MUST implement TLS,
except for the emergency case.  The text would further state that additional
dereferencing procedures could be defined by a standards track RFC.

Brian and James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 18 Jul 2006 18:12:18 -0500

I see no harm in simplifying the header to be just 'absoluteURI' as in RFC 3986.  Text in the document can say that implementations MUST support https: and cid: (with appropriate cautions regarding the degenerate case of http:).

Andy,

Discussions to date on a subscription URI indicate that it is for LIS -> Target purposes only.  We have not yet reached the point where we discuss the creation of a reference.  There are obvious similarities, but I think that we would need to resolve some privacy and security concerns first.

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, 19 July 2006 7:25 AM
> To: Brian Rosen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] SIP Location Conveyance:dereferencing location-by-
> reference
> 
> 
> 
> Brian Rosen wrote:
> I'm not sure it is as simple as this.
> 
> What happens when a client gets a subscribable location reference URI
> via the L7-LCP, and puts that into a Location header in an INVITE?  How
> is the subscription done with HTTP?
> 
> -andy
> 
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Tue, 18 Jul 2006 17:25:00 -0400

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Jul 2006 11:29:45 -0500

At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote:

>What happens when a client gets a subscribable location reference URI via 
>the L7-LCP,

you mean a SIP or SIPS URI?

You expect SIP to be a dereference capable protocol?  Why?

>and puts that into a Location header in an INVITE?

INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into a 
Location header that's in an INVITE wouldn't create a subscription in the 
first place.

The above offering is to make sure dereferencing is done with HTTP/HTTPS, 
not SIP.

>  How is the subscription done with HTTP?

It isn't done with an INVITE either. sorry...

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2006 13:00:51 -0400

I suspect we're talking about two different use cases:

- proxies will find subscriptions rather tedious when doing call routing 
(do a SUBSCRIBE, wait for authorization, NOTIFY just to get a location 
to route a call?), and don't get any benefit from the subscription model;

- UASs will find subscriptions helpful, in some limited circumstances 
(e.g., if I call OnStar for directions, they might want to see where I'm 
going in real time, rather than where I was five minutes ago while all 
their agents were busy assisting other customers)

I don't see particular security issues as long as the UAC realizes that 
any subscription URI that it hands out might be used by anybody that is 
on the call path. In some cases, that's an acceptable model, 
particularly if the caller identity is obscured, so that you only know 
that "random caller abc17 is at location X waiting for tow truck". (In 
that case, subscriptions are probably somewhat pointless.)

In short, I think we should allow all of these and simply make sensible 
recommendations, such as that location information meant for call 
routing should NOT just use subscriptions and also provide location 
by-value/by-attachment, simply because location subscriptions are too 
painful and useless for proxies in practice.

Henning

Andrew Newton wrote:
> James M. Polk wrote:
>>> via the L7-LCP,
> I actually didn't mention SIP as the dereference protocol.  What I am 
> asking is which dereference protocol with a subscription mechanism are 
> you going to specify?  Or should implementers assume XMPP for this 
> feature? :)
> 
>> INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put 
>> into a Location header that's in an INVITE wouldn't create a 
>> subscription in the first place.
> 
> Thanks for the clarification, but I was talking about the dereference 
> being orchestrated via subscription rather than polling.  I wasn't 
> really talking about the conveyance itself, other than to ask how a 
> conveyee is to know what to do with the reference.
> 
>> The above offering is to make sure dereferencing is done with 
>> HTTP/HTTPS, not SIP.
> 
> I know, which is why I asked...
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Jul 2006 13:58:52 -0400

The original message said:
  The text would further state that additional dereferencing procedures
  could be defined by a standards track RFC.

Therefore, the proposed L7 protocol could specify its own dereference
procedure, including a subscription process.  We already have the mechanisms
needed to get a presence subscription out of an AoR.

Given the security concerns about location, it does seem wise to restrict
what kind of URI can be a location-by-reference to those that have reviews
of the geopriv privacy concerns.  I don't think we need to make the
mechanism completely general at the outset.  We propose to have the basic
mechanism be readily extensible by standards track RFCs.  That would seem to
balance security concerns against utility.

Brian

> Sent: Wednesday, July 19, 2006 12:51 PM
> To: James M. Polk
> Cc: Brian Rosen; [email-masked]; [email-masked]
> Subject: Re: [Sip] Re: [Geopriv] SIP Location Conveyance: dereferencing
> location-by-reference
> 
> James M. Polk wrote:
> > INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put into
> > a Location header that's in an INVITE wouldn't create a subscription in
> > the first place.
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Jul 2006 12:58:00 -0400

> Discussions to date on a subscription URI indicate that it is for LIS -> Target purposes only.  We have not yet reached the point where we discuss the creation of a reference.  There are obvious si…

Excuse me for not understanding, but LIS -> Target seems to miss the 
need outlined in the use case given on the L7-LCP DT list... which is a 
mobile device that has a link that very much looks like a fixed wired 
connection (and LI is derived from the network, i.e. not GPS).

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Jul 2006 12:51:13 -0400

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Jul 2006 13:28:28 -0400

> painful and useless for proxies in practice.

Agreed.  And I'm not advocating that subscription is the only method, it 
was just my understanding that there was a desire to have it.

What I would like is a small list of things I need to implement. 
AbsoluteURI leaves the number of possibilities wide open.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Jul 2006 14:46:51 -0500

At 12:51 PM 7/19/2006 -0400, Andrew Newton wrote:
>I actually didn't mention SIP as the dereference protocol.

you mentioned subscriptions, and sip-location-conveyance doesn't, but SIP 
does with SUBSCRIBE - so I made that leap.

Why do you want a subscription, and where's the requirement for that? The 
ID currently doesn't have one.

>What I am asking is which dereference protocol with a subscription 
>mechanism are you going to specify?  Or should implementers assume XMPP 
>for this feature? :)
>
>being orchestrated via subscription rather than polling.  I wasn't really 
>talking about the conveyance itself, other than to ask how a conveyee is 
>to know what to do with the reference.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Jul 2006 17:44:11 -0500

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 20 July 2006 3:01 AM
> To: Andrew Newton
> Cc: [email-masked]; [email-masked]; James M. Polk
> Subject: Re: [Sip] Re: [Geopriv] SIP LocationConveyance: dereferencing
> location-by-reference
> 

I disagree - this sort of system is, in effect, provided by a cellular network.  For Phase II, PSAPs are, in effect, given a reference to location information (through the callback number, and, in the US, the chain through the ALI).
 
> painful and useless for proxies in practice.

I am happy with that conclusion.  Keep the basic element simple, and provide guidance so that it isn't misused.