Subject: [DNSOP] Comparison of XML/JSON DNS drafts

From: Jay Daley <[email-masked]>
Date: Wed, 31 Jul 2013 21:30:02 +1200

For this I looked at three drafts:

	draft-manderson-rdns-xml-01
	draft-bortzmeyer-dns-json
	draft-daley-dnsxml

The comparison looked a the following criteria:

0.  XML or JSON
1.  Coverage of RR types
2.  What is covered - specifically is it just RRs or also any parts of the DNS protocol or other.
3.  Are RDATA fields and the contents of the RDATA fields described.
4.  Use of consistent data types for RDATA and support for semantic equivalence.
5.  The level of validation available. 
6.  Extensibility.

draft-manderson-rdns-xml-01 :

0.  XML
1.  Only covers one two RR types - DS and NS
2.  These two RRs are defined are part of a provisioning protocol separate from DNS.
3.  The RDATA is provided as a single text string that is parsed by the receiving applications and so can contain any fields with any content.
4.  No data types specified for RDATA and therefore no support for semantic equivalence.
5.  No validation of RDATA takes place though protocol itself is validated using RelaxNG.
6.  No specific support for extensibility.

draft-bortzmeyer-dns-json :

0. JSON
1.  Covers 16 RR types
2.  Defines both the RRs, the DNS message and zone files.
3.  Field names are defined but as this is unvalidated, fields could be omitted and additional fields added and it would be for the application to determine this.  Field contents are not defined.
4.  No data types specified for RDATA  and therefore no support for semantic equivalence.
5.  No validation.  
6.  No specific support for extensibility.

draft-daley-dnsxml :

0. XML
1.  Covers 47 RR types and the unknown type (Only NB and NBSTAT are not included)
2.  Only defines RRs.
3.  All fields are defined and all field contents are defined.
4.  Standard field contents defined wherever possible including standards tables of mnemonics, algorithms, time durations, unions of mutliple type, etc.  Full support for semantic equivalence.
5.  Full XML-Schema validation.  RDATA fields are validated so mandatory fields must be present, optional fields may be present and additional fields cannot be present for validation to succeed.  RDATA field contents validated to any possible wire format to allow for broken data that could be transmitted on the wire.  
6.  Specific support for extensibility so a new DNS type could be defined separately and work seamlessly.

So to summarise:

draft-manderson-rdns-xml-01 is a short and fixed provisioning protocol that includes a small bit of DNS.
draft-bortzmeyer-dns-json is the start of a process to create a standard representation but a long way to go.
draft-daley-dnsxml is the end of that process - a standard representation and fully validatable.

cheers
Jay

-- 
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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 31 Jul 2013 12:16:19 +0200

On Wed, Jul 31, 2013 at 09:30:02PM +1200,
 Jay Daley <[email-masked]> wrote 

> 	draft-bortzmeyer-dns-json

Presented in Orlando but unmaintained afterwards (sorry). I plan to
resume it at the autumn.

> draft-bortzmeyer-dns-json :

In Orlando, there was clear consensus that a better way to define the
RR (rather than by enumerating all the possible RRs) would be a good
thigng. New RR type appear from time to time. How would you handle
that? By publishing a new version of the RFC?

---

From: Jay Daley <[email-masked]>
Date: Wed, 31 Jul 2013 22:27:12 +1200

> that? By publishing a new version of the RFC?

No, by the mechanism described in section 3.4 (http://tools.ietf.org/html/draft-daley-dnsxml-00#page-18).  This shows how to create an extension that defines the XML for a new RR.  This could either be in a new RFC or the RFC that defines the RR could include the dnsxml for it if required.  

The extension feature uses the xml-schema feature of substitutionGroup that ensures that the new XML RR is exactly equivalent to an existing XML RR.  In other words this is different from EPP where extensions go into a different section.

A full example is provided in the draft.

cheers
Jay

> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop