Subject: [Ecrit] Revved the Transformations URN ID

From: "James M. Polk" <[email-masked]>
Date: Mon, 15 Mar 2010 14:08:53 -0500

ECRIT

re: 
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-transformations-urn-01.txt

This version is much more complete (only lacking the LoST examples).

There only sticking point is whether LoST should be used by a client 
to get this information - or if a pure HTTP transaction should be 
used to geocode/reverse-geocode.

I believe it is fairly logical for a URN to identify the service of 
"format transformation".

I believe a client will not generally know which server to ask for 
this information -- without that server being a "Google Maps"-style 
well-known URL. With that in mind, it appears fairly obvious that 
LoST can be used, with a well known URN (denoting the service 
desired) to ask a LoST server for this information (when geocoding is 
involved), or be pointed to an appropriate URI that can do this 
transformation.

This ID offers both options, with the LoST server deciding whether or 
not it will fulfill the transformation (when location transformation 
is the URN). If the LoST server wishes to return the transformed 
location, a single transaction is all that's needed by the client - 
increasing the user experience. If the LoST server can't or does not 
want to return the transformed location information, it returns the 
URI for that (URN) service, as is the case with most (all?) other 
LoST transactions.

Comments and questions are appreciated

James

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Mar 2010 15:29:32 -0500

Personally, I don't see the URN as having any real value.

I think all we need is a simple web service: send in a PIDF, get one back.
If you send a geo, you get a civic and vice versa.  If you insist, have two
services: geocode and reverse-geocode.

Why would we want to be more complicated then that?  Specifically, why would
we want to invent a URN to tell us what transformation we want?

Brian

On 3/15/10 2:08 PM, "James Polk" <[email-masked]> wrote:

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

---

From: "Avery Penniston" <[email-masked]>
Date: Mon, 15 Mar 2010 16:49:34 -0500

When you ask the LoST server to transform a civic into a geo or vice
versa, it seems that you are trying to make a LoST server into a
geocoding/reverse-geocoding server - I'm not sure how much I like that
idea, or how much advantage you get by using a LoST server to obtain the
URI of such a service.

I tend to agree with Brian, that it is better to separate concerns by
creating a distinct web service for geocoding/reverse-geocoding.  

Also, I believe your definitions of 'geocoding' and 'reverse geocoding'
are opposite what they should be - 'geocoding' is converting civic to
geodetic, and 'reverse geocoding' is converting geodetic to civic.

Avery

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Monday, March 15, 2010 2:09 PM
> To: 'ECRIT'
> Subject: [Ecrit] Revved the Transformations URN ID
> 
> ECRIT
> 
> re:

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Mar 2010 00:21:59 +0100

Brian,

I thought you were the one that mentioned the idea of additional  
transformations in ... Stockholm?

IMO, there's some merit in this draft, in that you could imagine  
geocoding services advertising their coverage areas in LoST.  (I have  
no idea whether anyone actually wants to do this, e.g., in the NG9-1-1  
context.)

This draft is significantly improved over the previous version in that  
it uses LoST in the more appropriate role -- discovery of geocoding  
services rather than the geocoding services themselves.  Going  
forward, I would suggest that this draft merge with draft-george- 
geopriv-address-translation to form a solution in two steps:
1. Use LoST to discover a geocoding server (if necessary)
2. Use HELD to query for geocoded result

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 15 Mar 2010 23:36:58 -0500

Richard

Thanks for reviewing the doc.

To affirm, it was Brian that strongly suggested that I expand this 
URN from "geocoding" to "transformations", with geocoding and 
reverse-geocoding as sub-services.

Of your 2 steps, this ID specifies doing #1, if the LoST server 
doesn't want or cannot do the geocoding itself. I leave that as an 
option - which is based on Andy Newton's offering in Stockholm that 
the LoST server _could_ have both location formats for a particular 
location, and satisfy the goal in a single transaction.

About step #2 below, I do talk about this in the current use of LoST 
(to learn the URI of the service at or near the given PIDF-LO 
location) - but I do not specify the use of HELD at this time, and 
leave it generically to "another transaction", inferring HTTP. HELD 
could very well be that second transaction's protocol. I was waiting 
for feedback before going down that path.

I'm not opposed to merging this ID with the 
draft-george-geopriv-address-translation ID.  You, as chair of both 
WGs (once we get to Anaheim), should likely provide the guidance as 
to which WG this merged ID goes into.

James

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Mar 2010 07:44:22 +0100

Yeah, I thought about suggesting that this go to GEOPRIV, but I don't  
think it matters much one way or another.
--Richard

On Mar 16, 2010, at 5:36 AM, James M. Polk wrote:

> I'm not opposed to merging this ID with the draft-george-geopriv- 
> address-translation ID.  You, as chair of both WGs (once we get to  
> Anaheim), should likely provide the guidance as to which WG this  
> merged ID goes into.
>
> James
>

---

From: Robins George <[email-masked]>
Date: Tue, 16 Mar 2010 15:30:34 +0800

> WGs (once we get to Anaheim), should likely provide the guidance as to 
> which WG this merged ID goes into.
>

I'm happy to merge  this draft with the 
draft-george-geopriv-address-translation.

- robins