Re: [Geopriv] Other civic-related stuff

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Sun Dec 05 2010 - 23:58:03 EST

(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
Received on Mon, 6 Dec 2010 12:58:03 +0800

This archive was generated by hypermail 2.1.8 : Sun Dec 05 2010 - 23:58:29 EST