> 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
