Subject: [Json] Proposed changes for -03 based on IESG RFC Editor note

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jul 2017 12:33:48 +0200

Attached:

- diffs for the XML source
- TXT output
- HTML diffs
- source

Addresses:

- the change in 8.1
- the fix to the boilerplate
- broken metadata (invisible in txt output)
- updates the changelog
- updates Errata entries to the format defined in draft-flanagan-7322bis-01
- adds types to the artwork (for automatic ABNF extraction)
- avoids using hardwired section numbers in the changelog where possible

Best regards, Julian
--- draft-ietf-jsonbis-rfc7159bis-03.xml	2017-07-18 11:26:50.838824100 +0100
+++ draft-ietf-jsonbis-rfc7159bis-latest.xml	2017-07-18 11:23:10.793589800 +0100
@@ -20,10 +20,10 @@
 <?rfc subcompact="no" ?>
 
 <rfc category="std"
-     docName="draft-ietf-jsonbis-rfc7159bis-03"
+     docName="draft-ietf-jsonbis-rfc7159bis-latest"
      submissionType="IETF"
      consensus="yes"
-     obsoletes="4627, 7158, 7159"
+     obsoletes="7159"
      ipr="pre5378Trust200902">
 
 <front>
@@ -36,10 +36,9 @@
 </address>
 </author>
 
-<date day="19" month="February" year="2017"/>
-
-<area>Operations and Management</area>
-<workgroup>JSON Working Group</workgroup>
+<date/>
+<area>Applications and Real-Time</area>
+<workgroup>JSON</workgroup>
 
 <abstract>
 
@@ -93,7 +92,7 @@
 
 </section>
 
-<section title="Specifications of JSON">
+<section title="Specifications of JSON" anchor="specifications.of.json">
 <t>This document updates <xref target="RFC4627" />, which describes
 JSON and registers the media type "application/json".</t>
 <t>JSON is also described in <xref target="ECMA-404" />.</t>
@@ -113,7 +112,7 @@
 together to ensure that the two documents stay aligned through the change.</t>
 </section>
 
-<section title="Introduction to This Revision">
+<section title="Introduction to This Revision" anchor="introduction.to.this.revision">
 <t>In the years since the publication of RFC 4627, JSON has found very wide 
 use. This experience has revealed certain patterns,
 which, while allowed by its specifications, have caused interoperability
