Merge pull request #14 from djw1149/master

Various changes discussed with Authors

i-d/pdns-qof.xml

@@ -50,7 +50,7 @@
 <?rfc subcompact="no" ?>
 <!-- keep one blank line between list items -->
 <!-- end of list of popular I-D processing instructions -->
-<rfc category="info" docName="draft-dulaunoy-dnsop-passive-dns-cof-03" ipr="trust200902">
+<rfc category="info" docName="draft-dulaunoy-dnsop-passive-dns-cof-05" ipr="trust200902">
   <!-- category values: std, bcp, info, exp, and historic
      ipr values: full3667, noModification3667, noDerivatives3667
      you can add the attributes updates="NNNN" and obsoletes="NNNN"
@@ -129,7 +129,7 @@
 		</address>
 	</author>
 
-    <date month="June" year="2017" />
+    <date month="February" year="2019" />
     <area>General</area>
     <workgroup>Domain Name System Operations</workgroup>
 
@@ -186,7 +186,8 @@ 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" | "origin" | futureField
+                  "zone_time_first" | "zone_time_last" | "origin" |
+                  futureField
 futureField     = string
 CR              = %x0D
 qm              = %x22                  ; " a quotation mark
@@ -200,20 +201,20 @@ ws              = *(
 		</section>
 		<section title="Mandatory Fields">
 			<t>Implementation MUST support all the mandatory fields.</t>
-			<t>Uniqueness property: the tuple (rrname,rrtype,rdata) will always be unique within one answer per server. While rrname and rrtype are always individual JSON primitive types (strings, numbers, booleans or null), rdata MAY return multiple resource records or a single record. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string.</t>
+			<t>Uniqueness property: the tuple (rrname,rrtype,rdata) will always be unique within one answer per server. While rrname and rrtype are always individual JSON primitive types (strings, numbers, booleans or null), rdata MAY return multiple resource records or a single record. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string or a JSON array containing one JSON string.  Senders SHOULD send an array for rdata, but receivers MUST be able to accept a single-string result for rdata.</t>
 			<section title="rrname">
 				<t>This field returns the name of the queried resource.</t>
 			</section>
 			<section title="rrtype">
-			 <t>This field returns the resource record type as seen by the passive DNS. The key is rrtype and the value is in the interpreted record type represented as a <xref target="RFC4627">JSON</xref> string. If the value cannot be interpreted the decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>. Then the decimal value is represented as a <xref target="RFC4627">JSON</xref> number.
+			 <t>This field returns the resource record type as seen by the passive DNS. The key is rrtype and the value is in the interpreted record type represented as a <xref target="RFC4627">JSON</xref> string. If the value cannot be interpreted, the decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>. Then the decimal value is represented as a <xref target="RFC4627">JSON</xref> number.
 
 			 The resource record type can be any values as described by IANA in the DNS parameters document in the section 'Resource Record (RR) TYPEs' (http://www.iana.org/assignments/dns-parameters).
-			 Currently known and supported textual descriptions of rrtypes are: A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6.
+                         Supported textual descriptions of rrtypes include: A, AAAA, CNAME, etc.
-			 A client MUST be able to understand these textual rrtype values represented as a  <xref target="RFC4627">JSON</xref> string. In addition, a client MUST be able to handle a decimal value (as mentioned above) as answer represented as a  <xref target="RFC4627">JSON</xref> number.
+			 A client MUST be able to understand these textual rrtype values represented as a  <xref target="RFC4627">JSON</xref> string. In addition, a client MUST be able to handle a decimal value (as mentioned above) answer represented as a <xref target="RFC4627">JSON</xref> number.
 			</t>
 			</section>
 			<section title="rdata">
-				<t>This field returns the resource records of the queried resource. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string. Each resource record is represented as a <xref target="RFC4627">JSON</xref> string. Each resource record MUST be escaped as defined in section 2.6 of <xref target="RFC4627">RFC4627</xref>. Depending on the rrtype, this can be an IPv4 or IPv6 address, a domain name (as in the case of CNAMEs), an SPF record, etc.  A client MUST be able to interpret any value which is legal as the right hand side in a DNS master file  <xref target="RFC1035">RFC 1035</xref> and <xref target="RFC1034">RFC 1034</xref>. If the rdata came from an unknown DNS resource records, the server must follow the transparency principle as described in <xref target="RFC3597">RFC 3597</xref>.</t>
+				<t>This field returns the resource records of the queried resource. When multiple resource records are returned, rdata MUST be a JSON array containing JSON strings. In the case of a single resource record is returned, rdata MUST be a JSON string or a JSON array containing one JSON string. Each resource record is represented as a <xref target="RFC4627">JSON</xref> string. Each resource record MUST be escaped as defined in section 2.6 of <xref target="RFC4627">RFC4627</xref>. Depending on the rrtype, this can be an IPv4 or IPv6 address, a domain name (as in the case of CNAMEs), an SPF record, etc.  A client MUST be able to interpret any value which is legal as the right hand side in a DNS master file  <xref target="RFC1035">RFC 1035</xref> and <xref target="RFC1034">RFC 1034</xref>. If the rdata came from an unknown DNS resource records, the server must follow the transparency principle as described in <xref target="RFC3597">RFC 3597</xref>.</t>
 			</section>
 			<section title="time_first">
 				<t>This field returns the first time that the record / unique tuple (rrname, rrtype, rdata) has been seen by the passive DNS. The date is expressed in seconds (decimal) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. This field is represented as a <xref target="RFC4627">JSON</xref> number.</t>
@@ -325,7 +326,7 @@ ws              = *(
         </reference>
         <reference anchor="CACHEPOISONING" target="http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf">
           <front>
-            <title>Black ops 2008: It&#8217;s the end of the cache as we know it.</title>
+            <title>Black ops 2008: It's the end of the cache as we know it.</title>
             <author fullname="Dan Kaminsky"/>
             <date year="2008"/>
           </front>
@@ -399,7 +400,7 @@ ws              = *(
       <!-- &I-D.draft-bortzmeyer-dnsop-dns-privacy; -->
     </references>
   <section anchor="app-additional" title="Examples">
-<t>The JSON output are represented on multiple lines for readability but each JSON object should on a single line.</t>
+<t>The JSON output are represented on multiple lines for readability but each JSON object should be on a single line.</t>
 <t>If you query a passive DNS for the rrname www.ietf.org, the passive dns common output format can be:</t>
 <figure><artwork>
         <![CDATA[
@@ -425,7 +426,8 @@ ws              = *(
 "time_last": 1330209752}
         ]]>
 </artwork></figure>
-	<t>Please note that in the examples above, any backslashes "\" can be ignored and are an artefact of the tools which produced this document.</t>
+	<t>Please note that the examples imply that a single query returns a single set of JSON objects. For example, two queries were made; one query returned a set of two JSON objects and the other query returned a set of three JSON objects. This specification requires each JSON object individually MUST conform to the common output format, but this specification does not require that a query will return a set of JSON objects.</t>
+	<t>Please note that in the examples above, any backslashes "\" can be ignored and are an artifact of the tools which produced this document.</t>
           </section>
 
   </back>