When I looked at this in 2012 I concluded that the best approach would be
to keep the generic language REALLY simple, and that RDATA with special
needs would have to have a custom-coded parser/serializer.
I'm close to that. If a field is odd but it's a minor variant of
something else, such as the hex fields with optional hyphens or dots, it's
easy enough to include. Or if it seems like it might be useful in the
future, like a trailing list of domain names which could show up in
something like CLONE, might as well.
Beyond that, I don't think anyone will ever reuse the odd arithmetic in
LOC or the data-dependent formats in IPSECKEY, so if I do anything for
them, it'll be something like Z[LOC] or Z[IPSECKEY] meaning do the
appropriate special hackery for that record type.
Not sure what to do with the type bit maps in NSEC. They're reused in
NSEC3, and both records are certainly in active use.
see if I run into unexpected problems. It took about 15 minutes to realize
that it needs to let you name the fields as well as describe them, if you want
to refer to the fields from other code.
Yes! And field names are really crucial if you want to be able to
auto-generate user interfaces from the abstract syntax, because you can
use the field names as a key for localization and for help text.
That's the main change in -08.
R's,
John
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
