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

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

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.

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

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]] 
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
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 21:27:29 -0400

James Winterbottom wrote:
> 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 

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Jul 2005 22:38:26 -0400

This is probably naive, but what the heck...

On Jul 14, 2005, at 9:17 PM, James Winterbottom wrote:

> 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.
>
>       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.
Wouldn't these lead to loss of information (the floor from the civic)?

This sounds like we need a very short, new schema.  One that allows  
this:

     <rfc3825:data>
       <gml:location>
         ....
       </gml:location>
       <cl:civilAddress>
         <cl:FLR>
           ....
         </cl:FLR>
       </cl:civilAddress>
     </rfc3825:data>

In that way, all the information can be sent:
   <gp:location-info>
     <rfc3825:data>
       ....
     </rfc3825:data>
     <cl:civilAddress>
       ....
     </cl:civilAddress>
   </gp:location-info>

> 2) If you request different location types at different times then  
> the locations must be populated into different tuples.
But then the usage rules would be need to be repeated for every  
location.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 22:34:27 -0500

>This is probably naive, but what the heck...

seems like something like this is what we're driving at for 
interoperability, unless we mandate everything has to be parsed in any 
order and always have the same result...

>But then the usage rules would be need to be repeated for every

cheers,
James

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