The registry exists when folks want to come and get some interoperability.
This draft shouldn't need to exist. Mileposts (or mile-posts) are a foreign concept to most of the world [1], so a US authority is free to define them. If they want to register a CAtype, there is nothing preventing this, and there is no need for an IETF publication.
If they want to define their own private extension instead, well, this was intended to enable that.
--Martin
p.s. I observe that the same arguments apply equally well to INT. It's just that our positions are reversed. The only significant difference is that there are (probably) pre-arranged semantics associated with these sorts of extensions, whereas INT is proudly semantic-free.
[1] http://www.allvoices.com/contributed-news/1098610-google-street/image/16214621
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 8 September 2010 11:58 PM
> To: Thomson, Martin
> Cc: James M. Polk; Winterbottom, James; geopriv@ietf.org
> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-
> geopriv-local-civic-00
>
> We have some awareness that if there is to be precision, addressing is
> a national matter. Having one reference work per country is probably
> needed; indeed we agree that there needs to be one. We have experience
> with working on something that is formal and one per country (public
> ENUM), and the experience is bad. We need some informal way to have
> about one per country. The easy way is registry with expert review.
> NENA is a reasonable source of US addressing information, although
> URISA would be better, but if the expert looks into it even a little,
> NENA is appropriate. Joe Blow is not.
>
> Having more than one per country, except when you have dueling experts,
> which is possible (disputed territories or internecine rivals) is bad.
>
> My nightmare is being given the assignment to write a website form that
> accepts an address from anywhere in the world and create a PIDF that
> would be accepted anywhere in the world. Having to manage one
> namespace per country is bad enough. Possibly hundreds, or thousands,
> because there is no registry is mind-boggling. It's actually
> impossible - without a registry, you don't even know what namepaces are
> available.
>
> Our protocols don't have mechanisms that would allow the receiver to
> tell the sender what namespaces it understands. That makes this whole
> thing more than a little difficult to get interoperability, and indeed
> may doom the whole effort, but I personally think there is value in it,
> with registries.
>
> Within namespaces, we really do want the same kind of element to have
> the same element name. It's more than just cleanliness - it
> simplifies code if a milepost is a milepost, and not a mile-post. It's
> also easy.
>
>
>
>
> On Sep 7, 2010, at 7:25 PM, Thomson, Martin wrote:
>
> > This is doing nothing more than formalizing the extensibility scheme
> that is already provided for XML in such a way that it can be
> translated into RFC 4776. And this goes right to the heart of the
> extensibility philosophy of the work we do here.
> >
> > <rant>
> > I find the idea that the IETF should maintain a monopoly on the
> definition of civic addresses offensive. The same goes for much of the
> work we do. It's an insult to the community that uses our stuff.
> Familiar as I am with the well-worn stories about the standard that was
> poisoned by proprietary extension, I simply don't buy into that ethos.
> >
> > We build protocols with extension in mind not only for the benefit of
> the IETF, but also to allow others to benefit.
> >
> > The cost is in occasional duplications of effort and interoperability
> problems. By the same measure that these sorts of genuine problems
> arise from the provided extension capability, they are also mitigated.
> If this capability was not provided, I propose that our standard would
> not be used at all, or it would be used in some altered state that
> would entirely prevent interoperability of the most basic functions.
> This doesn't prevent real problems from occurring, but we were never
> going to stop them in any case.
> >
> > Of course, I recognise and appreciate that others will have a
> different opinion. There are good reasons for tighter control in some
> cases. But not for civic addresses.
> > </rant>
> >
> > --Martin
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of James M. Polk
> >> Sent: Wednesday, 8 September 2010 8:14 AM
> >> To: Winterbottom, James; Brian Rosen
> >> Cc: geopriv@ietf.org
> >> Subject: Re: [Geopriv] New Version Notification for draft-
> winterbottom-
> >> geopriv-local-civic-00
> > ...
> >> see, this to me is a real problem - as I see "no one has to come to
> >> the IETF to define new things" as creating something RIPE for
> >> collisions, i.e., incompatible elements or descriptions that mean
> one
> >> thing to one (group) and an entirely different thing to the other
> >> (group).
> >>
> >> This, to me, breeds incompatibility - only to get worse over time.
> >>
> >> IANA is there to prevent this - and what you're suggesting is to
> >> circumvent that registration (with associated document defining the
> >> means/usage of such a/each new element.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
