Comments in line.
________________________________________
From: Brian Rosen [br@brianrosen.net]
Sent: Tuesday, September 07, 2010 8:41 AM
To: Winterbottom, James
Cc: geopriv@ietf.org
Subject: 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.
[AJW] Excellent. This is a good place to start from.
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.
[AJW] Absolutely right, only applications that need to understand "lamp-post" would do so. Better still, organization don't need to come the IETF everytime they want to define a new element specific to their application. This is a win for everyone.
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.
[AJW] Herein lies a great misconception. First of all this can and is done today already, XML allows this, and to a large extent encourages it. That is the XML examples in the document are perfectly legal civic examples today, and any device processing the civic schema needs to be able to handle this today. Absolutely nothing new, the current behaviour is to ignore the additional elements it doesn't understand. Requiring the registrations of namespaces into the IETF by external organizations so that they can extend an XML schema that has been defined with extensions points is cumbersome, unnecessary and I would argue ultimately unmanageable.
No interaoperability is patently not true. The local extension schemas have clearly defined scope. This is defined by the namespace, and is applicable to the local application in mind. Fields cannot be misinterpreted by something outside of the context within which the element was specified. This is good design. You are talking variants, and I am talking contexts, and there is a world of difference, and the namespace provides this very clear clarification.
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.
[AJW] You are right. The Canadian mile-post has significance in Canada only. But here is where I think you are misunderstanding something. The different namespace means that it is a completely different thing, their mile-post might represents the number of standard-begets from the Eiffel-tower. It isn't just a US mile-post in a different namespace. It is very difficult to misinterpret anything when it is defined in this fashion.
My very significant issues with INT, is that it is exactly the opposite! It is totally open to misinterpretation and arbitrary assignment. It has no definition of context, even within the domain that assigns it. So if it forms a basic part of the must implement everywhere there is no way to enforce usage or understanding leading to complete chaos.
Further to this, you cannot define INT in the fashion that your current draft does, without up versioning the civic schema. This requires a NEW representation of the civic schema. The impact of this is very large. People have implemented and are starting to deploy product that represents civic addresses using the schema defined in RFC5139. Further to this there are several national profiles of the 5139 schema that people have invested a lot of time producing. Up versioning the schema will require pretty much all implementations to require support for both. This is a very BAD idea.
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.
[AJW] Yes, you could. This would however have significant impacts on how long your namespace is allowed to be, and how long the value can be. The method as defined means that the namespace only need to be sent once, and a number of local elements defined within that namespace can be sent following it. The method defined also eliminates the need to have artificial separators between the namespace, element and value. But if the group things that slamming these together into a single value is a good idea, it probably isn;t a show-stopped on my part.
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.
[AJW] Requiring organizations to register their namespaces with the IETF is a very bad idea and for the reasons stated earlier is totally unnecessary.
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
