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

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:hgs@cs.columbia.edu] 
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