If you want to re-open the discussion, then I guess that's fair game. I'm against it.
--Martin
On 2011-03-09 at 02:08:43, Brian Rosen wrote:
> Somewhere before this section:
>
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
