Re: [Geopriv] Other civic-related stuff

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Wed Dec 08 2010 - 09:09:18 EST

We may be heading for compromise, so this may be moot but:

The point of interoperability is that if YOU create a LIS and I create an app that uses location, it would be real nice if my app uses your location.

If I define some extension that you don't know about, I may reject your location.

The more we create these situations, the less the whole system will work.

99% of apps should be able to use the per country location that is discussed in 5774. It is HIGHLY desirable that the total number of elements needed to cover all of the countries that (eventually) get listed in the registry that 5774 creates be as small as possible, and that elements are re-used as much as possible. If I want my app to work world wide, I have to deal with each of those elements, and the fewer, the better.

I'll accept that there will be apps that need things beyond that. However, the same considerations apply. The smaller the variation, the easier it is to create locations and apps that interoperate.

Uniqueness, which is the only property you seem to care about, is necessary, but far, far from sufficient.

I don't really care all that much about decoration. I'm an engineer and I like things to be efficient. If you want to carry around a zillion namespaces in a detailed location object, okay. I'd prefer just a unique name in a registry, but that isn't that important to me. What is important is to encourage re-use and advertisement of location elements so that apps can be built that work well in a wide variety of situations.

Brian
On Dec 7, 2010, at 7:12 PM, Winterbottom, James wrote:

