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".
--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
