Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

From: Jeroen Van Bemmel <[email-masked]>
Date: Sun, 30 Jul 2006 10:36:28 +0200

Yes,mine too, with one additional remark: the location based routing use case should be removed

It is a special case of a more general one: route to some party in area X. This need not have anything to do with the caller's location, in fact for privacy reasons it is better not.

LBR is better handled using caller prefs/callee capabilities (eg define +geo.zip, not using PIDF at all for simplicity)

Given the above, proxy removal of location and data URIs are less of an issue

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Stark, Barbara" <[email-masked]>
Aan: "Henning Schulzrinne" <[email-masked]>; "Brian Rosen" <[email-masked]>
CC: "IETF SIP List" <[email-masked]>; [email-masked]
Verzonden: 27-7-06 22:02
Onderwerp: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

This gets my vote.
Barbara

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 11:25 PM
> To: Brian Rosen
> Cc: IETF SIP List; [email-masked]
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
> location-conveyance
> 
> 
> My suggestion would be
> 
> - to focus the draft on just defining the Location header syntax,  
> without ruling out any particular mechanism or scheme; this would  
> make the draft really short (which I would find helpful).
> 
> - and then add one section to the draft that prototypically defines  
> what a particular scheme that wants to appear in the Location header  
> needs to define, using the non-controversial cid mechanism as the  
> example. Other, separate, drafts can then define other modes,  
> following the same template. Documents such as the phone-bcp 
> can then  
> pick some suitable must-implement subset and make emergency-call- 
> specific recommendations, rather than sprinkling these 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jul 2006 09:01:24 -0400

> LBR is better handled using caller prefs/callee capabilities (eg  
> define +geo.zip, not using PIDF at all for simplicity)
>

This is completely new suggestion; emergency calling is nothing but a  
special case of location-based routing. I agree that it is useful to  
separate location information for routing from that shown to end  
systems, as they often have different resolution needs. (To route to  
the right branch of your pizza delivery franchiser, you may only need  
a zip code, but for delivery, you need the full street address. The  
practical problem is that such boundaries don't always agree with zip  
codes or any other higher-level geographic unit, such as state,  
county or town.)

Henning

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 30 Jul 2006 16:50:48 +0200

Hi Henning,

Yes, it was intended as a new angle. And you are right that 'zip' is 
probably not enough to cover all cases, my intention in providing the 'geo' 
feature tree as example was to suggest that GEOPRIV might define other 
feature parameters in this space ("country","state" etc are some obvious 
candidates, and "geo.lat" and "geo.lon" perhaps?)

To me, the "emergency calling" use case should indeed be viewed as a 
scenario in which "location conveyance" and "location based routing" are 
combined.

Regards,

Jeroen

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: "Jeroen Van Bemmel" <[email-masked]>
Cc: "IETF SIP List" <[email-masked]>; "GEOPRIV" <[email-masked]>
Sent: Sunday, July 30, 2006 3:01 PM
Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

>> LBR is better handled using caller prefs/callee capabilities (eg  define 
>> +geo.zip, not using PIDF at all for simplicity)
>>
>
> separate location information for routing from that shown to end  systems, 
> as they often have different resolution needs. (To route to  the right 
> branch of your pizza delivery franchiser, you may only need  a zip code, 
> but for delivery, you need the full street address. The  practical problem 
> is that such boundaries don't always agree with zip  codes or any other 
> higher-level geographic unit, such as state,  county or town.)
>
> Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Jul 2006 19:45:19 +0200

Hi Jeroen,

in past discussions we concluded that we don't want to have a special 
encoding for location-based routing.

I agree with Henning that the level of granularity might, in some cases, 
be different depending on the consumer of the PIDF-LO. This is, however, 
more a location-based scenario rather than an emergency calling 
scenario. The problem is that the end host does not necessarily know the 
service boundary ahead of time and hence you don't know the required 
granularity of the location object. If you omit too many elements from 
the PIDF-LO then LoST might just return incorrect information.

Ciao
Hannes

Jeroen van Bemmel wrote:
> probably not enough to cover all cases, my intention in providing the 
> 'geo' feature tree as example was to suggest that GEOPRIV might define 
> other feature parameters in this space ("country","state" etc are some 
> obvious candidates, and "geo.lat" and "geo.lon" perhaps?)
> 
> ----- Original Message ----- From: "Henning Schulzrinne" 
> <[email-masked]>
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 30 Jul 2006 20:29:08 +0200

Hi Hannes,

see inline

Regards,

jeroen

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Henning Schulzrinne" <[email-masked]>; "IETF SIP List" 
<[email-masked]>; "GEOPRIV" <[email-masked]>
Sent: Sunday, July 30, 2006 7:45 PM
Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

> encoding for location-based routing.

I was not aware of any such conclusion. IMHO PIDF-LO is not the answer to 
all location-based problems, but before we delve into that discussion 
again - I was argueing that "location conveyance" and "location based 
routing" are separate cases. Do you agree with that?

