Re: [Json] Description of parsers
Stefan Drees <stefan@drees.name> Mon, 10 June 2013 11:56 UTC
Return-Path: <stefan@drees.name>
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 A50AE21F8F29 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 04:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6]
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 qUTrWbr5+ZB6 for <json@ietfa.amsl.com>; Mon, 10 Jun 2013 04:56:16 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A8CD821F8647 for <json@ietf.org>; Mon, 10 Jun 2013 04:56:13 -0700 (PDT)
Received: from newyork.local.box ([93.129.126.10]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0M4lkz-1UQjp92N6T-00yz5Q; Mon, 10 Jun 2013 13:56:11 +0200
Message-ID: <51B5BED9.3030308@drees.name>
Date: Mon, 10 Jun 2013 13:56:09 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <20130609042518.11918.qmail@joyce.lan> <51B44197.2000006@drees.name> <014BC561-ECB9-4C82-B759-580025770E58@vpnc.org> <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org>
In-Reply-To: <2014F29A-4F38-4E8C-A05C-892F9B06A7E2@tzi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:YLPfFOPn0OEJX2GqXnygCphnRzvBbckkI7kJpfTFqMk+UcW163W 21btAl3u0izZxtaFZhVGomr0WpbXXh/JNwslHN1hKp6NPG3tqVs3x9ZRNubpdSxGMmIvEN6 X3TJAnt+9RzvehCxeksTzMseXiaPU4uzhx+VMIrH2wwy+xPsw1LKElv/1dtUe7Z6MQm5Jdi l8zpBjgx1wZ01Jf1xx58Q==
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "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
Reply-To: stefan@drees.name
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 11:56:22 -0000
On 2013-06-10 12:27 CEST, Carsten Bormann wrote: > On Jun 9, 2013, at 22:38, Paul Hoffman ... wrote: > >>> duplicate names in objects > > That doesn't mean anything, until it has been defined. I think here the contxt is confined to parsers and is a summarizing description with focus on the parsers. I understand the job of the section 2 to introduce the vocabulary. So the name is the first part of the ordered pair (name, value). > > Is "foofoo" a duplicate name? not in itself, but maybe if some other "foofoo" in the same object and nesting level comes along or preceeded it. > > Or is it just not allowed to write > { "foo" "foo" : "bar" } > ? here the parser is already out, as this is invalid JSON. > Or is it that all maps (objects) must have unique names, so > [{"foo": "bar"}, {"foo": "baz"}] > is an instance of a duplicate name? we should talk about names of a single object and nesting level. So no. > Or maybe this is about the names within an object, so > {"foo": {"foo": "bar"}} > is an instance of a duplicate name? No. ditto. > -> > 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). As long as we do not "invent" something, but are all sure, that the "common" knowledge where it fills a real gap has also been "shared by all known implementers" knowledge :-) ... > [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.] ... How do the existing validators and parsers decide that {"a" "a":"b"} is invalid maybe the ABNF rules :-?) """ object = begin-object [ member *( value-separator member ) ] end-object member = string name-separator value [...] string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF """ where "a" "a" seems not to match the rule for a string in rule member. All the best, Stefan.
- [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