>
> Brian,
>
> I have asked on numerous occasions for you to justify the "interoperability problems". I maintain that this is simply not true and have provided examples of why it is not true. The fact that the XML we are already using in protocols and in the PIDF itself all have multiple namespaces goes a long way towards bunking the interoperability argument. Quite simply, I don't want to discourage this, I think it is desirable flexibility to have. It has no impact on backwards compatibility, basic XML rules already allow for this. Local-civic explains this in quite a succinct way.
>
> I am opposed to using a registry as you suggest below. We already have clear guidelines on what is required to register a new CAtype, I don't think these should be relaxed. Further, I think that anybody looking to define new elements will think about their general applicability as part of the definition phase and will, if they are good citizens, submit a specification to have them accepted to the common set of CAtypes. Where elements have local applicability I am all for them staying local, and I think that we need a way to allow people to define these without imposing unnecessary IETF process on them. I simply don't buy the FUD on interoperability that is being pushed using arguments that misrepresent scoping using XML namespaces.
>
> The reality is that the namespace mechanism doesn't need to be "made" to work, because it already works and I don't see the prediction of doom and chaos around us now, or even blooming on the horizon. Local-civic simply makes DHCP compatible with what can be provided via HELD already. Personally I am okay with a disparity, but previous decisions made by this work group have wanted, as much as possible, to maintain a parity in functionality between these LCPs. So, it is my opinion that this horse has already to a large extent bolted in that we already have one LCP capable of supporting 5139 civic extensions through namespace extension, the greater question is do we leave DHCP behind?
>
> Your assertion that registries just work seems to be somewhat at odds with the email that Richard forwarded from Julian Reschke on the 14th of November.
> "Many people take it as a given that once you have an extension point, you need a new registry. Not so." He then goes on to cite exactly what they did in WebDav which has very close parallels to what we are discussing here. The reality, quite to the converse to your assertion, is that local namespaces work really well when defining local content!
>
> I assert that the proposed registry is an imposition on organizations that want to define their own extensions. It is an administrative overhead for the IETF. And, it undermines the due process required when defining new CAtypes by providing a relaxed means of registering globally visible civic address elements without requiring the scrutiny for general applicability provided through the writing and approval of a formal specification. This really will lead to the anarchy and chaos predicted below.
>
> Cheers
> James
>
>
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
>> Of Brian Rosen
>> Sent: Wednesday, 8 December 2010 9:25 AM
>> To: Thomson, Martin
>> Cc: geopriv@ietf.org
>> Subject: Re: [Geopriv] Other civic-related stuff
>>
>> There is currently two mechanisms. This adds 1/2 of one. Semantics, to
>> be sure, but the point is that the only difference between two of them is
>> the registry they go in and the actual element name/DHCP option.
>>
>> We can't avoid the new namespace thing, but it has so many
>> interoperability problems, all we can do is discourage it. Backwards
>> compatibility is going to be an issue. Yet another reason not to use it.
>> Your proposal has the same problem.
>>
>> A problem occurs when you start with the local registry, and subsequently
>> decide it deserves to be more general purpose. It occurred to me to use
>> the same name/number in both, and ask implementations to treat one as the
>> other if they encounter it. Anyone that really wanted to could actually
>> check the IANA registry. All of the implementations we're concerned about
>> are on-line anyway.
>>
>> The namespace mechanism can be made to "work", but it encourages anarchy.
>> No interoperability, no common use. You have to just "know" that some
>> namespace is out there or roll your own. The registry is the
>> advertisement for what others have done. Namespaces are squeaks in the
>> wind. You could have a million of them and have no way whatsoever to
>> build a general purpose LIS, or LoST server, or anything else.
>>
>> I don't want to get rid of namespaces. Don't think we really could even
>> if we were even more against them than I am. However, they are a bad
>> idea for all but a very, very constrained environment. Registries work.
>> Once you have the registry, then you look for the simplest way to
>> implement the functionality. That's what I proposed (one extension
>> namespace, three DHCP options, and you are done for all new extensions).
>> If you really want to, you could have only two DHCP options if you have
>> non-intersecting numbers in the two registries.
>>
>> Brian
>>
>>
>> On Dec 5, 2010, at 11:58 PM, Thomson, Martin wrote:
>>
>>> (Apologies for taking my time responding here.)
>>>
>>> That's three parallel extension mechanisms.
>>>
>>> You get to choose from three wonderful options. I'll admit that each is
>> effectively partitioned from the other, so there is no need for multiple
>> encodings for each.
>>>
>>> You'd better pick the right option from the outset. What happens when
>> you pick option 3 and it turns out that Option 2 or Option 1 was a better
>> choice (maybe it was a good enough idea to standardize)?
>>>
>>> After all, if it didn't matter, why would there even be three options?
>>>
>>>
>>> The other big problem I have with this discussion is the subtext. That
>> subtext is that the existing extension mechanism doesn't work and /can't
>> be made to work/. You would have us throw it all in for a replacement
>> scheme. The numbers don't have enough code points; the namespaces are too
>> ugly. To-mah-toes, to-may-toes.
>>>
>>> -local-civic acknowledges that it doesn't work due to the interaction
>> between the different formats, but proposes an approach that is far less
>> disruptive.
>>>
>>> Changing backwards compatibility schemes has its own backward
>> compatibility problems, after all.
>>>
>>> I had a small concern about there being multiple forms, but now that
>> I've had time to mull it over, it's not going to cause significant damage.
>> We can handle it. The way we agreed works. For the types of things we're
>> being asked to add, we can handle it 100 times over.
>>>
>>>
>>> --Martin
>>>
>>> On 2010-12-03 at 09:32:40, Brian Rosen wrote:
>>>> I'll write an I-D if I need to.
>>>>
>>>> The essence is:
>>>> 1) A CAtype that is generally useful is defined and entered into the
>>>> existing registry as currently documented. To use it, the XML is:
>>>> <ext:EXT CAtype="STP">Avenue</ext:EXT>
>>>>
>>>> The DHCP is
>>>> <extCAoption><STP><Avenue>
>>>>
>>>> The LoST validation is:
>>>> ext:STP
>>>>
>>>> The LoST Service Boundary can contain <ext:EXT
>>>> CAtype=STP>Avenue</ext:EXT>
>>>>
>>>> 2) A CAtype that is not generally useful can be entered into a new
>>>> registry with expert review that simply avoids duplication. This
>>>> registry can't contain element names that conflict with those in the
>>>> existing registry (and vice versa). To use it, the XML is
>>>> <ext:localEXT CAtype="Foo">Baz</ext:localEXT>
>>>>
>>>> The DHCP is
>>>> <extlocalCAoption><Foo><Baz>
>>>>
>>>> The LoST validation is:
>>>> ext:Baz
>>>>
>>>> The LoST Service Boundary can contain <ext:localEXT
>>>> CAtype="Foo">Baz</ext:EXT>
>>>>
>>>> 3) It's possible, as it is now, to create a new namespace and elements
>>>> within it. To do so requires no registry entry. The XML is
>>>> <my:Food>Tomato</my:Food>
>>>>
>>>> The DHCP is
>>>> <extNameSpaceOption><http://foodsoftheworld.net/ns/food><Food><Tomato>
>>>>
>>>> The LoST validation is:
>>>> my:Food
>>>>
>>>> The LoST Service Boundary can contain <my:Food>Tomato</my:food>
>>>>
>>
>> _______________________________________________
>> 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
Received on Wed, 8 Dec 2010 09:09:18 -0500

This archive was generated by hypermail 2.1.8 : Wed Dec 08 2010 - 09:09:46 EST