I thought that we had got agreement on a single registry and what was required for this. I see no benefit in a secondary registry.
Cheers
James
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Thomson, Martin
> Sent: Wednesday, 9 March 2011 8:51 AM
> To: Brian Rosen; Ted Hardie
> Cc: geopriv@ietf.org WG
> Subject: Re: [Geopriv] local-civic registry management policy
>
> This proposal fundamentally changes the mechanism in the draft.
>
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
