Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
Julian Reschke <julian.reschke@gmx.de> Tue, 12 November 2013 14:01 UTC
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2011E8143 for <json@ietfa.amsl.com>; Tue, 12 Nov 2013 06:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.138
X-Spam-Level:
X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEsbglFYvJaK for <json@ietfa.amsl.com>; Tue, 12 Nov 2013 06:01:15 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3F11E8159 for <json@ietf.org>; Tue, 12 Nov 2013 06:01:11 -0800 (PST)
Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFcg9-1VukiW2RBl-00Ec5C for <json@ietf.org>; Tue, 12 Nov 2013 15:01:10 +0100
Message-ID: <528234A4.2040004@gmx.de>
Date: Tue, 12 Nov 2013 15:01:08 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: ietf@ietf.org
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com>
In-Reply-To: <20131111143420.20298.75880.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:ZHm/kn9oETzJKyoQdQi6i6mj7z8dkMXzkz4vUH20rxV503Uzqsb 0c7MXUOb3S4JdU5llYxuwfW7Quj7RrCwaDStu4KwZpHTxPwhBBp3zgulsqE5N8fkHin+8UR wcUeyzN4zFGvv5jiqr0rf9Islsh5f4B8VkE7/Idls2dDoDnz8SLcT4fVR8EilItoXfy1aIN G4nIrOzYZJxl5nJIeVJWA==
Cc: json@ietf.org
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 14:01:20 -0000
Hi there, below are my editorial comments: Abstract JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document makes no changes to the definition of JSON; it repairs specification errors and offers experience-based interoperability guidance. I believe historical considerations do not belong into the abstract (but into the Introduction) Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 10, 2014. Are we sure that we do not need the "pre-5378 escape clause" here? (Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>) The grammatical rules in this document are to be interpreted as described in [RFC5234]. Maybe note which productions are imported as well (HEXDIG and DIGIT it seems). This revision does not change any of the rules of the specification; all texts which were legal JSON remain so, and none which were not JSON become JSON. The revision's goal is to fix the errata and highlight practices which can lead to interoperability problems. s/fix errata/apply errata/ ? Insignificant whitespace is allowed before or after any of the six structural characters. ws = *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ) ; Carriage return We *could* use SP, HTAB, LF, and CR here. JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. That's a bit misleading. How do I "encode in Unicode"? I think what it tries to say is that one of the Unicode-compatible character encoding schemes needs to be used. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 I'm ok to sticking with this, but I'm also with AvK that it would be good to recommend (not necessarily RECOMMEND) UTF-8. An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings. Maybe this should be a bullet list? 10. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. "strictly"? Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used. As mentioned before, please clarify that there is no such thing as content-transfer-encoding in binary transports such as HTTP. Person & email address to contact for further information: IESG <iesg@ietf.org Missing ">"? Change controller: IESG <iesg@ietf.org Ditto. o Changed Working Group attribution to JSON Working Group. ...this is a change that will not be visible in the RFC. Furthermore, it would be great if the spec made it crystal-clear that application/json really really has no charset parameter; maybe as a NOTE? Finally, I did check the ABNF using Bill's ABNF Parser, and the result is good except for DIGIT and HEXDIG being defined elsewhere: > array = begin-array [ value *( value-separator value ) ] end-array > begin-array = ws "[" ws > begin-object = ws "{" ws > end-array = ws "]" ws > end-object = ws "}" ws > name-separator = ws ":" ws > value-separator = ws "," ws > ws = *( " " / %x09 / %x0A / %x0D ) > value = false / null / true / object / array / number / string > false = %x66.61.6C.73.65 > null = %x6E.75.6C.6C > true = %x74.72.75.65 > object = begin-object [ member *( value-separator member ) ] end-object > member = string name-separator value > number = [ minus ] int [ frac ] [ exp ] > decimal-point = "." > digit1-9 = %x31-39 > e = %x65 / %x45 > ; DIGIT UNDEFINED > exp = e [ minus / plus ] 1*DIGIT > frac = decimal-point 1*DIGIT > int = zero / ( digit1-9 *DIGIT ) > minus = "-" > plus = "+" > zero = "0" > string = quotation-mark *char quotation-mark > ; HEXDIG UNDEFINED > char = unescaped / ( escape ( %x22 / "\" / "/" / %x62 / %x66 / %x6E / %x72 / %x74 / ( %x75 4HEXDIG ) ) ) > escape = "\" > quotation-mark = %x22 > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Best regards, Julian
- [Json] Last Call: <draft-ietf-json-rfc4627bis-07.… The IESG
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… John Cowan
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Paul Hoffman
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Tim Bray
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Carsten Bormann
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Carsten Bormann
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Tim Bray
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… John Cowan
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Carsten Bormann
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Tim Bray
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Nico Williams
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Tim Bray
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Julian Reschke
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… John Cowan
- Re: [Json] Last Call: <draft-ietf-json-rfc4627bis… Joe Hildebrand (jhildebr)