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
