Re: [DNSOP] Self-describing RTYPE in the DNS, draft-levine-dnsextlang (was DNS-in-JSON draft)

["John R Levine" <[e-mail]>]

> 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