Re: [Json] FYI: JSON discussion minutes (W3C TAG)

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 08 November 2013 08:03 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 318FF21E8200 for <json@ietfa.amsl.com>; Fri, 8 Nov 2013 00:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.688
X-Spam-Level:
X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 F9hUMqRAZq8B for <json@ietfa.amsl.com>; Fri, 8 Nov 2013 00:03:14 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8416021E81A7 for <json@ietf.org>; Fri, 8 Nov 2013 00:03:13 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA882trj019700; Fri, 8 Nov 2013 17:02:55 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_b40c_2cd9c786_484c_11e3_b4b7_001e6722eec2; Fri, 08 Nov 2013 17:02:54 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2DACEBF54D; Fri, 8 Nov 2013 17:02:55 +0900 (JST)
Message-ID: <527C9AA5.10503@it.aoyama.ac.jp>
Date: Fri, 08 Nov 2013 17:02:45 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "json@ietf.org" <json@ietf.org>
References: <C68CB012D9182D408CED7B884F441D4D348260C73B@nambxv01a.corp.adobe.com> <527A77B5.6060800@gmx.de> <CADnb78j28zpFh9Dv76oms+bhd6w9hL9UQXn_7p0c_LwHJJvWBQ@mail.gmail.com>
In-Reply-To: <CADnb78j28zpFh9Dv76oms+bhd6w9hL9UQXn_7p0c_LwHJJvWBQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <annevk@annevk.nl>, Larry Masinter <masinter@adobe.com>
Subject: Re: [Json] FYI: JSON discussion minutes (W3C TAG)
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: Fri, 08 Nov 2013 08:03:20 -0000

On 2013/11/07 23:31, Anne van Kesteren wrote:
> On Wed, Nov 6, 2013 at 5:09 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> FWIW, I think Anne misunderstands the ABNF vs "7 bit" issue. We've used ABNF
>> to specify things in terms of code points (instead of octets) lots of times.
>
> http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06#section-1.1
> does not define the alphabet used. I assumed ABNF defaulted to ASCII,
> but it appears I might have skimmed that incorrectly during the
> teleconference.

Good catch! There's no assumption that ABNF defaults to ASCII, but there 
is also no assumption that ABNF defaults to anything else. See
http://tools.ietf.org/html/rfc5234#section-2.4.

So this seems to be a hole in the current draft. Although the hole 
hasn't had lots of consequences so far (there's lots of context to help 
out), it seems advisable to fix it.

I herewith propose the following change to the second paragraph of 1.1:

OLD:

    The grammatical rules in this document are to be interpreted as
    described in [RFC5234].

NEW:

    The grammatical rules in this document are to be interpreted as
    described in [RFC5234].  Character numbers are taken from the
    Unicode, without implying any actual binary encoding.  Terminals
    in the ABNF are characters, not bytes.

(The additional text is based on the last part of the first paragraph of 
http://tools.ietf.org/html/rfc3987#section-2.2.)

For the process-inclined (read chairs and ADs): If this comment comes at 
a bad moment, please ignore it for the time being and consider it being 
made as a comment to the upcomming IETF last call.

Regards,   Martin.