Subject: [Ecrit] New ID creating Geocoding URN

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 18:19:51 -0500

ECRIT

I have written a new ID creating URNs for Geocoding and 
Reverse-Geocoding using LoST.

http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.txt

This draft is not in a preliminary state, and I hope to have a more 
complete version out by Stockholm.

This is a fairly simple draft that merely creates the URNs, and 
specifies how LoST can be used to convert Geo to civic, and civic to Geo.

I hope this idea will not become anything that's complicated.

Comments are appreciated.

James

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Jul 2009 09:48:52 -0400

James,

I'm a little puzzled as to why you would want to use LoST for [reverse] 
geocoding -- unless you were trying to discover a geocoding service for 
a particular region.

For just trading civic vs. geodetic information, it would seem much more 
appropriate to use HELD as a baseline, as in
<http://tools.ietf.org/html/draft-george-geopriv-address-translation-01>

--Richard

James M. Polk wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Jul 2009 14:19:41 -0500

At 08:48 AM 7/17/2009, Richard Barnes wrote:
>James,
>
>I'm a little puzzled as to why you would want to use LoST for 
>[reverse] geocoding -- unless you were trying to discover a 
>geocoding service for a particular region.

It seems to me that LoST servers will not be that overloaded (though 
I could be underestimating), and these servers will have both formats 
for each location anyway.  Why not have them just do the conversion 
between the formats too, as a service.

>For just trading civic vs. geodetic information, it would seem much 
>more appropriate to use HELD as a baseline, as in

I'm not sure HELD will be in every device, which would be required 
for/by this ID, correct?

We believe LoST will be in every current (at some point) and future 
device, so this seems like a natural fit, given the LoST function is 
already there. Anything else would be new (unless you consider SIP 
subscribe to do geocoding - which will likely also be there in each 
current and future device).

James

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Jul 2009 16:29:48 -0400

Hey James,

>> [reverse] geocoding ...
> It seems to me that LoST servers will not be that overloaded (though I 
> could be underestimating), 

There's nothing preventing these servers from offering a different 
interface.  Heck, both LoST and HELD are HTTP-based, so it'll probably 
just be another servlet / script / etc.

> I'm not sure HELD will be in every device, which would be required 

Last I read phonebcp, HELD and DHCP were required in the same places.

Moreover, geocoding is useful in many cases outside of emergency 
services, so devices that aren't capable of emergency calling might 
still want to do it.  These devices won't necessarily have LoST 
libraries, so there's no inherent advantage there to using LoST.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Jul 2009 18:06:56 -0500

At 03:29 PM 7/17/2009, Richard Barnes wrote:
>>It seems to me that LoST servers will not be that overloaded 
>>(though I could be underestimating),
>
>interface.  Heck, both LoST and HELD are HTTP-based, so it'll 
>probably just be another servlet / script / etc.

fair comment - but this is a draw IMO

>>>For just trading civic vs. geodetic information, it would seem 
>>>much more appropriate to use HELD as a baseline, as in

true - but since devices are made by vendors, they will choose to 
implement what they want to implement (and I'm not just talking about 
Cisco), regardless of what a spec says. The all mighty RFP is 
mightier than the RFC (regrettably)   ;-)

>still want to do it.

ok - to that I'd say that LoST is definitely more useful than just 
for emergency calling too.  The ECRIT WG reached consensus that LoST 
and the service URNs are to be extended in ECRIT even if the 
particular service has nothing to do with emergency calling. There 
was a lively and open debate about this in Vancouver.

I'd further say that applications that likely are intelligent enough 
to know the difference between the two formats will be more 
intelligent than a palette, thus making them (probably) more often 
than not able to signal an emergency - even if the likely won't in 
their lifetime.

Smart phones is a good example of this. Not-so-smart phones probably 
will also have LoST in them, so coding the new URN seems like a 
no-brainer to me.

>These devices

which devices? boxes, palettes or phones?

>won't necessarily have LoST libraries, so there's no inherent 
>advantage there to using LoST.

I believe the latter of the list above will, and will probably be the 
type of devices that knows enough to do the geocoding transaction. 
I'm not thinking palettes or boxes will have the choice of more than 
one location format, much less know to ask for another one.

My draft is targeted at devices that have applications that are smart 
enough to know there is a difference and to ask for the more 
preferred format if they only receive a format that know isn't what 
they prefer.

James

---

From: Robins George <[email-masked]>
Date: Thu, 30 Jul 2009 09:10:44 +0200

James,

HELD extension would be a better choice for Geocoding and 
Reverse-Geocoding. More over address translation is useful in many cases 
other than emergency services, where LoST is not required.

On 7/18/2009 1:06 AM, James M. Polk wrote:
>>> I could be underestimating),
>>
> Cisco), regardless of what a spec says. The all mighty RFP is mightier 
> than the RFC (regrettably)   ;-)
>
>
> ok - to that I'd say that LoST is definitely more useful than just for 
> emergency calling too.  The ECRIT WG reached consensus that LoST and 
> the service URNs are to be extended in ECRIT even if the particular 
> service has nothing to do with emergency calling. There was a lively 
> and open debate about this in Vancouver.
>
> type of devices that knows enough to do the geocoding transaction. I'm 
> not thinking palettes or boxes will have the choice of more than one 
> location format, much less know to ask for another one.
>
> enough to know there is a difference and to ask for the more preferred 
> format if they only receive a format that know isn't what they prefer.
>
> James
>
>
>> --Richard
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 02:51:47 -0500

