Re: [Json] Response to Statement from W3C TAG

Nico Williams <nico@cryptonector.com> Mon, 09 December 2013 00:54 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D451AE187 for <json@ietfa.amsl.com>; Sun, 8 Dec 2013 16:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqY72n4HXXgl for <json@ietfa.amsl.com>; Sun, 8 Dec 2013 16:54:55 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2425A1AE12C for <json@ietf.org>; Sun, 8 Dec 2013 16:54:55 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 6F6CA1601; Sun, 8 Dec 2013 16:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0nn1t8ono6j3WO VpVMtQZOqICXc=; b=tg4T+muA5e3NAp+hEvcwf7pCag76ffdDvtG+uF6lGOybh0 VqsFtednJHhvGl+CpAj9c3Ox3cQ6PYrHCUEdcg6uNtY7mHwa2RoE9ySe6hqsqUr/ hJUFZsUzz1wA9InHEkcTLay22oErrhcpfgJtfoEoGIs6G6oeGccPOEjTJfqaI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id BB7C41600; Sun, 8 Dec 2013 16:54:49 -0800 (PST)
Date: Sun, 08 Dec 2013 18:54:49 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131209005444.GJ4067@localhost>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <20131208072144.GF4067@localhost> <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 09 Dec 2013 00:54:56 -0000

On Sun, Dec 08, 2013 at 11:13:12AM -0800, Allen Wirfs-Brock wrote:
> I agree.  Fundamentally I have been asking what is the technical
> meaning of the statement "an object is an unordered collection" that
> occurs in section 1 (Introduction) of the current draft for 4627bis.
> No one has yet responded to my question regarding whether or not
> statements in the Introduction are considered normative.  

Tim's proposed addition to section 4 should address this.

Specifically, "unordered" means that interoperable implementations can't
rely on object name ordering (nor duplicate handing, for that matter).
Note that there's no SHOULD or MUST as to this.  We had long, long
discussions over this where some insisted on stronger language
forbidding duplicates, and we settled for this description instead.

> Section 4 which presumably is supplying the normative specification of
> a JSON object currently says nothing about member ordering.  

Tim's proposed addition to section 4 should address this.  I support it.

> If the intent is for the statement in the introduction to have some
> normative mean, then please make that meaning technically clear in
> section 4. 

It's not intended to have normative meaning in the sense of an RFC2119
MUST.  See those long, long discussions in the archives.

Nico
--