Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-l o -profile-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 20:31:11 -0500

At 11:17 AM 7/15/2005 +1000, James Winterbottom wrote:

>I think that the problem is more complex than this.
>
>The Geo with floor does provide a relatively precise location. Certainly 
>it can be precise enough to enable routing decisions to be made. Civic, as 
>is defined in the PIDF-LO document I am afraid does not. All elements are 
>defined as 0-1 occurrences, which means that an operator can pick and 
>choose what ever elements they want to include. We need to provide 
>recommendations on a minimum set of civic elements that are required to be 
>entered I think.

I wholeheatedly agree with this assessment

>Anyway, given this limitation I am going to propose the following:

I want to ponder this below

>
>
>1) If you request AT THE SAME TIME, Geo and Civic, and you get both, you:
>         a) Create a Single tuple, status, GeoPriv and Location-info element.
>       b) You fill in everything you can with the Geo information first, 
> so Geo will be the first entry in the location-info element. If floor was 
> provided then you create a civic element and fill in the floor.
>
>       c) You take everything except for floor from the returned civic 
> information and populate that into the same civic element that was 
> created to put the floor info into.
>
>RATIONALE:- Civic data returned may not be sufficient to provide routing 
>information, but may be extremely useful to people that need to look at 
>the location.
>
>2) If you request different location types at different times then the 
>locations must be populated into different tuples.
>
>
>
>-----Original Message-----
>From: Henning Schulzrinne 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Friday, 15 July 2005 10:47 AM
>To: James M. Polk
>Cc: Winterbottom, James [WOLL:5500:EXCH]; Marc Linsner; 'GEOPRIV'
>Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo 
>-profile-00
>
>Since I'm not sure I understand the question and since partial answers
>may confuse more than help, let me try to explain what I see as the
>process and issues systematically.
>
>The DHCP client wants to get location information and then PUBLISH this
>information via PIDF-LO.
>
>I assume that the DHCP client has no out-of-band knowledge what location
>information, if any, is available locally.
>
>Let's assume that the DHCP client hasn't participated in the 35 geo vs.
>civic discussions on this list and just wants to get all the location
>information it can lay its virtual hands on. I know it's bad form these
>days to be an agnostic, but maybe we can tolerate it in protocols.
>
>The most expedient way is to request both civic and geo options in one
>DHCP request, requesting them by their respective DHCP option numbers.
>
>Let's assume both are available and are returned. (If just one, there's
>no problem except that you'll possibly generate an incomplete civic record.)
>
>The question at hand is what the PIDF should look like, with its 1, 2 or
>3 location objects. (One: combined civic+geo, Two: one each, Three: one
>civic from the geo object, plus the full civic plus the geo object). It
>sure would be nice if we can give an answer which is something other
>than "maybe 1, maybe 2, maybe 3, depending on the weather".
>
>Henning

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "James Winterbottom" <[email-masked]>
Date: Fri, 15 Jul 2005 11:37:27 +1000

Clearly, we indicate an acceptable level of precision required for routing
if Geo is used
I did specify this in the revision of the document that I sent to you and
James a week or so back which included how to create a PIDF-LO from Geo
specified in RFC-3825 (it will be in the 01 version as an appendix). The
same goes for the civic elements that are necessary and we may just need to
agree what that subset is.

To clarify a comment from James's recent email, floor is currently defined
as a string in the PIDF-LO draft, so 2.2 etc is okay.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 15 July 2005 11:27 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: James M. Polk; Marc Linsner; 'GEOPRIV'
Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-l o
-profile-00

James Winterbottom wrote:
> it can be precise enough to enable routing decisions to be made. Civic, 
> as is defined in the PIDF-LO document I am afraid does not. All elements 
> are defined as 0-1 occurrences, which means that an operator can pick 
> and choose what ever elements they want to include. We need to provide 

That's true in some sense, but doesn't much matter. Just like we have to 
assume that an operator includes a valid geo address, we have to assume 
that the civic address is a complete and preferably validated address, 
at least to the street level.

(Obviously, in either geo or civic case, things like building names or 
floor numbers may not be included.)

The notion that geo is always sufficient for routing is mistaken. If 
your geo resolution is such that it includes the whole North American 
continent, it is not particularly useful for routing. This is exactly 
the same problem as if somebody were to only include the country and 
state, say.

Henning