Evaluate usefulness of `zone_field_info_t`
k0ekk0ek opened this issue · comments
simdzone exposes "type" (not RRTYPE) information for each RDATA field. Originally, this was modeled after the implementation in NSD (wire format/zone format tables) and studying draft-levine-dnsextlang-12. There were two reasons for having that information available.
- The parser can call the functions when iterating fields.
- The application can discover the type of field.
Since the first implementation, the parser simply uses a table of callback functions for each RRTYPE. The RRTYPE function simply invokes the correct data type parse functions in order. While no zone_printer has been implemented yet, it stands to reason it will operate in the same way. Therefore, the information in zone_field_info_t is redundant wrt the implementation itself.
As for exposing the information to the application, the more I think about it, the less sense it makes. The output format is simply the standardized DNS wire format, which the application must be able to interpret if it wants to consume it. I highly doubt any application will iterate RDATA fields based on the table.
Having talked this through with some people, zone_type_info_t and zone_field_info_t will not be exposed in the public API.