What you propose is a false optimization because you have to know that the registry contains a particular NS_ID (and what it is) to be able to take it from the DHCP form and get an XML form. That's the essential problem with extensions - you have to assume that someone, sometime is going to get one that they don't know about.
If you have two representations for the same thing (in this case, namespace URI and the NS_ID), then you are back to having two representations.
Now, I've satisfied myself that the impact of that is small, but what you propose has the same weaknesses as -local-civic and it adds a new extension mechanism in the process. It does save a few bytes in the process, but you can save more by registering a CAtype.
--Martin
On 2010-12-08 at 11:58:53, Richard L. Barnes wrote:
> > 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.
>
> Overall, this proposal was sounding pretty good to me. But I don't see
> why ending CAtype numbers is necessary or a good idea. There doesn't
> seem to be any harm in keeping the numerical designations in the
> standard-required registry (while adding a "namespace" column) and
> allowing new standard options to use them. Given the efficiency gain,
> it could serve as an incentive to get a standard CAtype!
>
> Note that you could also assign numbers to the FCFS extension schema
> registry as well, and get a little bit of efficiency. That way, for
> (2) you could have the generic extension binary type be:
> {
> uint8_t EXT_CA_TYPE
> uint16_t NS_ID
> octet_string localName
> octet_string value
> }
> As a bonus, it would encourage people to register their schemas!
>
> --Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
