>
> 1. Continue using namespaces to extend the XML.
>
> 2. Define a way to carry namespace + localName + value in CAtypes.
>
> 3. End use of CAtype numbers.
>
> 4. Create a registry for the namespaces. FCFS or Expert Review with a minimal template required only. Expert Review would only exist to look for duplicates and to make sure the template is filled out.
>
>
I'm always willing to compromise, and decoration is one of the easiest ways to compromise. All we need is uniqueness, and getting it by registered namespace+local name gets that. I think it's unnecessary, but it's okay.
The downside to me is that there really is a difference between a generally useful CAtype, with a document that has significant consensus/review, and a CAtype that is not duplicative, but has a more narrow use, and we're really only concerned about re-use. Retaining the present registry with its current management requirements seems important to me. If consensus is that having two levels of review is not important, I won't make a fuss.
As long as the template has a solid definition of the elements (such that it's possible for anyone else to re-use it the same way, and the expert can determine that a new one is different or not), It's okay. Think about the fact that the registry has to have the elements defined in it, not just the namespace, along with at least a minimal description, so the expert (and anyone else) can scan through to find out if something is there. IANA has to keep the templates, or they have to be stored in some archive somewhere that is permanent. That's simple enough. There wouldn't be any requirement that the element names be unique (because the namespace is unique), but good practice probably would suggest that it should be.
By the time you get to that, your registry and mine don't look very different.
I'm assuming that along with "Define a way to carry namespace + localName + value in CAtypes", there is an equivalent DHCP option. Qnames would continue to work for LoST validation and service boundaries.
Brian
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
