From 94e89223b521ef0a07993c99ccdc3598812c3e85 Mon Sep 17 00:00:00 2001 From: Aaron Kaplan Date: Thu, 27 Feb 2014 14:45:32 +0100 Subject: [PATCH] fixed ABNF, updated TODO.md --- TODO.md | 17 +++++++++-------- i-d/pdns-qof.xml | 14 +++++++++++--- 2 files changed, 20 insertions(+), 11 deletions(-) diff --git a/TODO.md b/TODO.md index f811f1f..470faab 100644 --- a/TODO.md +++ b/TODO.md @@ -2,17 +2,18 @@ TODO ===== - * get an updated address of Henry DONE - * formal grammar (ABNF) for the output format + * DONE get an updated address of Henry + * DONE formal grammar (ABNF) for the output format * create query API RFC - * move samples to a separate section - DONE (two samples added in appendix) - * cross check out work with http://tools.ietf.org/id/draft-bortzmeyer-dnsop-dns-privacy-01.txt - DONE - * Submit to IETF editor DONE - * Submit to dns-op IETF WG (after first publication via RFC editor) DONE + * DONE move samples to a separate section - DONE (two samples added in appendix) + * DONE cross check out work with http://tools.ietf.org/id/draft-bortzmeyer-dnsop-dns-privacy-01.txt + * DONE Submit to IETF editor + * DONE Submit to dns-op IETF WG (after first publication via RFC editor) * Import master file - how does this work from a passive DNS point of view? -> Paul? * More examples to add - to explain JSON escaping multi resource records and so on on (adulau) - * ABNF grammar (aaron) - * Check with aaron if sensor_id new definition matches the implementation in Austria + * DONE ABNF grammar (aaron) + * DONE Check with aaron if sensor\_id new definition matches the implementation in Austria Yes * Submit -02 to IETF editor + * Submit -03 to IETF editor diff --git a/i-d/pdns-qof.xml b/i-d/pdns-qof.xml index 270b3fe..59d5762 100644 --- a/i-d/pdns-qof.xml +++ b/i-d/pdns-qof.xml @@ -170,7 +170,7 @@ The document does not describe the protocol (e.g. WHOIS
- The formatting of the answer follows the JSON format. The order of the fields is not significant for the same resource type. + The formatting of the answer follows the JSON format. In fact, it is a subset of the full JSON language. Notable differences are the modified definition of whitespace ("ws"). The order of the fields is not significant for the same resource type. The intent of this output format is to be easily parsable by scripts. Each JSON object is expressed on a single line to be processed by the client line-by-line. Every implementation MUST support the JSON output format. Examples of JSON output are in the appendix.
@@ -180,14 +180,21 @@ answer = entries entries = * ( entry CR) entry = "{" keyvallist "}" keyvallist = [ member *( value-separator member ) ] -member = field name-separator value -name-separator = ws %x3A ws ; : colon +member = qm field qm name-separator value +name-separator = ws %x3A ws ; a ":" colon value = value ; as defined in the JSON RFC +value-separator = ws %x2C ws ; , comma. As defined in JSON field = "rrname" | "rrtype" | "rdata" | "time_first" | "time_last" | "count" | "bailiwick" | "sensor_id" | "zone_time_first" | "zone_time_last" | futureField futureField = string CR = %x0D +qm = %x22 ; " a quotation mark +ws = *( + %x20 | ; Space + %x09 ; Horizontal tab + ) + ]]> Note that value is defined in JSON and has the exact same specification as there. The same goes for the definition of string.
@@ -403,6 +410,7 @@ CR = %x0D "time_last": 1330209752} ]]> + Please note that in the examples above, any backslashes "\" can be ignored and are an artefact of the tools which produced this document.