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

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?

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



_______________________________________________
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