> > A new proposal:
> >
> > 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.
I can be persuaded to include two levels of review, but I am only really describing the current management requirements. That is, the current requirements are equivalent to the weaker level you advocate.
Current requirements are 'Expert Review' and 'Specification Required'. Specification Required is a subset of Expert Review [RFC5226], so that's just redundant. Without guidance (and there is none) Expert Review amounts to a check that the a specification exists.
> 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.
Anything we do to specify a template or any other procedure only makes the process MORE difficult. That's probably not a bad thing because they also make it easier by making it clearer what the expectations are.
> 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.
That's right. The QName works by default. LoST validation and service boundaries only have to deal with one representation.
--Martin
> Brian
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
