Tuesday, September 7, 2010

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

While I am in favor of the basic idea this puts forth, I am opposed to the mechanisms described in this draft.

Let's take an example - Robins George and my "lamp-post" draft. This would mean we wouldn't proceed with that draft, and NENA would just create a namespace with milepost in it.

There is no review and no registry for these namespaces - anyone can make one, and create a PIDF that conforms to it and recipients would be up the creek without the paddle if they didn't know this variant = no interoperability.

If Canada makes a namespace, and calls it mile-post when the U.S. one calls it milepost, tough, it's different (different name spaces). This is not INT where I explicitly proposed to follow local signage and plans; it's the basic civic location.

The DHCP option stuff is truly ugly. With a registry of namespaces, and some reasonable rules, we could get the triplet (namespace, element name, and value) into a single CAtype.

Instead, I would propose that we have registries for the namespaces with at least expert review, and elements within the namespace, and a more compact DHCP option.

Brian

On Sep 5, 2010, at 8:41 PM, Winterbottom, James wrote:

> Hi All,
>
> There have been a number of discussions on this list, and a number of drafts that attempt to introduce new civic address types. The problem is that all of these drafts, as written, would require an update of the schema defined in RFC5139, and would likely require a new namespace. This issue with this is that it breaks backward compatibility for other specifications, such as LoST. It also has impact on equipment vendors that have implement the 5139 schema, and national organizations that have profiled their civic addresses to fit within the 5139 schema.
>
> This draft describes a way that allows easy tension of the civic schema, without breaking backwards compatibility, and allows local authorities to define their own local address elements in such a way that they can have local significance without being open to misinterpretation by general applications.
>
> Cheers
> James
>
>
> A new version of I-D, draft-winterbottom-geopriv-local-civic-00.txt has been successfully submitted by James Winterbottom and posted to the IETF repository.
>
> Filename: draft-winterbottom-geopriv-local-civic
> Revision: 00
> Title: Specifying Local Civic Address Fields in PIDF-LO
> Creation_date: 2010-09-06
> WG ID: Independent Submission
> Number_of_pages: 7
>
> Abstract:
> This document describes how to specify local civic elements in the Geopriv civic schema maintaining backward compatibility with existing specifications and implementations. Support for providing local civic elements over DHCP is also described.
>
>
>
> <image002.jpg>
> James Winterbottom
> Global Product Manager
> Andrew GeoLENs
> IP Location Product Portfolio
> Email: james.winterbottom@andrew.com
> Phone: +61-2-42-212938
> Mobile: +61-447-773-560
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv