There are basically two approaches to handling new record types in any 'DNS language' definition:
1. Have a good extension mechanism built in; or 2. Issue an updated language specification each time a new record is agreed. Personally I think 2 is a big step backwards and 1 is much easier if the language is built on an underlying technology that supports it. One of the reasons we chose XML Schema for draft-daley-dnsxml is that XML-Schema has polymorphism built into it. Using the little known 'substitutionGroup' feature the spec has a built-in extension mechanism allows a new record type to have it's XML representation defined in a new document and work basically as though it were defined in the base specification (it sits in a different namespace). Jay On 12/11/2014, at 9:46 am, Stephane Bortzmeyer <[email protected]> wrote: > Does anyone know how Spartacus > (draft-dickson-dnsop-spartacus-{lang,system}, on the agenda for today) > handles new record types that may be invented tomorrow? I find nothing > in the drafts, which describe the JSON structure for today's record > types, but not for future types. > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
