>James,
>
>I believe Martin's point is this: RFC 4119, 4776, and 5139 don't place
>any restriction on what can be done with the "##other" extension point
>in the schema. So it is perfectly legal for any entity to put any XML
>entity in a civic address that it wants, as long as it's not from the
>namespace "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr".
Thanks for clarifying that point. I agree with what you say, but
that's not how I read Martin's note about how offensive it is to him.
Brian and I (at least) are stating that registries prevent collisions
and increase interoperability by understanding what a given element
means. If some random other SDO or group of guys in a garage decide
to define a <cl:HMO> element that isn't in line with RFC 4119, 4776,
5139 *and* IANA -- they are increasing the likelihood of miscommunications.
Similarly if some random other SDO or group of guys in a garage
decide to define it's a race condition to see who can define which
new element -- believing that first come, first to defacto ownership
of the name of the element.
James
>--Richard
>
>
>
>On Sep 8, 2010, at 3:32 PM, James M. Polk wrote:
>
>>At 06:25 PM 9/7/2010, 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.
>>
>><my rant>
>>this rant is probably the least intelligent thing I've ever heard/
>>read you say.
>></my rant>
>>
>>Now the facts:
>>The IETF created and "OWNS" the civic datum. They have every right
>>to claim to be the ultimate source for its definitions, extensions
>>and registrations - that is, until they collectively choose to give
>>that right up (which they haven't).
>>
>>you don't like it? Get the IETF to give up its rights to the datum
>>-- but until then, deal with it!
>>
>>James
>>
>>
>>><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
>>
>>_______________________________________________
>>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
