Tuesday, September 7, 2010

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

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