@@ -141,13 +140,13 @@
 called for will be interoperable in the sense that all implementations will
 accept these as conforming JSON texts.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    JSON-text = ws value ws
 </artwork></figure>
 
 <t>These are the six structural characters:</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    begin-array     = ws %x5B ws  ; [ left square bracket
 
    begin-object    = ws %x7B ws  ; { left curly bracket
@@ -164,7 +163,7 @@
 <t>Insignificant whitespace is allowed before or after any of the six
 structural characters.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    ws = *(
            %x20 /              ; Space
            %x09 /              ; Horizontal tab
@@ -178,14 +177,14 @@
 <t>A JSON value MUST be an object, array, number, or string, or one of
 the following three literal names:</t>
 
-<figure><artwork>
+<figure><artwork type="inline">
    false null true
 </artwork></figure>
 
 <t>The literal names MUST be lowercase.  No other literal names are
 allowed.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    value = false / null / true / object / array / number / string
 
    false = %x66.61.6c.73.65   ; false
@@ -205,7 +204,7 @@
 from the value.  A single comma separates a value from a following
 name.  The names within an object SHOULD be unique.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    object = begin-object [ member *( value-separator member ) ]
             end-object
 
@@ -234,7 +233,7 @@
 <t>An array structure is represented as square brackets surrounding zero
 or more values (or elements).  Elements are separated by commas.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
 array = begin-array [ value *( value-separator value ) ] end-array
 </artwork></figure>
 
@@ -259,7 +258,7 @@
 <t>Numeric values that cannot be represented in the grammar below
 (such as Infinity and NaN) are not permitted.</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    number = [ minus ] int [ frac ] [ exp ]
 
    decimal-point = %x2E       ; .
@@ -328,7 +327,7 @@
 containing only the G clef character (U+1D11E) may be represented as
 "\uD834\uDD1E".</t>
 
-<figure><artwork>
+<figure><artwork type="abnf">
    string = quotation-mark *char quotation-mark
 
    char = unescaped /
@@ -354,20 +353,23 @@
 
 <section title="String and Character Issues">
 
-<section title="Character Encoding">
-<t>JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 
-<xref target="UNICODE" /> (Section 3).  The default
-encoding is UTF-8, and
-JSON texts that are encoded in UTF-8 are interoperable in the sense that
-they will be read successfully by the maximum number of implementations; there
-are many implementations that cannot successfully read texts in other
-encodings (such as UTF-16 and UTF-32).</t>
-
-<t>Implementations MUST NOT add a byte order mark (U+FEFF)
-to the beginning of a JSON
-text. In the interests of interoperability, implementations that parse JSON
-texts MAY ignore the presence of a byte order mark rather than treating it as
-an error.</t> 
+<section title="Character Encoding" anchor="character.encoding">
+<t>
+When transmitting over a network protocol, or as a payload of a
+network protocol intended to be interpreted as part of a protocol,
+JSON text MUST be encoded in UTF-8 (Section 3 of <xref target="UNICODE"/>).</t>
+
+<t>Previous specifications of JSON have not required the use of UTF-8
+when transmitting JSON text. However, the vast majority of
+JSON-based software implementations have chosen to use the UTF-8
+encoding, to the extent that it is the only encoding that achieves
+interoperability.</t>
+
+<t>Implementations MUST NOT add a byte order mark (U+FEFF) to the
+beginning of a networked-transmitted JSON text.  In the interests
+of interoperability, implementations that parse JSON texts MAY
+ignore the presence of a byte order mark rather than treating it
+as an error.</t>
 </section>
 
 <section anchor="unichars" title="Unicode Characters">
@@ -473,7 +475,7 @@
 </t>
 </section>
 
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
 
 <t>Generally, there are security issues with scripting languages.  JSON
 is a subset of JavaScript but excludes
@@ -496,7 +498,7 @@
 
 <t>This is a JSON object:</t>
 
-<figure><artwork>
+<figure><artwork type="example">
    {
      "Image": {
          "Width":  800,
@@ -518,7 +520,7 @@
 
 <t>This is a JSON array containing two objects:</t>
 
-<figure><artwork>
+<figure><artwork type="example">
    [
      {
         "precision": "zip",
@@ -544,7 +546,7 @@
 </artwork></figure>
 
 <t>Here are three small JSON texts containing only values:</t>
-<figure><artwork>
+<figure><artwork type="example">
 
 "Hello world!"
 
@@ -629,7 +631,7 @@
 <seriesInfo name="Standard" value="ECMA-262"/>
 </reference>
 
-<reference anchor="Err607" target="http://www.rfc-editor.org"> 
+<reference anchor="Err607" target="https://www.rfc-editor.org/errata/eid607"> 
 <front> 
 <title>Errata ID 607</title>
 <author><organization>RFC Errata</organization></author> 
@@ -638,7 +640,7 @@
 <seriesInfo name="RFC" value="4627"/>
 </reference>
 
-<reference anchor="Err3607" target="http://www.rfc-editor.org"> 
+<reference anchor="Err3607" target="https://www.rfc-editor.org/errata/eid3607"> 
 <front> 
 <title>Errata ID 3607</title>
 <author><organization>RFC Errata</organization></author> 
@@ -647,7 +649,7 @@
 <seriesInfo name="RFC" value="4627"/>
 </reference>
 
-<reference anchor="Err3915" target="http://www.rfc-editor.org"> 
+<reference anchor="Err3915" target="https://www.rfc-editor.org/errata/eid3915"> 
 <front> 
 <title>Errata ID 7159</title>
 <author><organization>RFC Errata</organization></author> 
@@ -656,7 +658,7 @@
 <seriesInfo name="RFC" value="7159"/>
 </reference>
 
-<reference anchor="Err4264" target="http://www.rfc-editor.org"> 
+<reference anchor="Err4264" target="https://www.rfc-editor.org/errata/eid4264"> 
 <front> 
 <title>Errata ID 7159</title>
 <author><organization>RFC Errata</organization></author> 
@@ -665,7 +667,7 @@
 <seriesInfo name="RFC" value="7159"/>
 </reference>
 
-<reference anchor="Err4336" target="http://www.rfc-editor.org"> 
+<reference anchor="Err4336" target="https://www.rfc-editor.org/errata/eid4336"> 
 <front> 
 <title>Errata ID 7159</title>
 <author><organization>RFC Errata</organization></author> 
@@ -683,15 +685,18 @@
 
 <t><list style="symbols">
 
-<t>Section 1.2 has been updated to reflect the removal of a JSON specification
+<t><xref target="specifications.of.json"/> has been updated to reflect the removal of a JSON specification
 from ECMA-262, to make the reference to ECMA-404 normative, and to explain 
 the particular meaning of "normative".
 </t>
 
-<t>Section 1.3 has been updated to reflect errata filed against RFC7159, 
+<t><xref target="introduction.to.this.revision"/> has been updated to reflect errata filed against RFC7159, 
 not RFC4627.</t>
 
-<t>Section 12 has been updated to increase the precision of the description
+<t><xref target="character.encoding"/> was changed to require the use of UTF-8 when transmitted over a network.
+</t>
+
+<t><xref target="security.considerations"/> has been updated to increase the precision of the description
 of the security risk that follows from using the ECMAScript "eval()"
 function.</t>