Forgive the top posting, but I'd like to encourage you to go ahead and
post suggested language. It's hard for me to parse how what you
discuss below would fit into the document, and exact language would
improve that a good bit.
thanks,
Ted
On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net> wrote:
> In -local-civic, the text on registration currently states:
> The "CAtypes" registry is altered to operate on a registration policy
> of "Expert Review", and optionally "Specification Required"
> [RFC5226].
>
> The registration rules for "Specification Required" are followed only
> if a registration includes a reference to a specification.
> Registrations can be made without a specification reference.
>
>
> I think this came about because of my yammering about two different kinds of extensions:
> 1) Truly local extensions, where an app has to be created specifically around the use case and the extension. These are more special purpose applications
> 2) Generally applicable extensions that are used relatively widely, and for which most implementations should be able to use them
>
> We expect, for example, that any implementation of civic address would be able to handle ALL of the CAtypes in the current registry, and implementors of a location source can reasonably expect that a PIDF containing any or all of these elements would work.
>
> I posit that we haven't had enough countries writing their civic address encodings as recommended in 5774, and we will find some additional elements like Street Type Prefix, and Lamp Post, which are more commonly used.
>
> What I would like to see is two ways to add a new element to the registry: one which is basically FCFS, expert review to avoid duplicates, and the other is specification required, expert review for general applicability. We would the say that all implementations SHOULD be able to correctly handle any of the latter elements, just like they handle the elements now in 5139.
>
> The definition of the registry in the current draft of local-civic is okay, the working of Management Policy is what I want to change.
>
> I will propose exact wording for this section if this differentiation makes sense.
>
> Brian
>
> _______________________________________________
> 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
