Re: [Geopriv] HELD: user-configured data

Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> Wed, 29 April 2015 15:41 UTC

Return-Path: <Henning.Schulzrinne@fcc.gov>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065E91A1B22 for <geopriv@ietfa.amsl.com>; Wed, 29 Apr 2015 08:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_EbAaiqI10Q for <geopriv@ietfa.amsl.com>; Wed, 29 Apr 2015 08:41:11 -0700 (PDT)
Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id EB49C1A6FCB for <geopriv@ietf.org>; Wed, 29 Apr 2015 08:40:49 -0700 (PDT)
Message-ID: <E6A16181E5FD2F46B962315BB05962D07D338634@fcc.gov>
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
To: "'Rosen, Brian'" <Brian.Rosen@neustar.biz>
Thread-Topic: [Geopriv] HELD: user-configured data
Thread-Index: AdB+DVAsfrtK/5I1T2CjgnoZPVLhZwAKaPIA//+/iq+AAOONAIABmf/XgABhzwD/+efPYA==
Date: Wed, 29 Apr 2015 15:40:47 +0000
References: <E6A16181E5FD2F46B962315BB05962D07D336F45@fcc.gov> <,> <CABkgnnWcLErqa4b6CGUKgLVuc6HDQFdiR9nFZnzFDX20G=C3YA@mail.gmail.com> <E6A16181E5FD2F46B962315BB05962D07D337042@fcc.gov> <30BDAF1D-6F50-4053-AA7F-818BD6E68043@gmail.com> <E6A16181E5FD2F46B962315BB05962D07D3376E1@fcc.gov> <61D3E84D-765D-45C3-8A75-7DB5A3473DF0@neustar.biz>
In-Reply-To: <61D3E84D-765D-45C3-8A75-7DB5A3473DF0@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/geopriv/t3DxOfaeWKhccVYf00YdVvcFibY>
Cc: "geopriv@ietf.org" <geopriv@ietf.org>
Subject: Re: [Geopriv] HELD: user-configured data
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv/>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2015 15:41:14 -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:Brian.Rosen@neustar.biz] 
Sent: Saturday, April 25, 2015 10:34 AM
To: Henning Schulzrinne
Cc: James Winterbottom; geopriv@ietf.org
Subject: Re: [Geopriv] HELD: user-configured data

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 <Henning.Schulzrinne@fcc.gov>; wrote:
> 
> 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 [a.james.winterbottom@gmail.com]
> Sent: Friday, April 24, 2015 4:16 AM
> To: Henning Schulzrinne
> Cc: Martin Thomson; geopriv@ietf.org
> Subject: Re: [Geopriv] HELD: user-configured data
> 
> 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 <Henning.Schulzrinne@fcc.gov>; wrote:
>> 
>> 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 [martin.thomson@gmail.com]
>> Sent: Thursday, April 23, 2015 6:32 PM
>> To: Henning Schulzrinne
>> Cc: geopriv@ietf.org
>> Subject: Re: [Geopriv] HELD: user-configured data
>> 
>> On 23 April 2015 at 14:36, Henning Schulzrinne 
>> <Henning.Schulzrinne@fcc.gov>; wrote:
>>> 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.
>> 
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv