There is still a part I think that you are misunderstanding from both Martin and I are saying, and what the draft tries to state, though not clearly enough.
I would go as far as to propose that we do not define any further IETF civic address types that extend the existing civic schema. Any further extensions would be local and go into the namespace of the organization that required the extensions. In your example below cl:HMO cannot possibly have a clash using this scheme, the garage boys would define their HMO element in their namespace, and it could be a complex element if they want, and it ONLY has significance in their context. If the civic object already has the following line xlms:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" then they can't even get the namespace prefix cl to prefix their elements with. Absolutely no possibility of a clash, because namespaces define scope, and I think that this is a point that is not perhaps being articulated by us very well.
Hopefully this clears things up a bit.
Cheers
James
________________________________________
From: James M. Polk [jmpolk@cisco.com]
Sent: Wednesday, September 08, 2010 4:13 PM
To: Richard L. Barnes; James M. Polk
Cc: Thomson, Martin; Winterbottom, James; Brian Rosen; geopriv@ietf.org
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
At 03:06 PM 9/8/2010, Richard L. Barnes wrote:
>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
