Re: [Json] Description of parsers
Carsten Bormann <cabo@tzi.org> Mon, 10 June 2013 10:27 UTC
Return-Path: <cabo@tzi.org>
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 77DC621F8477 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 03:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.076
X-Spam-Level:
X-Spam-Status: No, score=-106.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3D1DpOzsgzAA for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 03:27:30 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4717D21F894E for <json@ietf.org>; Mon, 10 Jun 2013 03:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5AARMXa002128; Mon, 10 Jun 2013 12:27:22 +0200 (CEST)
Received: from [192.168.217.105] (p54893267.dip0.t-ipconnect.de [84.137.50.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 109283B35; Mon, 10 Jun 2013 12:27:21 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org>
Date: Mon, 10 Jun 2013 12:27:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org>
References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1508)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Description of parsers
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: Mon, 10 Jun 2013 10:27:41 -0000
On Jun 9, 2013, at 22:38, Paul Hoffman <paul.hoffman@vpnc.org> wrote: >> duplicate names in objects That doesn't mean anything, until it has been defined. Is "foofoo" a duplicate name? Or is it just not allowed to write { "foo" "foo" : "bar" } ? Or is it that all maps (objects) must have unique names, so [{"foo": "bar"}, {"foo": "baz"}] is an instance of a duplicate name? Or maybe this is about the names within an object, so {"foo": {"foo": "bar"}} is an instance of a duplicate name? -> Of the name/value pairs that comprise a single object, no two [shall/should/whatever] have the same name. For the purposes of this comparison, two names are the same if they are the same sequence of characters after processing the strings (2.5). [RFC 4627 doesn't quite define what that is, either, but one can complete section 2.5 with common knowledge such as that the quotes aren't meant to be part of the decoded string.] Grüße, Carsten
- [Json] Security Considerations Douglas Crockford
- Re: [Json] Security Considerations Gonzalo Salgueiro
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Peter Brooks
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Carsten Bormann
- [Json] Security Considerations Douglas Crockford
- Re: [Json] Security Considerations Stephan Beal
- Re: [Json] Security Considerations John Levine
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Douglas Crockford
- Re: [Json] Security Considerations Peter Brooks
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Description of parsers Stefan Drees
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Security Considerations Paul Hoffman
- Re: [Json] Security Considerations Peter brooks
- Re: [Json] Security Considerations John Cowan
- Re: [Json] Security Considerations Peter brooks
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Security Considerations Eliot Lear
- Re: [Json] Security Considerations Stefan Drees
- Re: [Json] Security Considerations John Levine
- Re: [Json] Security Considerations Stefan Drees
- [Json] Description of parsers Paul Hoffman
- Re: [Json] Description of parsers Stefan Drees
- Re: [Json] Description of parsers Carsten Bormann