Subject: [Geopriv] HELD: user-configured data

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Apr 2015 21:36:53 +0000

I haven't been following the measurement work all that closely, but I'm curious about the following use case:

Can we use a model similar to RFC 7105 for updating user-configured (civic) location data in VoIP scenarios?

The use case scenario is:

(1) User enters their civic address in a non-web SIP UA.
(2) UA delivers update to LIS, via HELD.
(3) Error is returned if validation fails.

Henning

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Apr 2015 15:32:48 -0700

> Can we use a model similar to RFC 7105 for updating user-configured (civic) location data in VoIP scenarios?

'twould require definition of a new measurement type that used the
civic address schema.

The success response would likely turn into an echo of the address;
failure would not include the information.  There wouldn't be any way
to annotate that with extra information about what went wrong in the
same way that recent additions to LoST might.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Apr 2015 22:43:08 +0000

I'm not wedded to the method at all, but that was the only one that seemed close... A validation query via LoST might be a good option (i.e., first LoST, then HELD).

________________________________________
From: Martin Thomson [[email-masked]]
Sent: Thursday, April 23, 2015 6:32 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Geopriv] HELD: user-configured data

---

From: James Winterbottom <[email-masked]>
Date: Fri, 24 Apr 2015 18:16:32 +1000

I guess that this would ensure that location was “valid”, but doesn’t it open the system up to the “Where would I like to be today” issue that is impacting i2 to some extent?
The LIS is supposed to provide some kind of assurances on the location it provides, if it can be independently user-populated it kind of feels like this aspect of the LIS is going away.

Cheers
James

> On 24 Apr 2015, at 8:43 am, Henning Schulzrinne <[email-masked]> wrote:
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 25 Apr 2015 12:49:33 +0000

James,

I'm struggling with the problem that deployment of LIS by ISP has been slow (and this is more glacier-slow than snail-slow). Thus, I'm afraid that user-provided location will be with us for quite a while, for landline and nomadic devices.

In my particular use case (VRS), faking locations seems less likely since the caller is a known entity.

In addition, there is some ability to validate the rough location by IP address.

Besides a custom web page, we don't seem to have any good standards-based options at the moment. I'd like to be able to automate the process a bit, so that the UA can detect changes in network attachment point and prompt the user for new location data.

Henning

________________________________________
From: James Winterbottom [[email-masked]]
Sent: Friday, April 24, 2015 4:16 AM
To: Henning Schulzrinne
Cc: Martin Thomson; [email-masked]
Subject: Re: [Geopriv] HELD: user-configured data

Cheers
James

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 25 Apr 2015 14:34:02 +0000

The i2 mechanism is using a web page.

It seems you are arguing that it’s more likely the user would update her address on a phone device using something other than a browser interface than using a computer or a browser interface on the device.  That seems unlikely to me.  Further, in the VRS case, the device is provided by the same entity as the LIS provider, so even if it was a non-browser interface, it could update the existing database.

The prompt to do it seems independent of the mechanism to do the update.

Brian

> On Apr 25, 2015, at 8:49 AM, Henning Schulzrinne <[email-masked]> wrote:
> 
> James,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Apr 2015 15:40:47 +0000

Brian,

The "UA provider = service provider" may have been true in the past, but you are familiar with efforts on VRS to create a uniform (multi-provider) VRS SIP UA. Yes, there's a reason for my question...

It would be really nice if a user didn't have to update multiple location databases manually, each via their own web page.

Henning

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Saturday, April 25, 2015 10:34 AM
To: Henning Schulzrinne
Cc: James Winterbottom; [email-masked]
Subject: Re: [Geopriv] HELD: user-configured data

It seems you are arguing that it's more likely the user would update her address on a phone device using something other than a browser interface than using a computer or a browser interface on the device.  That seems unlikely to me.  Further, in the VRS case, the device is provided by the same entity as the LIS provider, so even if it was a non-browser interface, it could update the existing database.

Brian

> I guess that this would ensure that location was "valid", but doesn't it open the system up to the "Where would I like to be today" issue that is impacting i2 to some extent?

---

From: James Winterbottom <[email-masked]>
Date: Thu, 30 Apr 2015 02:49:03 +1000

Hi Henning,

Just so I am 100% sure on what you are querying/asking about.
A device is able to use HELD to update its location in a LIS and the LIS would then validate the location and store it against the IP address of the device?

Is there an assumption that from that time forward that the location is statically bound to that IP address?
So, if the initial device, device-X, pushed something that bound IP address ABC to location EFG that this remains in the LIS. Then if device-X disconnects from the network, device-Y connects and allocated IP address ABC that it will then be at location EFG? The net result being that the LIS is populated via crowd-sourcing?

If the location could be different each time address ABC is allocated then I am not really sure why the device wouldn’t just keep the location in the device and send a PIDF-LO at INVITE or REGISTER time.

I am not necessarily opposed to the idea because I think I  only half understand the use case.

Cheers
James

> On 30 Apr 2015, at 1:40 am, Henning Schulzrinne <[email-masked]> wrote:
> 
> Brian,
>