Hi Robins,

We discussed this in the meeting and came to the conclusion that your geocoding draft might be a more appropriate means of actually making the geocoding request.  Brian suggested that the scope might be extended to include a more general "PIDF-LO transformation" - something that is apparently necessary in the 'states for translating between emergency-useful civic location and postal-useful civic location for instance.  I'm certainly interested in seeing that work progress.

However, use of LoST in _discovering_ a server that is capable of providing this service was still a useful thing.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robins George
> Sent: Thursday, 30 July 2009 9:11 AM
> To: James M. Polk
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] New ID creating Geocoding URN
> 
> James,
> 
> much
> for
> I'm
> preferred

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Robins George <[email-masked]>
Date: Thu, 30 Jul 2009 10:53:40 +0200

Hi Martin,

> We discussed this in the meeting and came to the conclusion that your geocoding draft might be a more appropriate means of actually making the geocoding request.  Brian suggested that the scope mig…

I do understand Brian's concern to include presence information and I'll 
work on it to produce a revision of this draft.
> However, use of LoST in _discovering_ a server that is capable of providing this service was still a useful thing.
I agree.

--Robins

[Apologies for not attending the face-to-face discussion, I was in 
another meeting]

>> (though
>>>>>> <http://tools.ietf.org/html/draft-george-geopriv-address-
>>>>>>              
>> translation-01>
>>      
>>>>>>              
>>>> Last I read phonebcp, HELD and DHCP were required in the same
>>>>          
>> places.
>>      
>> mightier
>>> format if they only receive a format that know isn't what they
>>>        
>> prefer.
>>      
>>> James
>>>
>>>
>>>        
>>>> --Richard
>>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 30 Jul 2009 05:01:27 -0400

What I suggested is that we need a generalized PIDF-LO to PIDF-LO
transformation service.  The service would take a PIDF and some set of
parameters and transform the input PIDF to an output PIDF.  One
transformation is geocode/reverse geocode.  Another might be to transform
from one form of civic address to another (which was my example).  

I do not want to overload either LoST or HELD with this service. It doesn't
have the same inputs and/or outputs.  Make it a different service, defined
to do the specific task at hand.

Brian

> Sent: Thursday, July 30, 2009 4:54 AM
> To: Thomson, Martin
> Cc: ECRIT
> > We discussed this in the meeting and came to the conclusion that your
> geocoding draft might be a more appropriate means of actually making
> the geocoding request.  Brian suggested that the scope might be
> extended to include a more general "PIDF-LO transformation" - something
> that is apparently necessary in the 'states for translating between
> emergency-useful civic location and postal-useful civic location for
> instance.  I'm certainly interested in seeing that work progress.
> >
> >
> 
> > However, use of LoST in _discovering_ a server that is capable of
> providing this service was still a useful thing.
> >
> >
> I agree.
> 
> --Robins
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Jul 2009 11:09:35 +0200

>to do the specific task at hand.

What permissions need to be granted in order to allow this transformation?
Are we sure that the privacy considerations are the same, and that the rule-makers
original decision on what rules to apply can be applied to a transformed
PIDF-LO?  Especially if the transformation is not simple geocoding?

Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 04:10:06 -0500

I agree. It's a different service. I don't know if folk think that
overloading services is a quicker way to get a spec... it's not in my
experience. And modular design, as in almost all engineering, is a
better approach to protocol specification.

Cheers,
Martin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Thursday, 30 July 2009 7:01 PM
To: 'Robins George'; Thomson, Martin
Cc: 'ECRIT'
Subject: Re: [Ecrit] New ID creating Geocoding URN

transformation is geocode/reverse geocode.  Another might be to
transform

I do not want to overload either LoST or HELD with this service. It
doesn't
have the same inputs and/or outputs.  Make it a different service,
defined
to do the specific task at hand.

Brian

> >>> format if they only receive a format that know isn't what they
---------------------------------------------------------------------
> ---------------------------
---------------------------------------------------------------------
> ---------------------------
> > [mf2]
> >
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 30 Jul 2009 05:23:00 -0400

Generally, I would think that the PIDF still represents the location of a
target, and its privacy considerations would be the same.  I'm sanguine on
whether you need explicit permission to transform, but you certainly need to
respect the same restrictions on dissemination as the original.

An interesting transform is "fuzz", i.e. make location less precise.  That
may be allowed to have a less restrictive ruleset than the original.  The RM
would have to do that itself of course.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 5:10 AM
> To: Brian Rosen; 'Robins George'; 'Thomson, Martin'
> Cc: 'ECRIT'
> >> >> Reverse-Geocoding. More over address translation is useful in
> many
> >> >> cases
> >> >>> I believe the latter of the list above will, and will probably
> be
> >> the