A simple illustrative example: suppose I will be going on holiday to Paris 
next week. I want to make a hotel reservation, and call some well-known 
chain of hotels. My location will be somewhere in Holland (at the moment of 
calling), and I want my call to go to their Paris office. How would this 
work with only 1 PIDF-LO?

> more a location-based scenario rather than an emergency calling scenario. 
> The problem is that the end host does not necessarily know the service 
> boundary ahead of time and hence you don't know the required granularity 
> of the location object. If you omit too many elements from the PIDF-LO 
> then LoST might just return incorrect information.

OK, so perhaps the required granularity for matching would have to be 
specified as part of the callee-capabilities. Then an error would occur (eg 
the proxy would return '485 Ambiguous', with candidate contacts) when no 
locations match the given criteria. For specific cases (like Emergency) I 
imagine the required granularity would be defined, such that the UA would 
know in advance.

I understand the desire to limit the number of different formats and 
encodings being used, but caller prefs / callee capabilities is more than a 
format - it is a specific, existing SIP mechanism that can address several 
useful scenarios. It has many benefits - for one, in this way LBR could be 
introduced for existing proxies (that support caller prefs).

Regards,

jeroen

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Jul 2006 20:49:00 +0200

Hi Jeroen,

Jeroen van Bemmel wrote:
> Hi Hannes,
> 
> see inline
> 
> Regards,
> 
> jeroen
> 
> ----- Original Message ----- From: "Hannes Tschofenig" 
> <[email-masked]>
> I was not aware of any such conclusion. IMHO PIDF-LO is not the answer 
> to all location-based problems, but before we delve into that discussion 

I agree with you in various ways. The use case is different, the 
security properties are different and the description in the draft needs 
to describe both cases.

> 
> A simple illustrative example: suppose I will be going on holiday to 
> Paris next week. I want to make a hotel reservation, and call some 
> well-known chain of hotels. My location will be somewhere in Holland (at 
> the moment of calling), and I want my call to go to their Paris office. 
> How would this work with only 1 PIDF-LO?

I guess the use cases most GEOPRIV/ECRIT folks have in mind is a bit 
different.
 From a protocol point of view there is, however, no difference.

> 
>> I agree with Henning that the level of granularity might, in some 
>> cases, be different depending on the consumer of the PIDF-LO. This is, 
>> however, more a location-based scenario rather than an emergency 
>> calling scenario. The problem is that the end host does not 
>> necessarily know the service boundary ahead of time and hence you 
>> don't know the required granularity of the location object. If you 
>> omit too many elements from the PIDF-LO then LoST might just return 
>> incorrect information.
> 
> 
> specified as part of the callee-capabilities. Then an error would occur 
> (eg the proxy would return '485 Ambiguous', with candidate contacts) 
> when no locations match the given criteria. For specific cases (like 
> Emergency) I imagine the required granularity would be defined, such 
> that the UA would know in advance.

I have no problem with two PIDF-LOs in a single message: One for routing 
and the other one for end host consumption. Would this solve your 
concerns already?

For emergency services we know that you have to provide location 
information at a fine grain granularity. In recent discussions we argued 
about the need to include composite location with civic information at a 
floor level.

> encodings being used, but caller prefs / callee capabilities is more 
> than a format - it is a specific, existing SIP mechanism that can 
> address several useful scenarios. It has many benefits - for one, in 
> this way LBR could be introduced for existing proxies (that support 
> caller prefs).

I understood your previous comment as a request to specify a different 
location information format (not PIDF-LO) for location-based routing.

Ciao
Hannes

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 30 Jul 2006 21:51:45 +0200

> location information format (not PIDF-LO) for location-based routing.

That depends, I would be happy with a mapping of PIDF-LO onto callee 
capabilities / caller prefs. Would that be considered a different format?

Jeroen

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 31 Jul 2006 09:15:35 -0400

We have spent a couple of YEARS working on this draft, it has always
considers location based routing one of its uses, and at this point, I think
this idea is not interesting.

Does anyone else besides Jeroen support a different mechanism to convey
location for routing than one for conveying location to the endpoint?

I remind you that many (but not all) location based routing use cases DO
involve conveyance of the location to an endpoint.  The usual case we use
for location based routing besides the emergency case is the pizza delivery
scenario.  You use location to route to the correct store, and the store
gets your location to deliver the pizza.  You don't ALWAYS want to do this,
of course, but it is very common.

At this point, we need fewer options (not only in the draft, in the SIP
world), not more.

Brian

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Sunday, July 30, 2006 3:52 PM
> To: Hannes Tschofenig
> Cc: IETF SIP List; GEOPRIV; Henning Schulzrinne

---

From: Andrew Newton <[email-masked]>
Date: Mon, 31 Jul 2006 09:30:51 -0400

> At this point, we need fewer options (not only in the draft, in the SIP

I agree.  Not only do I not see a need for this, but such a suggestion 
this late in the game without any implementation, specification, or 
formalized use case is not helpful.

-andy