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

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

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