New CAtypes have a myriad of uses. This document classifies usage into two classes:
Type A: CAtypes that are more widely used to encode civic addresses, and most clients should be able to use the extension
Type B: CAtypes that are special purpose, and both the client and server have to be constructed specifically for the use case the extension was designed for, and consequently relatively few clients will be able to use the extension CAtype
The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A CAtypes.
The CAtypes registry is modified by this document to contain an indication of which type of extension CAtype the entry is. All clients implementing PIDF-LO SHOULD implement all Type A extension CAtypes, recognizing that a newly defined Type A extension CAtype marked may not be implemented by a client until that client is updated and some clients may be constructed for special purposes where it is known that a Type A CAtype will not be encountered.
In this section, replace the text noted with:
The CAtypes registry is altered to so that it's management policy [RFC5226] for Type A registrations (see Section [?]) is "Standards Action". If a Type A registration is made, the specification column in the registry will contain a reference to an RFC.
Type B registrations require "Expert Review". A specification is optional. If it is provided, it must meet the rules for "Specification Required".
Registrations requests to IANA for this registry must specify whether a Type A or Type B registration is desired. All entries presently in the registry are Type A.
On Mar 7, 2011, at 5:43 PM, Ted Hardie wrote:
> Hi Brian,
>
> 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
