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

Hi Jeroen,

Jeroen van Bemmel wrote:
> Hi Hannes,
> 
> see inline
> 
> Regards,
> 
> jeroen
> 
> ----- Original Message ----- From: "Hannes Tschofenig" 
> <[email protected]>
> To: "Jeroen van Bemmel" <[email protected]>
> Cc: "Henning Schulzrinne" <[email protected]>; "IETF SIP List" 
> <[email protected]>; "GEOPRIV" <[email protected]>
> Sent: Sunday, July 30, 2006 7:45 PM
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to 
> location-conveyance
> 
> 
>> Hi Jeroen,
>>
>> in past discussions we concluded that we don't want to have a special 
>> 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?

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.
> 
> 
> 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 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.

> 
> 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).

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

Ciao
Hannes

> 
> Regards,
> 
> jeroen
> 
> 
> 


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