In that particular example, perhaps, but others, maybe not. Think about the floor discussion we're having. Suppose you wanted something that had both that starts at zero always goes up or down by one, and you wanted the local signage version. You could have two CAtypes with the different versions, but having the two representations in one is better. That's basically the INT thing also. In the end, you can probably add enough CAtypes to make them all work, but then you really would have a big registry. Much cleaner to just allow parameters. If you don't need them, don't use them. I'm trying to think ahead.
> The reason I didn't think of it is that it's expensive. You have to close the CAtype registry for further business and create a new registry with two levels of registration.
No, we keep the existing registry. All of the details remain the same, no need to change it. IANA won't know the difference. Update 5139 to change how the encoding works. No redefinition of the 5139 namespace, just a change in how the registry entry encodes in PIDF.
We add a new one. It's like the existing one, but has a much easier management policy. Either FCFS, or a lightweight expert review where the only thing the reviewer is doing is preventing duplicate entries with slightly different names.
You could expand the existing registry to have two policies and add a field that was what kind it was, but I don't think anyone benefits from that.
> Incidentally, why not cut off extension for other namespaces too? You could use localExt with an unregistered name happily.
While I agree you could do that, I don't want to remove the existing namespace extension although I hope it's roughly never used except in a situation where there is only one app that uses it and therefore there is no interoperability issue. I don't want to have two ways to encode the same thing, and that adds more mechanism with no benefit.
The benefit of the registry is interoperability - there is a place to go to find out what extensions are available, what they mean, and how they are encoded. There is maximum re-use, and a modicum of review. That has benefits.
Using the registry to have global uniqueness is just convenient. I want the registry for the interoperability. With it, I don't need a explosion of namespaces that add no value. The number bits in the IANA registry aren't significant. The bits that define all the namespaces in the PIDF are annoying but not fatal. I'm pushing for interoperability, the other stuff comes with it for free.
> Good thing that LoST is the only possible use we have for a civic address.
I've avoided the problem you worried about by not allowing more than one way to encode. All other uses for location will have the same advantage. Be happy.
Brian
On Dec 1, 2010, at 8:11 PM, Thomson, Martin wrote:
>
> On 2010-12-02 at 11:45:35, Brian Rosen wrote:
>> Progress, and yet perhaps a bigger misunderstanding of positions.
>
> Ditto.
>
>>> I think that it's a terrible idea. But then, I don't know what a
>>> generic parameter is or what it gains me, so I could be convinced
>>> otherwise. What semantics did you want to attach to these parameters?
>>
>> The CAtypes that use the extensions are free to use them, and define
>> what they mean. If we decided, just for example, to use one new CAtype
>> for "post", then one parameter could say what kind of a post it was.
>> The purpose of defining them is obviously to have the syntax for them
>> in all of the appropriate XML (and DHCP)
>
> In otherwords: no semantics, just a limited space for sub-typing. If you need to split things further, split them further and use more CAtypes.
>
>
>>> If an extension only ever has a single representation, then there is
>>> no problem. However, imagine that you define a CAtype (192) and a
>>> corresponding XML element <pfx:STP>. A generic client that gets the
>>> CAtype translates that to an extension element in XML: <ext:EXT
>>> CAtype="192">; and a client that knows about the extension produces
>>> <pfx:STP>.
>>
>> Perhaps we have a bigger problem.
>>
>> I want to define two new CAtypes, put them in the registry, with one
>> new namespace. If the process defined to add new CAtypes is followed,
>> no new namespace is created. There is only an entry in the registry.
>> The encoding for that new CAtype is always <ext:EXT CAtype="STP"> (or
>> <ext:localEXT CAtype="foo">) and there is no pfx. The names (and
>> numbers) in the registries are unique.
>>
>> If you create a local extension, then there is a namespace, and there
>> is only one representation <pfx:STP> and there is no registry entry, no
>> CAtype name or number. One or the other, not both. If you add an
>> entry to the registry, you don't need a new namespace. EXT is the
>> namespace. If you don't add an entry to the registry, then you do need
>> a new namespace, and you don't have a CAtype name or number in the
>> registry.
>>
>> DHCP also only has one way - two DHCP options (ext and localExt), plus
>> one (or two) for local namespaces based extensions. Since there is
>> only one way, conversion between DHCP and XML is straightforward,
>> transparent and reversible.
>
> And now I think I've got a better handle on your proposal. What you are suggesting is the third option I didn't think of. A third, new, extension mechanism.
>
> The XML extension option exists, but rather than using CAtypes, you want to define a new mechanism for the "standardized" extensions.
>
> The reason I didn't think of it is that it's expensive. You have to close the CAtype registry for further business and create a new registry with two levels of registration.
>
> Incidentally, why not cut off extension for other namespaces too? You could use localExt with an unregistered name happily.
>
> Or go even further an just have a single ext element. Lump the local and standardized names in the same naming scope. The registry can prevent collisions for those who care to use the registry (and those who don't use the registry get all they pay for anyhow).
>
> A good reason is that namespace URIs are a handy, available, proven mechanism for ensuring global uniqueness with no management overhead. You might save a few bits by using IANA to maintain a separate global namespace, but who counts bits in this modern age?
>
>>> That's two different representations for the same logical element. [...]
>>
>> Well, even if this was a problem, all you need to do to solve it is
>> require that the LoST server use the same representation as the LI
>> passed up and then it isn't a problem. [...]
>> If the LIS did something really stupid and
>> switched representations mid stream, the client would have to requery.
>> So what?
>
> That's the conclusion that I was coming to. Multiple representations isn't a big problem for LoST. A little bit of tweaking on the server sets everything right.
>
> Good thing that LoST is the only possible use we have for a civic address.
>
>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
