From nobody Sun Mar 2 00:38:23 2014 Return-Path: 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 29B481A080B for ; Sun, 2 Mar 2014 00:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 BYQ9MKlxFiJF for ; Sun, 2 Mar 2014 00:38:18 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCE91A03BC for ; Sun, 2 Mar 2014 00:38:18 -0800 (PST) Received: from [10.128.17.221] (unknown [77.108.153.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 102F3509B5 for ; Sun, 2 Mar 2014 03:38:14 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> Date: Sun, 2 Mar 2014 08:38:13 +0000 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/pEBXrdqHWeTQwsGUsUUo3xnw7pI Subject: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 08:38:20 -0000 > JSON5 is a proposed extension to JSON that brings ES5 enhancements to = its syntax. It remains a strict subset of JavaScript, adds no new data = types, and is astrict superset of existing JSON. -- Mark Nottingham http://www.mnot.net/ From nobody Sun Mar 2 01:46:54 2014 Return-Path: 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 BC0981A0C41 for ; Sun, 2 Mar 2014 01:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 bdUVeJp39SL2 for ; Sun, 2 Mar 2014 01:46:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C74A91A0C13 for ; Sun, 2 Mar 2014 01:46:50 -0800 (PST) Received: from [172.16.32.52] (82-71-30-153.dsl.in-addr.zen.co.uk [82.71.30.153]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s229kiH7021524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Mar 2014 02:46:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 82-71-30-153.dsl.in-addr.zen.co.uk [82.71.30.153] claimed to be [172.16.32.52] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> Date: Sun, 2 Mar 2014 09:46:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/tlotxBTKLKUJ2kqmHnFMbofN1dE Cc: JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 09:46:51 -0000 On Mar 2, 2014, at 8:38 AM, Mark Nottingham wrote: >=20 > >=20 >> JSON5 is a proposed extension to JSON that brings ES5 enhancements to = its syntax. It remains a strict subset of JavaScript, adds no new data = types, and is astrict superset of existing JSON. This appears to only be meant to work in a Javascript program, yes? = Otherwise, what the heck does "Object keys can be unquoted if they're = valid identifiers" mean? --Paul Hoffman= From nobody Sun Mar 2 01:59:08 2014 Return-Path: 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 4E14A1A08C4 for ; Sun, 2 Mar 2014 01:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5Dek_afaYrq7 for ; Sun, 2 Mar 2014 01:59:01 -0800 (PST) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 369441A0C41 for ; Sun, 2 Mar 2014 01:59:00 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id pa12so2582892veb.29 for ; Sun, 02 Mar 2014 01:58:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9tMknfsSQLWI/RsoSyw+f07pjtxECMrcEhqJzM1Hms8=; b=mVDNtqUujxUIO6fw4YEx5X6ocaQkV9Pe9Ya6FNX4PnnPa8bXOe8q2r5sIwJArccsMP IlqeSVuhrOIaLQCM9UMp2uGPZIDJ1YT/iMJiwHlv9B0jZjkeePU63ctwgL9Ywrs8jRCu aysM7gpbuZK4m9/umbwcSGmfz5rWNuZnkAhtvXsuNi7pXslp5VvG7RrgfQg3et7jWsJB 2zdNxvvgmP6sziyi+p17PpH4sFRSFFFoSRGaoN7nWjpM1MESf3EgtWTtcAcwwUa/YD75 muyuN6tPKma1nmRBqgAk7pxzQJSg5eJA0k2bimVbcVxlMIoMz1WMqKnG9txfF1BFt4hO XsQQ== X-Gm-Message-State: ALoCoQliYdaojtl9CgZJCoQfEV08RmwhSXC9OLrhNbUpH0rX+G8LaRwoWYVWVFUU/EZBppm2m3iU MIME-Version: 1.0 X-Received: by 10.220.106.84 with SMTP id w20mr11519002vco.18.1393754337177; Sun, 02 Mar 2014 01:58:57 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sun, 2 Mar 2014 01:58:57 -0800 (PST) X-Originating-IP: [130.129.155.179] In-Reply-To: <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> Date: Sun, 2 Mar 2014 01:58:57 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b3435c02c4af004f39cb8c3 Archived-At: http://mailarchive.ietf.org/arch/msg/json/a5S9WMcs8UKrNR_fzRtmay4yx4k Cc: Mark Nottingham , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 09:59:04 -0000 --047d7b3435c02c4af004f39cb8c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It says =E2=80=9Cthis implementation doesn=E2=80=99t handle Unicode charact= ers=E2=80=9D. Unfortunately, that=E2=80=99s more or less all the characters I use. Actually, quite sensible on the surface, aside from allowing +/-Infinity. On Sun, Mar 2, 2014 at 1:46 AM, Paul Hoffman wrote: > On Mar 2, 2014, at 8:38 AM, Mark Nottingham wrote: > > > > > > > > >> JSON5 is a proposed extension to JSON that brings ES5 enhancements to > its syntax. It remains a strict subset of JavaScript, adds no new data > types, and is astrict superset of existing JSON. > > This appears to only be meant to work in a Javascript program, yes? > Otherwise, what the heck does "Object keys can be unquoted if they're val= id > identifiers" mean? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b3435c02c4af004f39cb8c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It says =E2=80=9Cthis implementation doesn=E2=80=99t handl= e Unicode characters=E2=80=9D. =C2=A0Unfortunately, that=E2=80=99s more or = less all the characters I use.

Actually, quite sensible = on the surface, aside from allowing +/-Infinity.


On Sun,= Mar 2, 2014 at 1:46 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Mar 2, 2014, at 8:38 AM, = Mark Nottingham <mnot@mnot.net> = wrote:

>
> <http://json5.org/<= /a>>
>
>> JSON5 is a proposed extension to JSON that brings ES5 enhancements= to its syntax. It remains a strict subset of JavaScript, adds no new data = types, and is astrict superset of existing JSON.

This appears to only be meant to work in a Javascript program, yes? O= therwise, what the heck does "Object keys can be unquoted if they'= re valid identifiers" mean?

--Paul Hoffman
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b3435c02c4af004f39cb8c3-- From nobody Sun Mar 2 03:42:11 2014 Return-Path: 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 9E24E1A0D75 for ; Sun, 2 Mar 2014 03:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 zvD7X2L-U0EU for ; Sun, 2 Mar 2014 03:42:07 -0800 (PST) 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 A7C141A0D5F for ; Sun, 2 Mar 2014 03:42:06 -0800 (PST) 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.5/8.14.5) with ESMTP id s22Bg1kM011584; Sun, 2 Mar 2014 12:42:01 +0100 (CET) Received: from dhcp-9be3.meeting.ietf.org (dhcp-9be3.meeting.ietf.org [31.133.155.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D14CBE42; Sun, 2 Mar 2014 12:42:00 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> Date: Sun, 2 Mar 2014 11:41:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/O4G9CaCR05sqAJNRW7WgQ22iG8s Cc: JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 11:42:08 -0000 > In other news, there are $ NI * NV + 1 $ JSON variants (where $ NI $ =3D = number of implementations, $ NV $ =3D average number of configuration = variants per implementation, $ + 1 $ for the standard itself). Embrace and extend works for open source, too. Putting in a clever extension to JSON can be exploited to create = customer lock-in for an open-source library. That=92s why smart people use standards. Gr=FC=DFe, Carsten From nobody Sun Mar 2 04:16:26 2014 Return-Path: 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 ECE161A0923 for ; Sun, 2 Mar 2014 04:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 f5mcRjgUFmmw for ; Sun, 2 Mar 2014 04:16:09 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AD1A0C99 for ; Sun, 2 Mar 2014 04:16:08 -0800 (PST) Received: (qmail 7869 invoked from network); 2 Mar 2014 12:15:21 +0000 Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 2 Mar 2014 12:15:21 +0000 Message-ID: <211FD4E4CB37411AA3BA79156DEF9160@codalogic> From: "Pete Cordell" To: "JSON WG" References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> Date: Sun, 2 Mar 2014 12:15:34 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Vipre-Scanned: 001EA323006974001EA470 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/json/71e8JejXVPuL4GLoLSsNrpV61oI Cc: Mark Nottingham , Tim Bray , Paul Hoffman Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 12:16:11 -0000 Actually, I really wish the IETF would grab the bull by the horns and define a notation that is geared towards it's purposes rather than continually making do with everyone else's second-hand cast offs! I think something JSON like would be good, but with a few modifications. For example SHON - Simple Humanized Object Notation: // Implicit initial object - no { // Comments are allowed a_name_without_space: 12 // Unquoted whitespace without a comma separates records "a name with spaces": 14 an_array: 15, 16, 17 // Commas implicitly create an array an_array: 18 // Another member for an_array a_string: "A string" another_string: 'Another string' an_object: { /* as JSON */ } Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Tim Bray" To: "Paul Hoffman" Cc: "Mark Nottingham" ; "JSON WG" Sent: Sunday, March 02, 2014 9:58 AM Subject: Re: [Json] Meanwhile, out there... It says “this implementation doesn’t handle Unicode characters”. Unfortunately, that’s more or less all the characters I use. Actually, quite sensible on the surface, aside from allowing +/-Infinity. On Sun, Mar 2, 2014 at 1:46 AM, Paul Hoffman wrote: > On Mar 2, 2014, at 8:38 AM, Mark Nottingham wrote: > > > > > > > > >> JSON5 is a proposed extension to JSON that brings ES5 enhancements to > its syntax. It remains a strict subset of JavaScript, adds no new data > types, and is astrict superset of existing JSON. > > This appears to only be meant to work in a Javascript program, yes? > Otherwise, what the heck does "Object keys can be unquoted if they're > valid > identifiers" mean? > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -------------------------------------------------------------------------------- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun Mar 2 04:51:09 2014 Return-Path: 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 657E31A0D22 for ; Sun, 2 Mar 2014 04:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 cnkETzT0qaZz for ; Sun, 2 Mar 2014 04:51:05 -0800 (PST) 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 3ED371A0D1A for ; Sun, 2 Mar 2014 04:51:05 -0800 (PST) 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.5/8.14.5) with ESMTP id s22CopDk021669; Sun, 2 Mar 2014 13:50:52 +0100 (CET) Received: from dhcp-9be3.meeting.ietf.org (dhcp-9be3.meeting.ietf.org [31.133.155.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 06A37E5F; Sun, 2 Mar 2014 13:50:50 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: <211FD4E4CB37411AA3BA79156DEF9160@codalogic> Date: Sun, 2 Mar 2014 12:50:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> <211FD4E4CB37411AA3BA79156DEF9160@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/xWT7HHm4Dmjhty8y5aiAsfCEyQA Cc: Mark Nottingham , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 12:51:06 -0000 On 02 Mar 2014, at 12:15, Pete Cordell wrote: > SHON - Simple Humanized Object Notation YAML already fills this niche rather nicely. It is a stable, widely implemented specification. (It also happens to include JSON as a subset.) There often is confusion because JSON is =93human-readable=94. However, JSON is for app-to-app, not for human-to-app. Most naive JSON extension proposals are based in not understanding this = fine point. In a pinch, JSON can be used for human-to-app. But instead of trying to extend JSON to become another YAML, just use = YAML for human-to-app. (Human-readable, more generally speaking text-based, formats have = certain advantages over binary formats even for app-to-app. Insert MEGACO flip-a-coin story here.) Gr=FC=DFe, Carsten From nobody Sun Mar 2 07:24:18 2014 Return-Path: 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 C18D21A07DB for ; Sun, 2 Mar 2014 07:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 AeB69d1Z87ux for ; Sun, 2 Mar 2014 07:24:11 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 032281A07DA for ; Sun, 2 Mar 2014 07:24:10 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so3968596lbg.35 for ; Sun, 02 Mar 2014 07:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FBVVFGSVUwKEu7yGI8Cs/RczNHFEudMypqxgXjk9mQo=; b=qIM+BGzf39IhEeJfXQrRsEfWdBKFcCchW+hhgAsB6WK+yCs+7if9L+5mLlexhFXby7 hJVu4LCTtd0wnHhifUgvgTMmydwq2ijBGf6oE99+WcvGrks84Y/PtFpf9J0LMnGxyPVP EPqCEy0Nbuaz0hA8aEN+Y0bv0P7JlaXxbr7rJBaYN1neh/HNL04+hE2bHrwIvQovAFod uSAv7gpvxm8kYTInRlpmx2tddkLsYZ0aCHfAdAWF2j5ShAAjucfuIDlgWhZG6d19ubyA R+q0yY60pagWQVFAvdVcJ0ggsA4UKG+pydX3K62ccTWtvJj7djM6Ov7m7xHSbviUC8Kt F9FA== MIME-Version: 1.0 X-Received: by 10.152.7.97 with SMTP id i1mr2119399laa.36.1393773847850; Sun, 02 Mar 2014 07:24:07 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sun, 2 Mar 2014 07:24:07 -0800 (PST) In-Reply-To: <211FD4E4CB37411AA3BA79156DEF9160@codalogic> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> <211FD4E4CB37411AA3BA79156DEF9160@codalogic> Date: Sun, 2 Mar 2014 15:24:07 +0000 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=001a11c27b7a19350404f3a143e2 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Vx05UEzScS1I5GaFJOQ3frPkzqI Cc: Mark Nottingham , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 15:24:14 -0000 --001a11c27b7a19350404f3a143e2 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 2, 2014 at 12:15 PM, Pete Cordell wrote: > Actually, I really wish the IETF would grab the bull by the horns and > define a notation that is geared towards it's purposes rather than > continually making do with everyone else's second-hand cast offs! > > I think something JSON like would be good, but with a few modifications. > For example SHON - Simple Humanized Object Notation: > > // Implicit initial object - no { > // Comments are allowed > a_name_without_space: 12 > // Unquoted whitespace without a comma separates records > "a name with spaces": 14 > an_array: 15, 16, 17 // Commas implicitly create an array > an_array: 18 // Another member for an_array > a_string: "A string" > another_string: 'Another string' > an_object: { /* as JSON */ } > > > Well I could add these as variant syntax in JSONSchema https://sourceforge.net/projects/jsonschema/ It is a bit of a misnomer now because I had to write a HTTP server so I added in a parser/encoder module for RFC822 headers. At the moment I have three variations on JSON that extend the JSON core incrementally JSON-B Adds length delimited binary blobs and strings so that it is not necessary to mess about with BASE64 encoding or escaping UNICODE strings. This makes modularity a lot easier as it is now easy to wrap one JSON structure inside another. JSON-C Adds in the compression capabilities people often insist are needed. JSON-D Supports a full range of binary encodings for data etc. I am thinking about adding in JSON-A which would be an extension to the ASCII control codes. While people say JSON is a UNICODE format this is only actually true of JSON strings. It is not legal for a JSON encoding to have UNICODE characters anywhere else. Comments are a commonly requested feature. They are essential for using JSON for configuration so lets add them. Another essential capability is being able to use JSON for append-only log file updates. Most operating systems have handlers that can be used to make append only access transactional. I will think about the consequences of making LF an implicit comma. -- Website: http://hallambaker.com/ --001a11c27b7a19350404f3a143e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 2, 2014 at 12:15 PM, Pete Cordell <= ;petejson@codal= ogic.com> wrote:
Actually, I really wish the IETF would grab the bull by th= e horns and define a notation that is geared towards it's purposes rath= er than continually making do with everyone else's second-hand cast off= s!

I think something JSON like would be good, but with a few modifications. Fo= r example SHON - Simple Humanized Object Notation:

// Implicit initial object - no {
// Comments are allowed
a_name_without_space: 12
// Unquoted whitespace without a comma separates records
"a name with spaces": 14
an_array: 15, 16, 17 =A0 =A0// Commas implicitly create an array
an_array: 18 =A0 =A0// Another member for an_array
a_string: "A string"
another_string: 'Another string'
an_object: { /* as JSON */ }

</rant>

Well I could add these as= variant syntax in JSONSchema



It is a bit of a misnomer now because I = had to write a HTTP server so I added in a parser/encoder module for RFC822= headers.=A0

At the moment I have three variations= on JSON that extend the JSON core incrementally

JSON-B =A0 Adds length delimited binary blobs and strin= gs so that it is not necessary to mess about with BASE64 encoding or escapi= ng UNICODE strings. This makes modularity a lot easier as it is now easy to= wrap one JSON structure inside another.

JSON-C =A0Adds in the compression capabilities people o= ften insist are needed.

JSON-D Supports a full ran= ge of binary encodings for data etc.


I am thinking about adding in JSON-A which would be an extension to the ASC= II control codes. While people say JSON is a UNICODE format this is only ac= tually true of JSON strings. It is not legal for a JSON encoding to have UN= ICODE characters anywhere else.


Comments are a commonly requested featur= e. They are essential for using JSON for configuration so lets add them.=A0=

Another essential capability is being able to use= JSON for append-only log file updates. Most operating systems have handler= s that can be used to make append only access transactional.=A0

I will think about the consequences of making LF an imp= licit comma.

--
Website: http://hallambaker.com/
--001a11c27b7a19350404f3a143e2-- From nobody Sun Mar 2 08:10:20 2014 Return-Path: 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 31EC81A093A; Sun, 2 Mar 2014 08:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 uWfm9RHN9bbF; Sun, 2 Mar 2014 08:09:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 96B351A0938; Sun, 2 Mar 2014 08:09:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1FBAC7FC3AA; Sun, 2 Mar 2014 08:09:39 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140302160939.1FBAC7FC3AA@rfc-editor.org> Date: Sun, 2 Mar 2014 08:09:39 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Ox4DzKW6EeyEPBFASJRpQBGfhdc Cc: drafts-update-ref@iana.org, json@ietf.org, rfc-editor@rfc-editor.org Subject: [Json] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:09:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7158 Title: The JavaScript Object Notation (JSON) Data Interchange Format Author: T. Bray, Ed. Status: Standards Track Stream: IETF Date: March 2014 Mailbox: tbray@textuality.com Pages: 16 Characters: 27451 Obsoletes: RFC 4627 I-D Tag: draft-ietf-json-rfc4627bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc7158.txt 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 removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document is a product of the JavaScript Object Notation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Mar 2 08:41:25 2014 Return-Path: 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 7E5581A096F for ; Sun, 2 Mar 2014 08:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 2xikZk2UwZsJ for ; Sun, 2 Mar 2014 08:41:21 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 99BB41A0972 for ; Sun, 2 Mar 2014 08:41:21 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WK9S0-0000B6-JW; Sun, 02 Mar 2014 11:41:16 -0500 Date: Sun, 2 Mar 2014 11:41:16 -0500 From: John Cowan To: Tim Bray Message-ID: <20140302164116.GD20855@mercury.ccil.org> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/cWNy1V6MRJ7zjjNSVpHUnC0SzIk Cc: Mark Nottingham , Paul Hoffman , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:41:23 -0000 Tim Bray scripsit: > Actually, quite sensible on the surface, aside from allowing > +/-Infinity. I was thinking just the opposite; that's one of the few advantages of JSON5. The rest is nothing but surface syntactic variation, and the only time that helps is when you're writing JSON by hand. (Comments can be handled using conventional object keys.) Paul Hoffman scripsit: > This appears to only be meant to work in a Javascript program, > yes? Otherwise, what the heck does "Object keys can be unquoted if > they're valid identifiers" mean? It means just what it says: that you can omit the quotes around a JSON5 key if it happens to also be a valid JavaScript identifier. The only reason this isn't already so is that the inventor of JSON didn't want to burden the definition of JSON with the list of 57 JavaScript reserved words (as of ES3) that can't be identifiers. In ES5 this isn't a problem any more, but there's a lot of legacy ES3. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan From nobody Sun Mar 2 12:34:21 2014 Return-Path: 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 AB7C81A0AB8 for ; Sun, 2 Mar 2014 12:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 qYRhCs_19rcp for ; Sun, 2 Mar 2014 12:34:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC701A0AAD for ; Sun, 2 Mar 2014 12:34:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A7DEB7FC2CB; Sun, 2 Mar 2014 12:34:13 -0800 (PST) To: tbray@textuality.com, barryleiba@computer.org, presnick@qti.qualcomm.com, mamille2@cisco.com, paul.hoffman@vpnc.org From: RFC Errata System Message-Id: <20140302203413.A7DEB7FC2CB@rfc-editor.org> Date: Sun, 2 Mar 2014 12:34:13 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/q6Ie_CzVYsvzWKV3fvXpSs7ci_w Cc: rfc-editor@rfc-editor.org, rfc7158@schmorp.de, json@ietf.org Subject: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 20:34:18 -0000 The following errata report has been submitted for RFC7158, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7158&eid=3907 -------------------------------------- Type: Technical Reported by: Marc Lehmann Section: 1.3, 2.0, 3. Original Text ------------- This document's goal is to apply the errata, remove inconsistencies with other specifications of JSON, and highlight practices that can lead to interoperability problems. A JSON value MUST be an object, array, number, or string, or one of the following three literal names: Corrected Text -------------- Notes ----- Since RFC7158 breaks compatibility with the specifications, this should be duly noted. The original specification (both in RFC4627 and on www.json.org, I know of no other JSON "specifications") specify JSON as a self-delimited format, that is, each JSON text can be parsed without extra delimiters or length wrapping, and some network protocols came to rely on this by asking for back-to-back JSON texts. RFC7158 changes this, so protocols that formerly consumed JSON texts without any extra wrapping are no longer compliant to this new specification. These protocols are now in violation of RFC7158, and they can't be fixed in a backwards compatible way. This introduces a big incompatibility between RFC7158 implementations and older ones, and this is not at all reflected in the introduction nor, as far as I could see, anywhere else in the new rfc. Thus it is likely that this is a specification error - the new RFC should either warn that the new RFC is not compatible with the existign specifications, or be fixed to be compatible. I think changing JSON in an incompatible way at this stage would be an extremely bad idea. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7158 (draft-ietf-json-rfc4627bis-10) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : March 2014 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Mar 2 12:46:55 2014 Return-Path: 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 418121A0ADC for ; Sun, 2 Mar 2014 12:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 tUdm4DHs-no2 for ; Sun, 2 Mar 2014 12:46:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id A32101A0AD3 for ; Sun, 2 Mar 2014 12:46:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 11C6D7FC2CB; Sun, 2 Mar 2014 12:46:50 -0800 (PST) To: tbray@textuality.com, barryleiba@computer.org, presnick@qti.qualcomm.com, mamille2@cisco.com, paul.hoffman@vpnc.org From: RFC Errata System Message-Id: <20140302204650.11C6D7FC2CB@rfc-editor.org> Date: Sun, 2 Mar 2014 12:46:50 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/v9TBotSR_7ocVgW60oOKgbud0do Cc: rfc-editor@rfc-editor.org, rfc7158@schmorp.de, json@ietf.org Subject: [Json] [Technical Errata Reported] RFC7158 (3908) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 20:46:54 -0000 The following errata report has been submitted for RFC7158, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7158&eid=3908 -------------------------------------- Type: Technical Reported by: Marc Lehmann Section: Security con Original Text ------------- Corrected Text -------------- Notes ----- This is a followup to my previous errata. I just wanted to note that this should also be discusssed in the security considerations. Consider a protocol that would allow back-to-back json messages. For example, a banking protocol that accepted currency amounts. A RFC7158 encoder could now encode the two separate amounts "1" and "999" and end up with the single amount "1999", which couldn't happen with the original JSON specification. Since this affects existing protocols and could potentially result in serious misinterpretations, I think noting this in the security considerations sections would be prudent. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7158 (draft-ietf-json-rfc4627bis-10) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : March 2014 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Mar 2 13:31:51 2014 Return-Path: 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 1F2D31A0B1A for ; Sun, 2 Mar 2014 13:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 XBLIXOZNF6mj for ; Sun, 2 Mar 2014 13:31:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B8F451A0B18 for ; Sun, 2 Mar 2014 13:31:45 -0800 (PST) Received: from netb ([47.65.21.24]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMGWH-1WIsX93Mr7-0083iV; Sun, 02 Mar 2014 22:31:31 +0100 From: Bjoern Hoehrmann To: RFC Errata System Date: Sun, 02 Mar 2014 22:31:07 +0100 Message-ID: References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> In-Reply-To: <20140302203413.A7DEB7FC2CB@rfc-editor.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:asSL8X4wvEVIgyc/+/ww/NurUYLL1RsUZttsHI5WPxsrBbwz1dI 2XzikAqJpcpxqdz7i6yE4x/jhJDynUG5d4c3Cb+DQUEtylZzlQyEZFbfkmZOd7w9b3uLNUW NYa1SpdG2E+jRFcmZqaTnchi3L7bCi40Gza51Fz9OYLj4wn6JzJPETAuw1GztiTy2jix/vC h1lIiqfOLoeLMt2visu6Q== Archived-At: http://mailarchive.ietf.org/arch/msg/json/p1iqo6tMF1ZnpbJhSBzMqbe9plM Cc: presnick@qti.qualcomm.com, paul.hoffman@vpnc.org, json@ietf.org, tbray@textuality.com, mamille2@cisco.com, barryleiba@computer.org, rfc7158@schmorp.de, rfc-editor@rfc-editor.org Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 21:31:48 -0000 * RFC Errata System wrote: >Since RFC7158 breaks compatibility with the specifications, this should be >duly noted. It is in Appendix A., "Changes from RFC 4627": o Changed the definition of "JSON text" so that it can be any JSON value, removing the constraint that it be an object or array. Failing to note this in the Introduction is not ideal, but the errata system is not a good place to record that (holding it for document up- date probably does not make sense, if and when the document does get updated, this particular issue will not require prominent notice). -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sun Mar 2 13:58:53 2014 Return-Path: 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 0D34F1A0B38 for ; Sun, 2 Mar 2014 13:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 08EdSBgpwdqK for ; Sun, 2 Mar 2014 13:58:49 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D24F71A0B34 for ; Sun, 2 Mar 2014 13:58:48 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so4108647lbi.16 for ; Sun, 02 Mar 2014 13:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1b0MNP19Y0gEpg43dXQxdERejq5ZV2Ip/LjmoeS2GgM=; b=BUjDA/80LUjlTKziYfMM+w85DzTTHJnhlEsKyI6xE7cGDJjewoQqduAl2veWJ5e5Sx uREIihk8qBvGOVadEylJLiI7ezJimJSiV8YmOqy03Ftz/3XcTcwFKDnesmnlVjtQ8/ry shTBVdeU4ZwLuPHzrsZ1LTxsj0T6UlenY6UGETVsoHEZPmiDtvJhgk9Ny2+zf8HvSd8J 6equFsVb9yHzDE5fT1JaFOjUHybNFF3Y2o9mRCu2fyvmerksMVNV/4qw1Wc/5vJUwjnC NMupgNp9O2V+hKtMXdznPscM2KqwqmSNCnAyBeV0Op0Gjt/Ld7wexlzDgAfJhSuOq12k O7Yw== MIME-Version: 1.0 X-Received: by 10.112.164.5 with SMTP id ym5mr103323lbb.48.1393797525464; Sun, 02 Mar 2014 13:58:45 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sun, 2 Mar 2014 13:58:45 -0800 (PST) In-Reply-To: <20140302164116.GD20855@mercury.ccil.org> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> <20140302164116.GD20855@mercury.ccil.org> Date: Sun, 2 Mar 2014 21:58:45 +0000 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c2681864ea5504f3a6c68b Archived-At: http://mailarchive.ietf.org/arch/msg/json/RKgqBcTpslkLIIkYcDFKbHXdHZ0 Cc: Mark Nottingham , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 21:58:51 -0000 --001a11c2681864ea5504f3a6c68b Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 2, 2014 at 4:41 PM, John Cowan wrote: > Tim Bray scripsit: > > > Actually, quite sensible on the surface, aside from allowing > > +/-Infinity. > > I was thinking just the opposite; that's one of the few advantages > of JSON5. The rest is nothing but surface syntactic variation, and the > only time that helps is when you're writing JSON by hand. (Comments can > be handled using conventional object keys.) > > Paul Hoffman scripsit: > > > This appears to only be meant to work in a Javascript program, > > yes? Otherwise, what the heck does "Object keys can be unquoted if > > they're valid identifiers" mean? > > It means just what it says: that you can omit the quotes around a JSON5 > key if it happens to also be a valid JavaScript identifier. The only > reason this isn't already so is that the inventor of JSON didn't want > to burden the definition of JSON with the list of 57 JavaScript reserved > words (as of ES3) that can't be identifiers. > > In ES5 this isn't a problem any more, but there's a lot of legacy ES3. > Since at this point we are far beyond JavaScript, this does not concern me at all. For purposes of IETF specs it is probably imprudent to use any reserved word from SQL, Java, C# or C as a field name. -- Website: http://hallambaker.com/ --001a11c2681864ea5504f3a6c68b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 2, 2014 at 4:41 PM, John Cowan <cowan@mercury.cci= l.org> wrote:
Tim Bray scripsit:

> Actually, quite sensible on the surface, aside from allowing
> +/-Infinity.

I was thinking just the opposite; that's one of the few advantage= s
of JSON5. =A0The rest is nothing but surface syntactic variation, and the only time that helps is when you're writing JSON by hand. =A0(Comments = can
be handled using conventional object keys.)

Paul Hoffman scripsit:

> This appears to only be meant to work in a Javascript program,
> yes? Otherwise, what the heck does "Object keys can be unquoted i= f
> they're valid identifiers" mean?

It means just what it says: that you can omit the quotes around a JSO= N5
key if it happens to also be a valid JavaScript identifier. =A0The only
reason this isn't already so is that the inventor of JSON didn't wa= nt
to burden the definition of JSON with the list of 57 JavaScript reserved words (as of ES3) that can't be identifiers.

In ES5 this isn't a problem any more, but there's a lot of legacy E= S3.

Since at this point we are far beyo= nd JavaScript, this does not concern me at all.=A0

For purposes of IETF specs it is probably imprudent to use any reserved wor= d from SQL, Java, C# or C as a field name.
=A0
--
Website: http://hallamba= ker.com/
--001a11c2681864ea5504f3a6c68b-- From nobody Sun Mar 2 14:30:30 2014 Return-Path: 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 942851A0B17 for ; Sun, 2 Mar 2014 14:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 jcqC4ixlK6at for ; Sun, 2 Mar 2014 14:30:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 530BE1A096D for ; Sun, 2 Mar 2014 14:30:25 -0800 (PST) Received: from netb ([89.204.139.118]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lu3J4-1XKHti1ynW-011RN9; Sun, 02 Mar 2014 23:30:14 +0100 From: Bjoern Hoehrmann To: Marc Lehmann Date: Sun, 02 Mar 2014 23:29:49 +0100 Message-ID: <82b7h9l5djqeali7cr36uadlicg1183bsv@hive.bjoern.hoehrmann.de> References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> <20140302220629.GA4246@schmorp.de> In-Reply-To: <20140302220629.GA4246@schmorp.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:d1iwhwudri8FvpHMqJbxJCx3QzyjSjjd/X1bCL+2AGHtuhWqqKB cZ/k5FtWT+WxiI0n2qRaWF9GoQAV2HL65Xa8M4fh5ZU69rOqG1v25mhelgw8KHkTdw6okUV DswzQarLph0gH1gaxZATCUdwmdO1/QEPHLREQKa2wi/c0CvrJiSry5M+h7JJEYOrQYGLUTe GttQpdgHScfBiB42Vh7KA== Archived-At: http://mailarchive.ietf.org/arch/msg/json/z-VXSY3PDKFZcxqeeeXShuO4Fm8 Cc: presnick@qti.qualcomm.com, paul.hoffman@vpnc.org, json@ietf.org, tbray@textuality.com, mamille2@cisco.com, barryleiba@computer.org, rfc7158@schmorp.de, RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 22:30:27 -0000 * Marc Lehmann wrote: >Just for additional info, I followed the instructions given in the >RFC to give feedback (the page linked to by the rfc for feedback, >http://www.rfc-editor.org/info/rfc7158, didn't seem to list any other >options to give feedback than the errata system). > >It was merely my intent to give feedback on this issue (which is a big >issue for me as an implementerm not necessarily an errata). The document has gone through a series of drafts with various calls for review and many comments and has now been published as RFC, meaning it's impossible to change it; it can only be replaced through the heavyweight process of going through the IETF consensus process again. RFC Errata https://www.ietf.org/iesg/statement/errata-processing.html allow us to track some information about errors in the document, but people who miss this change from RFC 4627 in their use of the document are not likely to consult the errata pages. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sun Mar 2 17:13:24 2014 Return-Path: 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 EA2491A0B63 for ; Sun, 2 Mar 2014 17:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 kXcSwXN2ihGR for ; Sun, 2 Mar 2014 17:13:19 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 254D61A0ACA for ; Sun, 2 Mar 2014 17:13:19 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WKHRS-0000Kn-0O; Sun, 02 Mar 2014 20:13:14 -0500 Date: Sun, 2 Mar 2014 20:13:13 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140303011313.GA394@mercury.ccil.org> References: <7FE4234C-25BC-4AB9-B0DD-9E1641DB9BE0@mnot.net> <4CA4E293-3252-4082-A40C-DE867D732209@vpnc.org> <20140302164116.GD20855@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/Qj5yMNHSNkhTvajgRVky5LjlTs4 Cc: Mark Nottingham , Tim Bray , Paul Hoffman , JSON WG Subject: Re: [Json] Meanwhile, out there... X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 01:13:22 -0000 Phillip Hallam-Baker scripsit: > Since at this point we are far beyond JavaScript, this does not concern > me at all. Since JSON is, always has been, and I trust always will be a subset of ECMAScript 3, I don't know what that even means. -- John Cowan http://www.ccil.org/~cowan One time I called in to the central system and started working on a big thick 'sed' and 'awk' heavy duty data bashing script. One of the geologists came by, looked over my shoulder and said 'Oh, that happens to me too. Try hanging up and phoning in again.' --Beverly Erlebacher From nobody Mon Mar 3 02:55:22 2014 Return-Path: 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 3C0491A0E74; Mon, 3 Mar 2014 02:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 GsQMerTLnWw7; Mon, 3 Mar 2014 02:55:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 69A7B1A0E3F; Mon, 3 Mar 2014 02:55:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4FCCC7FC399; Mon, 3 Mar 2014 02:55:08 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140303105509.4FCCC7FC399@rfc-editor.org> Date: Mon, 3 Mar 2014 02:55:08 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/AlhegQg2KYcPZejdleLkk-OtAzU Cc: drafts-update-ref@iana.org, json@ietf.org, rfc-editor@rfc-editor.org Subject: [Json] RFC 7159 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:55:17 -0000 A new Request for Comments is now available in online RFC libraries. Please note that this document is a republication of RFC 7158 in order to correct the publication year. RFC 7159 Title: The JavaScript Object Notation (JSON) Data Interchange Format Author: T. Bray, Ed. Status: Standards Track Stream: IETF Date: March 2014 Mailbox: tbray@textuality.com Pages: 16 Characters: 27451 Obsoletes: RFC 4627, RFC 7158 I-D Tag: draft-ietf-json-rfc4627bis-rfc7159bis.txt URL: http://www.rfc-editor.org/rfc/rfc7159.txt 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 removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document is a product of the JavaScript Object Notation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Mar 3 04:10:09 2014 Return-Path: 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 59C151A0F14 for ; Mon, 3 Mar 2014 03:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 TxdMljPC1D15 for ; Mon, 3 Mar 2014 03:08:51 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0601A0F0D for ; Mon, 3 Mar 2014 03:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393844928; x=1425380928; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vDhbZiiDxYP9nof103tlZ5b2vOgPogpdqsWAdqFFD6s=; b=Q8Cjj6MI2kOEtJ1ZAxmO1Yk8eZW3T5uAPMz6JjLm3SJpuFGz1g/Ms9ud eeVMmIhWzVkxf7Z3ldcHKGGd7ZBJ01QL0/TeHBDmGsgQOowzfRiyuD0tF pxOAKz7YUwpeaKLeFMyl5p/l0XutB8niot7zeWtHONjPdTJASb7mbmYEY 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7365"; a="60106221" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 03 Mar 2014 03:08:48 -0800 X-IronPort-AV: E=Sophos;i="4.97,577,1389772800"; d="scan'208";a="639259944" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Mar 2014 03:08:48 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 03:08:47 -0800 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Mar 2014 03:08:47 -0800 Message-ID: <53146287.1030505@qti.qualcomm.com> Date: Mon, 3 Mar 2014 11:07:51 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ladislav Lhotka References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> <20140302220629.GA4246@schmorp.de> <82b7h9l5djqeali7cr36uadlicg1183bsv@hive.bjoern.hoehrmann.de> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/json/BQUd_z1-9AOoBu1LqMAzwZqj3Cw X-Mailman-Approved-At: Mon, 03 Mar 2014 04:10:09 -0800 Cc: Bjoern Hoehrmann , paul.hoffman@vpnc.org, json@ietf.org, Tim Bray , Marc Lehmann , mamille2@cisco.com, barryleiba@computer.org, rfc7158@schmorp.de, RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:08:53 -0000 On 3/3/14 11:03 AM, Ladislav Lhotka wrote: > Hmm, according to the RFC 7158 text, the month of publication appears to be March 2013. > Yes, we noticed that. The RFC Editor is going to publish a corrected version. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 4 01:01:27 2014 Return-Path: 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 8E45C1A0426 for ; Tue, 4 Mar 2014 01:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 XHVH9Bz0Hp6A for ; Tue, 4 Mar 2014 01:01:18 -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 7478A1A0418 for ; Tue, 4 Mar 2014 01:01:18 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2491DFk025108 for ; Tue, 4 Mar 2014 18:01:13 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1108_2b95_899c2204_a37b_11e3_ba19_001e6722eec2; Tue, 04 Mar 2014 18:01:12 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D3693BF4D0 for ; Tue, 4 Mar 2014 18:01:12 +0900 (JST) Message-ID: <53159651.10601@it.aoyama.ac.jp> Date: Tue, 04 Mar 2014 18:01:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: json@ietf.org References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> <20140302220629.GA4246@schmorp.de> <82b7h9l5djqeali7cr36uadlicg1183bsv@hive.bjoern.hoehrmann.de> <53146287.1030505@qti.qualcomm.com> In-Reply-To: <53146287.1030505@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/zXBi1rWC3ULuu7zN7uXfrA1jqiQ Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:01:26 -0000 I saw the announcement for the new RFC (7159). For the record, although=20 I understand the basic idea behind the policy that RFCs are never=20 changed, I think it would have been much wiser to just make the change=20 in place. In the long run (in this case, my guess would be that this means more=20 than one week), the implications would have been much smaller than=20 having to live with two virtually identical RFCs with numbers differing=20 only by 1 for a long time. Regards, Martin. P.S.: Needless to say that the best would have to be to avoid the=20 mistake in the first place. P.P.S.: W3C has a policy for very limited in-place fixes (http://www.w3.org/2003/01/republishing/), but it doesn't include this ca= se. On 2014/03/03 20:07, Pete Resnick wrote: > On 3/3/14 11:03 AM, Ladislav Lhotka wrote: >> Hmm, according to the RFC 7158 text, the month of publication appears >> to be =E2=80=9CMarch 2013=E2=80=9D. > > Yes, we noticed that. The RFC Editor is going to publish a corrected > version. > > pr > From nobody Tue Mar 4 02:29:43 2014 Return-Path: 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 9A61E1A042E for ; Tue, 4 Mar 2014 02:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 tE6FIJnedlGv for ; Tue, 4 Mar 2014 02:29:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 990D21A03AC for ; Tue, 4 Mar 2014 02:29:41 -0800 (PST) Received: from dhcp-bc61.meeting.ietf.org (dhcp-bc61.meeting.ietf.org [31.133.188.97]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s24ATU34026076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 03:29:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <53159651.10601@it.aoyama.ac.jp> Date: Tue, 4 Mar 2014 10:29:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> <20140302220629.GA4246@schmorp.de> <82b7h9l5djqeali7cr36uadlicg1183bsv@hive.bjoern.hoehrmann.de> <53146287.1030505@qti.qualcomm.com> <53159651.10601@it.aoyama.ac.jp> To: Martin Duerst X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/qev54re_O-97zGoQY-PeIDxZIIo Cc: json@ietf.org Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:29:42 -0000 On Mar 4, 2014, at 9:01 AM, Martin J. D=FCrst = wrote: > I saw the announcement for the new RFC (7159). For the record, = although I understand the basic idea behind the policy that RFCs are = never changed, I think it would have been much wiser to just make the = change in place. This comment is relevant to rfc-interest@rfc-editor.org, not here. This = WG doesn't make rules for how RFCs are published. --Paul Hoffman= From nobody Tue Mar 4 06:44:03 2014 Return-Path: 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 983EF1A0152 for ; Tue, 4 Mar 2014 06:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 zHXP0qlF-K0c for ; Tue, 4 Mar 2014 06:43:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0804A1A029C for ; Tue, 4 Mar 2014 06:43:53 -0800 (PST) Received: from netb ([47.65.29.77]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6P5z-1X9XLy0xKN-00yRZI for ; Tue, 04 Mar 2014 15:43:49 +0100 From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Tue, 04 Mar 2014 15:43:50 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:SGJ3k6gzBtTDBkJ3hCv0DPBeZ8PPS7mmT+TkMVXtJ2ujAZy67WN OZBgXkAKhadwn+w/JfP/yr4GW2CaZ4kX7qT05xWxiwfLd5MJkaUCB/MbU6gQ4GsSyNu+xmm 3eDT6KCBnclZ4t8VhdUHv65XVpgXImlbDyIes5vJ8yo75E27w7Fo/TmCumCVSr3e4T3C3a1 M8dBaIj04fg35/HAj0XKg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/5OvbJIZPELQtA-NZD8plGezratA Cc: rfc7158@schmorp.de, json@ietf.org Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:43:58 -0000 * Paul E. Jones wrote: >I've not been following the list closely, as I thought this was more of >an editorial exercise than anything else. This is definitely more than >editorial. This could definitely break things and the commenter is >right that there are instances where there could be misinterpretation. > >Why was it decided to change this: > > JSON-text = object / array > >to > > JSON-text = ws value ws > >Was there some misunderstanding of what 4627 said? http://www.ietf.org/mail-archive/web/json/current/msg02040.html is the decision, you can find relevant discussion nearby; most arguments I've seen revolved around various notions of consistency. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Tue Mar 4 06:51:45 2014 Return-Path: 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 EB9E51A011C for ; Tue, 4 Mar 2014 06:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 Z6Y-uae19ep7 for ; Tue, 4 Mar 2014 06:17:38 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4C1A0118 for ; Tue, 4 Mar 2014 06:17:38 -0800 (PST) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s24EHOgn023398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 09:17:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1393942646; bh=OGHtlqd0nXcznnVcMz96rNZnuHQqemWOdWPAc4pZfIc=; h=From:To:Subject:Cc:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=oZDMTH7u5yoGWu7TioG/lBLkbHiagLx15xOD/gF+Z7Uu5WlSPZBA64KCCb8u0gpKq nqBbLZ80fpqeBwmtWkXjllRduWES34m6how6OfBNH8JuXp3eKLWQxetSUDcq9A9ej5 pQLk22P/yeMFusKiacu/BpUhsu0+9+/IP2AJVAQw= From: "Paul E. Jones" To: "Bjoern Hoehrmann" , "RFC Errata System" Date: Tue, 04 Mar 2014 14:17:37 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.19861.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Zu5ArUJOt0RCfOsXLZBwBrIBom8 X-Mailman-Approved-At: Tue, 04 Mar 2014 06:51:40 -0800 Cc: presnick@qti.qualcomm.com, paul.hoffman@vpnc.org, json@ietf.org, tbray@textuality.com, mamille2@cisco.com, barryleiba@computer.org, rfc7158@schmorp.de, rfc-editor@rfc-editor.org Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:17:41 -0000 I've not been following the list closely, as I thought this was more of=20 an editorial exercise than anything else. This is definitely more than=20 editorial. This could definitely break things and the commenter is=20 right that there are instances where there could be misinterpretation. Why was it decided to change this: JSON-text =3D object / array to JSON-text =3D ws value ws Was there some misunderstanding of what 4627 said? Paul ------ Original Message ------ From: "Bjoern Hoehrmann" To: "RFC Errata System" Cc: presnick@qti.qualcomm.com; paul.hoffman@vpnc.org; json@ietf.org;=20 tbray@textuality.com; mamille2@cisco.com; barryleiba@computer.org;=20 rfc7158@schmorp.de; rfc-editor@rfc-editor.org Sent: 3/2/2014 4:31:07 PM Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >* RFC Errata System wrote: >>Since RFC7158 breaks compatibility with the specifications, this=20 >>should be >>duly noted. > >It is in Appendix A., "Changes from RFC 4627": > > o Changed the definition of "JSON text" so that it can be any JSON > value, removing the constraint that it be an object or array. > >Failing to note this in the Introduction is not ideal, but the errata >system is not a good place to record that (holding it for document up- >date probably does not make sense, if and when the document does get >updated, this particular issue will not require prominent notice). >-- >Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7=20 >http://bjoern.hoehrmann.de >Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7=20 >http://www.bjoernsworld.de >25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.we= bsitedev.de/ > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json From nobody Tue Mar 4 07:18:48 2014 Return-Path: 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 0720C1A01DA for ; Tue, 4 Mar 2014 07:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 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_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 LK6RZIsGoANq for ; Tue, 4 Mar 2014 07:18:42 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5F1A0179 for ; Tue, 4 Mar 2014 07:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393946319; x=1425482319; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mZPJZEYvs6G7K9a0U+btLW6DkO8MFn9C8qmB1UXc70Q=; b=UDiiiR7yllN65IVFaySUHuMDbrvTfesml9CqL9G5GSEEiOp7YhA72rkH 1q67Yh3ptP7z/5QPcxM3V3/Czj/oy8YBAwpNdVU8lR7pObyOGW++J4H2+ ypYaLRwviCPjJ8Vo5E7lgm52Ey2y40YyroSeBHQxjNq4LKofR+Xj8D5u9 g=; X-IronPort-AV: E=McAfee;i="5400,1158,7366"; a="109260070" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 04 Mar 2014 07:18:39 -0800 X-IronPort-AV: E=Sophos;i="4.97,585,1389772800"; d="scan'208";a="28003020" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 07:18:39 -0800 Received: from dhcp-ac59.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 07:18:37 -0800 Message-ID: <5315EEC9.3070509@qti.qualcomm.com> Date: Tue, 4 Mar 2014 15:18:33 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> In-Reply-To: <20140302203413.A7DEB7FC2CB@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/json/JEUk1A5hgCijTOTHUStQxdt211E Cc: json@ietf.org, RFC Editor Subject: [Json] On the errata (Was: [Technical Errata Reported] RFC7158 (3907) (3908)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:18:45 -0000 Hi Marc, As you may have surmised from some of the discussion, the note on the RFC Editor page is misleading regarding where to report things, and we (the IETF leadership) are working with the RFC Editor to update their page to make that clearer. What you have reported is actually input to the JSON Working Group, which the working group should be discussing on the WG mailing list, not errata, which are really for simple textual corrections to published RFCs. Certainly your input is appreciated, and it doesn't matter that it landed in the wrong place through no fault of your own. So here's what I would suggest: Your comments have been Cc'ed to the JSON WG list from the errata system. I'll leave it to the chairs (Paul and Matt) to say whether they want you to resend them directly to the WG mailing list with a new Subject so they can track it, or whether the Cc of the errata messages will suffice. Either way, please remove the RFC Editor and the Area Directors (Barry and I) from the Cc list if you continue the discussion of the issue. Meanwhile, I'll have the RFC Editor remove these entries from the Errata system; there's no need to keep the RFC Editor in the loop on these topics. Again, I appreciate your input, and I hope we can get the RFC Editor pages updated so it's clear where to send different kinds of comments. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 4 08:43:32 2014 Return-Path: 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 D56CB1A01DC for ; Tue, 4 Mar 2014 08:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 DQOiR6z43rkr for ; Tue, 4 Mar 2014 08:43:26 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E022E1A0191 for ; Tue, 4 Mar 2014 08:43:25 -0800 (PST) Received: from dhcp-bc61.meeting.ietf.org (dhcp-bc61.meeting.ietf.org [31.133.188.97]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s24GhIkE038598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 09:43:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5315EEC9.3070509@qti.qualcomm.com> Date: Tue, 4 Mar 2014 16:43:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <543A629C-20B3-47F5-A99D-BE96B175C33F@vpnc.org> References: <20140302203413.A7DEB7FC2CB@rfc-editor.org> <5315EEC9.3070509@qti.qualcomm.com> To: rfc7158@schmorp.de X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/cskuPh7vO0ilybCEXURpegcD1nk Cc: JSON WG Subject: Re: [Json] On the errata (Was: [Technical Errata Reported] RFC7158 (3907) (3908)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:43:27 -0000 On Mar 4, 2014, at 3:18 PM, Pete Resnick = wrote: > Your comments have been Cc'ed to the JSON WG list from the errata = system. I'll leave it to the chairs (Paul and Matt) to say whether they = want you to resend them directly to the WG mailing list with a new = Subject so they can track it, or whether the Cc of the errata messages = will suffice. The former. That is, please send a message to the list with a relevant = Subject: line. --Paul Hoffman= From nobody Tue Mar 4 09:12:08 2014 Return-Path: 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 304C51A029C for ; Tue, 4 Mar 2014 09:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 gtqPZiDLsFS7 for ; Tue, 4 Mar 2014 09:12:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 31D901A0289 for ; Tue, 4 Mar 2014 09:12:03 -0800 (PST) Received: from [31.133.165.4] ([31.133.165.4]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LvPgd-1XKRna3EW3-010afI for ; Tue, 04 Mar 2014 18:11:57 +0100 Message-ID: <5316095B.5050201@gmx.de> Date: Tue, 04 Mar 2014 18:11:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:E55h6mq08qDdxtRP1WzWmI2qGkR8ICgrXwwxm4faTQDdhgh4fQt id4T3LoJjLQ5tVBRYeHedo6gJgxV1hXQegQb2B41POTnDRvd2By5g2T5mdxLZxvELr2xEbs QJKkgy3FlDyCv+4nyXY8FBvhH1wtCMD/QMdUeCl2fpzyhI/EG3qP40TtdQY87bPSaH+YVit Zl1eEJMQ5QYtbQ+hA86/Q== Archived-At: http://mailarchive.ietf.org/arch/msg/json/hvy6iZ6GrFvlHw8k3z3Jyrrc0pA Subject: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:12:07 -0000 Hm. [Err3607] RFC Errata, Errata ID 3607, RFC 3607, . [Err607] RFC Errata, Errata ID 607, RFC 607, . Really?? From nobody Tue Mar 4 09:27:23 2014 Return-Path: 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 1EB951A0244 for ; Tue, 4 Mar 2014 09:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 eH2C9yoeBHqK for ; Tue, 4 Mar 2014 09:27:18 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49E6E1A0232 for ; Tue, 4 Mar 2014 09:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393954035; x=1425490035; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=N+1ANKJgOV/yEgWzKDP1dJfKgy0cQ4etPw5by4MvoOw=; b=sewYRv+YCnHvVBTBu1RRFdf3JfuaeRwlEePVKdfDPZK7bFVVa9zsBjqK qhHH+zoHHOZ9qDralKRgu4FJdT5glx30jD7jIZYbppTdapsCvmT7wzxIf IVKZQNBqA2+S4jn2cmyCx+F0N6wHZ76UjodmsVt4IJ3zz2BIzyxIPjUDF o=; X-IronPort-AV: E=McAfee;i="5400,1158,7367"; a="60078466" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 04 Mar 2014 09:27:15 -0800 X-IronPort-AV: E=Sophos;i="4.97,585,1389772800"; d="scan'208";a="27677865" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 09:27:14 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc13.na.qualcomm.com (172.30.48.20) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 09:27:14 -0800 Received: from dhcp-ac59.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 09:27:12 -0800 Message-ID: <53160CEE.6010405@qti.qualcomm.com> Date: Tue, 4 Mar 2014 17:27:10 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <5316095B.5050201@gmx.de> In-Reply-To: <5316095B.5050201@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/json/mnq3s1C3mJYMIEPIt_bB2abbG30 Cc: "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:27:21 -0000 On 3/4/14 5:11 PM, Julian Reschke wrote: > Hm. > > [Err3607] RFC Errata, Errata ID 3607, RFC 3607, > . > > [Err607] RFC Errata, Errata ID 607, RFC 607, > . > > Really?? These two errata are on RFC 4627. Erratum 3607 is marked as "Held For Document Update" and 607 is marked as "Verified". What's the question? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 4 09:32:12 2014 Return-Path: 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 3B3BF1A01B0 for ; Tue, 4 Mar 2014 09:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 jvTqcBJX5x8C for ; Tue, 4 Mar 2014 09:32:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9761A00F6 for ; Tue, 4 Mar 2014 09:32:02 -0800 (PST) Received: from netb ([47.68.212.170]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MQzoI-1WlvTJ3eG6-00UL4B; Tue, 04 Mar 2014 18:31:56 +0100 From: Bjoern Hoehrmann To: Pete Resnick Date: Tue, 04 Mar 2014 18:31:56 +0100 Message-ID: References: <5316095B.5050201@gmx.de> <53160CEE.6010405@qti.qualcomm.com> In-Reply-To: <53160CEE.6010405@qti.qualcomm.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:jReJ3rOWclqUPcUEFoSMUqn4sAI0w0bDtn8884aIbD0pI+A3FEX Yztlh1euhxALUMWSHo+T5zKIwzOO2w571WksDDNNXCc7buU/lQr8g2f7nfKFyS2Ygat9/ij W161BrYCtwcqUhRvt/8+PxeriSGJ1fu+7EiZxpFxJYtYqUwYb3+9+aew+/0JLZXLAguHnN5 G4VP0yYCHWo7g/ByCfNnQ== Archived-At: http://mailarchive.ietf.org/arch/msg/json/Le5_owcUQYt5hV2W-A15nld5A6A Cc: Julian Reschke , "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:32:10 -0000 * Pete Resnick wrote: >On 3/4/14 5:11 PM, Julian Reschke wrote: >> Hm. >> >> [Err3607] RFC Errata, Errata ID 3607, RFC 3607, >> . >> >> [Err607] RFC Errata, Errata ID 607, RFC 607, >> . >> >> Really?? > > > > >These two errata are on RFC 4627. Erratum 3607 is marked as "Held For >Document Update" and 607 is marked as "Verified". > >What's the question? Read the reference text more carefully. RFC 3607 is "Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool" and RFC 607 is "Comments on the File Transfer Protocol". -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Tue Mar 4 09:36:11 2014 Return-Path: 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 0F1C91A021C for ; Tue, 4 Mar 2014 09:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 PkBSstzkP6f3 for ; Tue, 4 Mar 2014 09:36:04 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id DD4421A01FE for ; Tue, 4 Mar 2014 09:36:03 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id lc6so449571vcb.10 for ; Tue, 04 Mar 2014 09:36:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YpGrUjN9xywWn+aRZnEB9l1znVLj6c6PAl0OrFM+7PQ=; b=IixZi/HQyJnBIl2H4JfKFjHxAON9m8VqqfaDlJl4imQ+JNaqMI/hR0OweH+u0AyKZf tQ8zaTO+NMwhBlpAh+ISFzlVsUpIKVySIvQweNcVmx/Rl4MQXtRX9QLWLvxkBshbxwNX bEev1w9w2iIN3vyaXgoSjfTCgCiHrqkCUwmTAt2llim/O5WXEyO0Xyr5Zo7oXbEdEOkc 46HR+NRzabgi2koDAwRzpzbl24vghmdLSpnnqpfKCTevyRaYu2AouwCk/6ybI+3SBcPI tfHmfNZ99y5cDApewGpo60nMNdagDprvmIew2z5uOSyuwl2qQzDAsa2lJX3g9BgemW5T 4Isw== X-Gm-Message-State: ALoCoQn7Lfk3Sq2YNuyIwWXIKg6wRWV8gtlNIzlxq2ro02c1v5PDOlbAmdog/hDOlqpp9sNavxFb MIME-Version: 1.0 X-Received: by 10.220.103.141 with SMTP id k13mr418660vco.25.1393954071139; Tue, 04 Mar 2014 09:27:51 -0800 (PST) Received: by 10.220.98.73 with HTTP; Tue, 4 Mar 2014 09:27:51 -0800 (PST) X-Originating-IP: [130.129.159.69] In-Reply-To: References: Date: Tue, 4 Mar 2014 09:27:51 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=047d7b342d303e97c804f3cb39a6 Archived-At: http://mailarchive.ietf.org/arch/msg/json/K5FiG09CqC71N07d4WNOxiUp8O0 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , Matthew Miller , Barry Leiba , rfc7158@schmorp.de, RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:36:08 -0000 --047d7b342d303e97c804f3cb39a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On this issue, also please read the interoperability note in the paragraph before the new production. On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones wrote= : > I've not been following the list closely, as I thought this was more of a= n > editorial exercise than anything else. This is definitely more than > editorial. This could definitely break things and the commenter is right > that there are instances where there could be misinterpretation. > > Why was it decided to change this: > > JSON-text =3D object / array > > to > > JSON-text =3D ws value ws > > Was there some misunderstanding of what 4627 said? > > Paul > > > ------ Original Message ------ > From: "Bjoern Hoehrmann" > To: "RFC Errata System" > Cc: presnick@qti.qualcomm.com; paul.hoffman@vpnc.org; json@ietf.org; > tbray@textuality.com; mamille2@cisco.com; barryleiba@computer.org; > rfc7158@schmorp.de; rfc-editor@rfc-editor.org > Sent: 3/2/2014 4:31:07 PM > Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) > > * RFC Errata System wrote: >> >>> Since RFC7158 breaks compatibility with the specifications, this should >>> be >>> duly noted. >>> >> >> It is in Appendix A., "Changes from RFC 4627": >> >> o Changed the definition of "JSON text" so that it can be any JSON >> value, removing the constraint that it be an object or array. >> >> Failing to note this in the Introduction is not ideal, but the errata >> system is not a good place to record that (holding it for document up- >> date probably does not make sense, if and when the document does get >> updated, this particular issue will not require prominent notice). >> -- >> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http:/= /bjoern.hoehrmann.de >> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoer= nsworld.de >> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.= websitedev.de/ >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > --047d7b342d303e97c804f3cb39a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On this issue, also please read the interoperability note = in the paragraph before the new production.


On Tue, Mar 4, 2014 at 6:17 AM, Paul E.= Jones <paulej@packetizer.com> wrote:
I've not been following the list closely= , as I thought this was more of an editorial exercise than anything else. = =C2=A0This is definitely more than editorial. =C2=A0This could definitely b= reak things and the commenter is right that there are instances where there= could be misinterpretation.

Why was it decided to change this:

=C2=A0 =C2=A0 JSON-text =3D object / array

to

=C2=A0 =C2=A0 JSON-text =3D ws value ws

Was there some misunderstanding of what 4627 said?

Paul


------ Original Message ------
From: "Bjoern Hoehrmann" <derhoermi@gmx.net>
To: "RFC Errata System" <rfc-editor@rfc-editor.org>
Cc: presnick= @qti.qualcomm.com; paul.hoffman@vpnc.org; json@ietf.org; tbray@textuality.com; mamille2@cisco.com; barryleiba@computer.org; rfc7158@schmorp.de; rfc-editor@rfc-editor.= org
Sent: 3/2/2014 4:31:07 PM
Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)

* RFC Errata System wrote:
Since RFC7158 breaks compatibility with the specifications, this should be<= br> duly noted.

It is in Appendix A., "Changes from RFC 4627":

=C2=A0 =C2=A0o Changed the definition of "JSON text" so that it c= an be any JSON
=C2=A0 =C2=A0 =C2=A0 value, removing the constraint that it be an object or= array.

Failing to note this in the Introduction is not ideal, but the errata
system is not a good place to record that (holding it for document up-
date probably does not make sense, if and when the document does get
updated, this particular issue will not require prominent notice).
--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.= de
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7b342d303e97c804f3cb39a6-- From nobody Tue Mar 4 09:37:34 2014 Return-Path: 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 176401A01D9 for ; Tue, 4 Mar 2014 09:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 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_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 pXOGaR_I51bA for ; Tue, 4 Mar 2014 09:37:14 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C75B61A0227 for ; Tue, 4 Mar 2014 09:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1393954625; x=1425490625; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DjDerZEAf6RNMrshynsA11jEGt8V6hZx65TvHKu4O9o=; b=S/DeXE/AzS+2s1HpRTTOxnqwAu0kybb2L3VB16NiB06zJedq/92Xpl42 GpoTViWEYbrA7NovMTY9AyOfcTLB4EdbRra+FIdYcOPMRE7wUK3oR76KD 09F+SRaLyWziigzKtpnT8f67gtzcBMubdu83H9nuZtUiGPwxs1YH3X2dc A=; X-IronPort-AV: E=McAfee;i="5400,1158,7367"; a="109288206" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 04 Mar 2014 09:37:05 -0800 X-IronPort-AV: E=Sophos;i="4.97,586,1389772800"; d="scan'208";a="627337140" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2014 09:37:05 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 09:37:05 -0800 Received: from dhcp-ac59.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 09:37:04 -0800 Message-ID: <53160F3E.1000408@qti.qualcomm.com> Date: Tue, 4 Mar 2014 17:37:02 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <5316095B.5050201@gmx.de> <53160CEE.6010405@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/json/HRMERhG35W55DR9hNYe3xoRYdkI Cc: Julian Reschke , "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:37:24 -0000 On 3/4/14 5:31 PM, Bjoern Hoehrmann wrote: > * Pete Resnick wrote: > >> On 3/4/14 5:11 PM, Julian Reschke wrote: >> >>> Hm. >>> >>> [Err3607] RFC Errata, Errata ID 3607, RFC 3607, >>> . >>> >>> [Err607] RFC Errata, Errata ID 607, RFC 607, >>> . >>> >>> Really?? >>> >> >> >> >> These two errata are on RFC 4627. Erratum 3607 is marked as "Held For >> Document Update" and 607 is marked as "Verified". >> >> What's the question? >> > Read the reference text more carefully. RFC 3607 is "Chinese Lottery > Cryptanalysis Revisited: The Internet as a Codebreaking Tool" and RFC > 607 is "Comments on the File Transfer Protocol". > Where did Julian's text above come from? The RFC Editor web site? This sounds like a report of a bug on the RFC Editor web site, displaying the wrong RFC number, not an issue for this WG. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 4 09:39:34 2014 Return-Path: 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 277A61A027B for ; Tue, 4 Mar 2014 09:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 YCSukVp1rVq6 for ; Tue, 4 Mar 2014 09:39:26 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9320F1A0227 for ; Tue, 4 Mar 2014 09:39:26 -0800 (PST) Received: from dhcp-b2d4.meeting.ietf.org (unknown [31.133.178.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9CCAD50AA2; Tue, 4 Mar 2014 12:39:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <53160CEE.6010405@qti.qualcomm.com> Date: Tue, 4 Mar 2014 17:39:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <144D54C9-2BFA-4F44-987C-12AEAF9D904F@mnot.net> References: <5316095B.5050201@gmx.de> <53160CEE.6010405@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/jVzlwdZDFlfOJuFRytX6TECbBfs Cc: "Julian F. Reschke" , "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:39:30 -0000 On 4 Mar 2014, at 5:27 pm, Pete Resnick = wrote: > On 3/4/14 5:11 PM, Julian Reschke wrote: >> Hm. >>=20 >> [Err3607] RFC Errata, Errata ID 3607, RFC 3607, >> . >>=20 >> [Err607] RFC Errata, Errata ID 607, RFC 607, >> . >>=20 >> Really?? >=20 > > >=20 > These two errata are on RFC 4627. Erratum 3607 is marked as "Held For = Document Update" and 607 is marked as "Verified". >=20 > What's the question? Well, the references section seems to indicate that these errata are = somehow related to RFC 3607 and RFC 607=85 I haven=92t looked those up, but I=92m guessing they=92re not to do with = JSON. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Tue Mar 4 09:39:55 2014 Return-Path: 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 C6B091A027F for ; Tue, 4 Mar 2014 09:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 UC_8d4qEC6BD for ; Tue, 4 Mar 2014 09:39:47 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B43431A027D for ; Tue, 4 Mar 2014 09:39:47 -0800 (PST) Received: from dhcp-b2d4.meeting.ietf.org (unknown [31.133.178.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D647950A89; Tue, 4 Mar 2014 12:39:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <53160F3E.1000408@qti.qualcomm.com> Date: Tue, 4 Mar 2014 17:39:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5316095B.5050201@gmx.de> <53160CEE.6010405@qti.qualcomm.com> <53160F3E.1000408@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/vgp55Lx7E4U_7NvWBzWo6vYXZtE Cc: "Julian F. Reschke" , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:39:52 -0000 15.2 Informative References On 4 Mar 2014, at 5:37 pm, Pete Resnick = wrote: > On 3/4/14 5:31 PM, Bjoern Hoehrmann wrote: >> * Pete Resnick wrote: >> =20 >>> On 3/4/14 5:11 PM, Julian Reschke wrote: >>> =20 >>>> Hm. >>>>=20 >>>> [Err3607] RFC Errata, Errata ID 3607, RFC 3607, >>>> . >>>>=20 >>>> [Err607] RFC Errata, Errata ID 607, RFC 607, >>>> . >>>>=20 >>>> Really?? >>>> =20 >>> >>> >>>=20 >>> These two errata are on RFC 4627. Erratum 3607 is marked as "Held = For >>> Document Update" and 607 is marked as "Verified". >>>=20 >>> What's the question? >>> =20 >> Read the reference text more carefully. RFC 3607 is "Chinese Lottery >> Cryptanalysis Revisited: The Internet as a Codebreaking Tool" and RFC >> 607 is "Comments on the File Transfer Protocol". >> =20 >=20 > Where did Julian's text above come from? The RFC Editor web site? This = sounds like a report of a bug on the RFC Editor web site, displaying the = wrong RFC number, not an issue for this WG. >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From nobody Tue Mar 4 09:42:12 2014 Return-Path: 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 975D91A021A for ; Tue, 4 Mar 2014 09:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 hP8riHJ06W5m for ; Tue, 4 Mar 2014 09:42:03 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id A50E11A02A5 for ; Tue, 4 Mar 2014 09:42:03 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hq11so4786855vcb.28 for ; Tue, 04 Mar 2014 09:42:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kqU/PRlia5euhCyrDghpTEKts7tjnGhwGGuUuDpd5iE=; b=J4INuiOh3hE0xmiVH0auLwocL8K2PE8oFPsoJsdZUpgeBVXGLyxfEgEUUFx9orcz6G DNqe3v6RRgOVQyBYbageewJh0YSQ9O8/pAX+FeDNTKdMbKZppV1bwAzAuJPElJAeZUSW 4fB7GqcLqgwnXqQdk23lbAW3BDVvqkoUjMGUH3KItWgRiMT0/EKvejFQ8XsqRLPsYfEW enVQ0M6l2MNY/KaA/KKGCkmFzIpE8Nd+MvVd+RXaZ/4Gz8EkHzXIpVM76J89KUjj2bUq DmWGQJaUrLVUKalCaNizL7Wg+sFc3qQJ9px4GZW2Emx1RNp9rZ9pL6QbouawiHBRFN+1 Uszg== X-Gm-Message-State: ALoCoQkkNp6bubTHMxJjhq5zpOAai6xUbuB0LI2WBLNlkLpBOwkI52m13oeTFIVTUlGlCUaieTsi MIME-Version: 1.0 X-Received: by 10.52.141.105 with SMTP id rn9mr441191vdb.44.1393954920241; Tue, 04 Mar 2014 09:42:00 -0800 (PST) Received: by 10.220.98.73 with HTTP; Tue, 4 Mar 2014 09:42:00 -0800 (PST) X-Originating-IP: [130.129.159.69] In-Reply-To: References: <5316095B.5050201@gmx.de> <53160CEE.6010405@qti.qualcomm.com> <53160F3E.1000408@qti.qualcomm.com> Date: Tue, 4 Mar 2014 09:42:00 -0800 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec51ba307dab16904f3cb6b02 Archived-At: http://mailarchive.ietf.org/arch/msg/json/yUwENOretWcGmT7zq1ZOxMzYAGs Cc: "Julian F. Reschke" , Pete Resnick , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] more errata (references) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:42:08 -0000 --bcaec51ba307dab16904f3cb6b02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Minor production screwup, it=E2=80=99s in the XML: Live with it, I say. On Tue, Mar 4, 2014 at 9:39 AM, Mark Nottingham wrote: > 15.2 Informative References > > > On 4 Mar 2014, at 5:37 pm, Pete Resnick wrote= : > > > On 3/4/14 5:31 PM, Bjoern Hoehrmann wrote: > >> * Pete Resnick wrote: > >> > >>> On 3/4/14 5:11 PM, Julian Reschke wrote: > >>> > >>>> Hm. > >>>> > >>>> [Err3607] RFC Errata, Errata ID 3607, RFC 3607, > >>>> . > >>>> > >>>> [Err607] RFC Errata, Errata ID 607, RFC 607, > >>>> . > >>>> > >>>> Really?? > >>>> > >>> > >>> > >>> > >>> These two errata are on RFC 4627. Erratum 3607 is marked as "Held For > >>> Document Update" and 607 is marked as "Verified". > >>> > >>> What's the question? > >>> > >> Read the reference text more carefully. RFC 3607 is "Chinese Lottery > >> Cryptanalysis Revisited: The Internet as a Codebreaking Tool" and RFC > >> 607 is "Comments on the File Transfer Protocol". > >> > > > > Where did Julian's text above come from? The RFC Editor web site? This > sounds like a report of a bug on the RFC Editor web site, displaying the > wrong RFC number, not an issue for this WG. > > > > pr > > > > -- > > Pete Resnick > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec51ba307dab16904f3cb6b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Minor production screwup, it=E2=80=99s in the XML: <ser= iesInfo name=3D"RFC" value=3D"607"/>

<= div>Live with it, I say.


On Tue, Mar 4, 2014 at 9:39 AM, Mark Nottingham <mnot@mnot.net> = wrote:
15.2 Informative References


On 4 Mar 2014, at 5:37 pm, Pete Resnick <presnick@qti.qualcomm.com> wrote:

> On 3/4/14 5:31 PM, Bjoern Hoehrmann wrote:
>> * Pete Resnick wrote:
>>
>>> On 3/4/14 5:11 PM, Julian Reschke wrote:
>>>
>>>> Hm.
>>>>
>>>> =C2=A0 =C2=A0[Err3607] =C2=A0RFC Errata, Errata ID 3607, R= FC 3607,
>>>> <http://www.rfc-editor.org>.
>>>>
>>>> =C2=A0 =C2=A0[Err607] =C2=A0 RFC Errata, Errata ID 607, RF= C 607,
>>>> <http://www.rfc-editor.org>.
>>>>
>>>> Really??
>>>>
>>> <http://www.rfc-editor.org/errata_search.php?eid= =3D3607>
>>> <http://www.rfc-editor.org/errata_search.php?eid= =3D607>
>>>
>>> These two errata are on RFC 4627. Erratum 3607 is marked as &q= uot;Held For
>>> Document Update" and 607 is marked as "Verified"= ;.
>>>
>>> What's the question?
>>>
>> Read the reference text more carefully. RFC 3607 is "Chinese = Lottery
>> Cryptanalysis Revisited: The Internet as a Codebreaking Tool"= and RFC
>> 607 is "Comments on the File Transfer Protocol".
>>
>
> Where did Julian's text above come from? The RFC Editor web site? = This sounds like a report of a bug on the RFC Editor web site, displaying t= he wrong RFC number, not an issue for this WG.
>
> pr
>
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_____________________________= __________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--bcaec51ba307dab16904f3cb6b02-- From nobody Tue Mar 4 12:13:05 2014 Return-Path: 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 CD1561A0263 for ; Tue, 4 Mar 2014 12:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 HeEk-lwegELy for ; Tue, 4 Mar 2014 12:13:00 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BE82A1A020D for ; Tue, 4 Mar 2014 12:12:59 -0800 (PST) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s24KCWj2015484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 15:12:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1393963954; bh=co/SuVaQKly/kQgeV8KMDBkJp9b8a3GPwkxmk6Fv2jc=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=JiK/3Jyx2d0802AEAonSjm4Qr9XwrlbJ+2p3QXJ4/s239hKk+FG+9ZqDwrxM/A4kV unfdnGkzB1/sn1thpkz7nRniQCX0mnqt7nL2hKF3+qbQXI2gcCaukN3G8hvK52AiLh CnvpOL9PVzupY7NWgtv4QR0UOlGZaagophZaj5e8= From: "Paul E. Jones" To: "Tim Bray" Date: Tue, 04 Mar 2014 20:12:45 +0000 Content-Type: multipart/alternative; boundary="------=_MB4AF4E751-9671-4E95-937A-24BDF17C2F70" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.19861.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pDbwQHbHHOLuwmEL9XExwEAfslc Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , Matthew Miller , Barry Leiba , rfc7158@schmorp.de, RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:13:02 -0000 --------=_MB4AF4E751-9671-4E95-937A-24BDF17C2F70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Tim, Yeah, I saw that. However, I still think this only opens the door for=20 future implementations to produce things that do not work reliably. As=20 Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears=20 to have disappeared), a serializer that is requested to serialize a=20 series of integers like 1 and 999 might produce 1999. Reading that back= =20 in, the single value 1999 would be read. Likewise, a serializer might=20 produce truefalse as output, but then fail when one tries to read that=20 back. One might argue to start all serialization with whitespace to=20 avoid having values serialized adjacent to each other. That would work,= =20 but unfortunate. Maybe I missed it, but I could not see _why_ the change was made to this= =20 production. What was wrong with allowing only an object or array? Looking at some of the messages hanging off of the link Bj=C3=B6rn provided= ,=20 I can see people are worried, too, about the BOM. The previous text=20 made it very clear how to determine whether the text is UTF-16LE or=20 UTF-16BE, for example. That text seems to have disappeared. Is there a= =20 reason? I think the same approach spelled out in Section 3 of RFC 4627=20 would still work, no? Paul ------ Original Message ------ From: "Tim Bray" To: "Paul E. Jones" Cc: "Bjoern Hoehrmann" ; "RFC Errata System"=20 ; "Pete Resnick" ;= =20 "Paul Hoffman" ; "json@ietf.org" ;= =20 "Matthew Miller" ; "Barry Leiba"=20 ; rfc7158@schmorp.de Sent: 3/4/2014 12:27:51 PM Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >On this issue, also please read the interoperability note in the=20 >paragraph before the new production. > > >On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones =20 >wrote: >>I've not been following the list closely, as I thought this was more=20 >>of an editorial exercise than anything else. This is definitely more=20 >>than editorial. This could definitely break things and the commenter=20 >>is right that there are instances where there could be=20 >>misinterpretation. >> >>Why was it decided to change this: >> >> JSON-text =3D object / array >> >>to >> >> JSON-text =3D ws value ws >> >>Was there some misunderstanding of what 4627 said? >> >>Paul >> >> >>------ Original Message ------ >>From: "Bjoern Hoehrmann" >>To: "RFC Errata System" >>Cc: presnick@qti.qualcomm.com; paul.hoffman@vpnc.org; json@ietf.org;=20 >>tbray@textuality.com; mamille2@cisco.com; barryleiba@computer.org;=20 >>rfc7158@schmorp.de; rfc-editor@rfc-editor.org >>Sent: 3/2/2014 4:31:07 PM >>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >> >>>* RFC Errata System wrote: >>>>Since RFC7158 breaks compatibility with the specifications, this=20 >>>>should be >>>>duly noted. >>> >>>It is in Appendix A., "Changes from RFC 4627": >>> >>> o Changed the definition of "JSON text" so that it can be any JSON >>> value, removing the constraint that it be an object or array. >>> >>>Failing to note this in the Introduction is not ideal, but the errata >>>system is not a good place to record that (holding it for document=20 >>>up- >>>date probably does not make sense, if and when the document does get >>>updated, this particular issue will not require prominent notice). >>>-- >>>Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7=20 >>>http://bjoern.hoehrmann.de >>>Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7=20 >>>http://www.bjoernsworld.de >>>25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7=20 >>>http://www.websitedev.de/ >>> >>>_______________________________________________ >>>json mailing list >>>json@ietf.org >>>https://www.ietf.org/mailman/listinfo/json >> > --------=_MB4AF4E751-9671-4E95-937A-24BDF17C2F70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Tim,
 
Yeah, I saw that.  However, I still think this only opens the = door for future implementations to produce things that do not work reliably= .  As Marc Lehmann rightfully pointed out (and, BTW, his Errata text= appears to have disappeared), a serializer that is requested to serialize= a series of integers like 1 and 999 might produce 1999.  Reading that= back in, the single value 1999 would be read.  Likewise, a serializer= might produce truefalse as output, but then fail when one tries to read= that back.  One might argue to start all serialization with whitespac= e to avoid having values serialized adjacent to each other.  That woul= d work, but unfortunate.
 
Maybe I missed it, but I could not see _why_ the change was made to= this production.  What was wrong with allowing only an object or arra= y?
 
Looking at some of the messages hanging off of the link Bj=C3=B6rn = provided, I can see people are worried, too, about the BOM.  The previ= ous text made it very clear how to determine whether the text is UTF-1= 6LE or UTF-16BE, for example.  That text seems to have disappeared.&nb= sp; Is there a reason?  I think the same approach spelled out in Secti= on 3 of RFC 4627 would still work, no?
 
Paul
 
------ Original Message ------
From: "Tim Bray" <tbray@tex= tuality.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Cc: "Bjoern Hoehrmann" <derhoe= rmi@gmx.net>; "RFC Errata System" <rfc-editor@rfc-editor.org>; "Pete Resnick" <presnick@qti.qualcomm.com>= ; "Paul Hoffman" <paul.hoffman@= vpnc.org>; "json@ietf.org" <json= @ietf.org>; "Matthew Miller" <mamille2@cisco.com>; "Barry Leiba" <barryleiba@computer.org>; rfc7158@schmorp.de
Sent: 3/4/2014 12:27:51 PM
Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
 
On this issue, also please read the interoperability note= in the paragraph before the new production.


On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones <paulej@packetizer.= com> wrote:
I've not been following the = list closely, as I thought this was more of an editorial exercise than anyt= hing else.  This is definitely more than editorial.  This could= definitely break things and the commenter is right that there are instance= s where there could be misinterpretation.

Why was it decided to chan= ge this:

    JSON-text =3D object / array

to
    JSON-text =3D ws value ws

Was there some misunderstan= ding of what 4627 said?

P= aul=20


------ Original Message ------
From: "Bjoern = Hoehrmann" <derhoermi@gmx.net&g= t;
To: "RFC Errata System" <rfc-editor@rfc-editor.org>
Cc: presnick@qti.qualcomm.com; paul.hoffman@vpnc.org; jso= n@ietf.org; tbray@textuality.co= m; mamille2@cisco.com; barryleiba@computer.org; rfc7158@schmorp.de; rfc-editor@rfc-editor.org
Sent: 3/2/201= 4 4:31:07 PM
Subject: Re: [Json] [Technical Errata Reported] RFC7158 = (3907)

* RFC Errata System wrote:
Since RFC7158 breaks compatibil= ity with the specifications, this should be
duly noted.
=
It is in Appendix A., "Changes from RFC 4627":

   o= Changed the definition of "JSON text" so that it can be any JSON
 =     value, removing the constraint that it be an object or array= .

Failing to note this in the Introduction is not ideal, but the = errata
system is not a good place to record that (holding it for documen= t up-
date probably does not make sense, if and when the document does= get
updated, this particular issue will not require prominent notice).<= BR>--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =C2=B7 Telefon:= +49(0)16= 0/4415681 =C2=B7 http://www.bjo= ernsworld.de
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78= =C2=B7 http://www.websitedev.de/=

_______________________________________________
json mailing= list
json@ietf.org
https://www.ietf.org/mailman/<= U>listinfo/json


--------=_MB4AF4E751-9671-4E95-937A-24BDF17C2F70-- From nobody Fri Mar 7 08:34:11 2014 Return-Path: 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 0A0741A00FC for ; Fri, 7 Mar 2014 05:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 7NCjuPBFH3Yb for ; Fri, 7 Mar 2014 05:09:36 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8251A00EB for ; Fri, 7 Mar 2014 05:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4641; q=dns/txt; s=iport; t=1394197772; x=1395407372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rb8YtZraeASqdlN92C+NXfHcI3p7cAEkByMC3v+FmLU=; b=SFgesEesNLZFCHZ5LWuatM1yYaj7rJb/K0OeLSvnAPPy8Arg8+RDOjS7 CWRWSyS+YlAhq8FkHuXUW6yeIv4Mpf+hT/4DP7jbfcuWARBFdnWtneSO5 NGiur2ujPVeeJhRE+QVwf85t/rBqyRExv1pzAuxaLdNjUGY+1AS3XKwSW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADLEGVOtJV2d/2dsb2JhbABagwY7V8EmgRMWdIIlAQEBBAEBAWsLDAQCAQgRBAEBAScHJwsUCQgCBAENBYdlAxENz1IXjESBZDMHBoQyBIkYjyuBMpB5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,607,1389744000"; d="scan'208";a="308690367" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 07 Mar 2014 13:09:32 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s27D9Vmh002204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 13:09:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 07:09:31 -0600 From: "Joe Hildebrand (jhildebr)" To: "Paul E. Jones" , Tim Bray Thread-Topic: [Json] [Technical Errata Reported] RFC7158 (3907) Thread-Index: AQHPN7R+OZJOXM0/ykGBbx4BwkPKfZrRk0+AgAAuEoCABEC9gA== Date: Fri, 7 Mar 2014 13:09:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.88.62] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/djGzUMHRGPwsOFOehkATzP3X1t4 X-Mailman-Approved-At: Fri, 07 Mar 2014 08:34:10 -0800 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" , RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:09:39 -0000 Paul: ECMA's version of JSON has allowed anything at the top level for quite a while. The WG explicitly decided that having the two specs in sync was more important to us than the backward-compatility issue, which we documented. This isn't a "mistake" in the sense that we didn't know it was happening - it was the consensus of the people who were participating. On 3/4/14 8:12 PM, "Paul E. Jones" wrote: >Tim, >=20 >Yeah, I saw that. However, I still think this only opens the door for >future implementations to produce things that do not work reliably. As >Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears to >have disappeared), a serializer that > is requested to serialize a series of integers like 1 and 999 might >produce 1999. Reading that back in, the single value 1999 would be read. > Likewise, a serializer might produce truefalse as output, but then fail >when one tries to read that back. One might > argue to start all serialization with whitespace to avoid having values >serialized adjacent to each other. That would work, but unfortunate. >=20 >Maybe I missed it, but I could not see _why_ the change was made to this >production. What was wrong with allowing only an object or array? >=20 >Looking at some of the messages hanging off of the link Bj=F6rn provided, = I >can see people are worried, too, about the BOM. The previous text made >it very clear how to determine whether the text is UTF-16LE or UTF-16BE, >for example. That text seems to > have disappeared. Is there a reason? I think the same approach spelled >out in Section 3 of RFC 4627 would still work, no? >=20 >Paul >=20 >------ Original Message ------ >From: "Tim Bray" >To: "Paul E. Jones" >Cc: "Bjoern Hoehrmann" ; "RFC Errata System" >; "Pete Resnick" ; > "Paul Hoffman" ; "json@ietf.org" ; >"Matthew Miller" ; "Barry Leiba" >; >rfc7158@schmorp.de >Sent: 3/4/2014 12:27:51 PM >Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >=20 > >On this issue, also please read the interoperability note in the >paragraph before the new production. > > >On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones > wrote: > >I've not been following the list closely, as I thought this was more of >an editorial exercise than anything else. This is definitely more than >editorial. This could definitely break things and the commenter is right >that there are instances where there could > be misinterpretation. > >Why was it decided to change this: > > JSON-text =3D object / array > >to > > JSON-text =3D ws value ws > >Was there some misunderstanding of what 4627 said? > >Paul > >------ Original Message ------ >From: "Bjoern Hoehrmann" >To: "RFC Errata System" >Cc: presnick@qti.qualcomm.com; >paul.hoffman@vpnc.org ; json@ietf.org; >tbray@textuality.com ; mamille2@cisco.com; >barryleiba@computer.org; >rfc7158@schmorp.de ; rfc-editor@rfc-editor.org >Sent: 3/2/2014 4:31:07 PM >Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) > > > >* RFC Errata System wrote: > >Since RFC7158 breaks compatibility with the specifications, this should be >duly noted. > > > >It is in Appendix A., "Changes from RFC 4627": > > o Changed the definition of "JSON text" so that it can be any JSON > value, removing the constraint that it be an object or array. > >Failing to note this in the Introduction is not ideal, but the errata >system is not a good place to record that (holding it for document up- >date probably does not make sense, if and when the document does get >updated, this particular issue will not require prominent notice). >-- >Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 >http://bjoern.hoehrmann.de >Am Badedeich 7 =B7 Telefon: >+49(0)160/4415681 =B7 >http://www.bjoernsworld.de >25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 >http://www.websitedev.de/ > > > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > > --=20 Joe Hildebrand From nobody Fri Mar 7 09:12:51 2014 Return-Path: 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 6E0161A0274 for ; Fri, 7 Mar 2014 09:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 C3NU9lONQpd5 for ; Fri, 7 Mar 2014 09:12:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8A1A00AA for ; Fri, 7 Mar 2014 09:12:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B1B8D7FC392; Fri, 7 Mar 2014 09:12:44 -0800 (PST) To: tbray@textuality.com, barryleiba@computer.org, presnick@qti.qualcomm.com, mamille2@cisco.com, paul.hoffman@vpnc.org From: RFC Errata System Message-Id: <20140307171244.B1B8D7FC392@rfc-editor.org> Date: Fri, 7 Mar 2014 09:12:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/cJq5BxuLV7AvPVFxsECJvuKL5Bg Cc: vfaronov@gmail.com, rfc-editor@rfc-editor.org, json@ietf.org Subject: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:12:50 -0000 The following errata report has been submitted for RFC7159, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7159&eid=3915 -------------------------------------- Type: Technical Reported by: Vasiliy Faronov Section: 12 Original Text ------------- Since JSON's syntax is borrowed from JavaScript, it is possible to use that language's "eval()" function to parse JSON texts. Corrected Text -------------- Since JSON's syntax is borrowed from JavaScript, it is possible to use that language's "eval()" function to parse most (but not all) JSON texts. Notes ----- This wording may be construed as meaning that every compliant JSON text is parseable as JavaScript, which is not the case: . (Actually I would prefer this to be stated clearly elsewhere in the document, e.g. where it says JSON's design goals were for it to be [...] a subset of JavaScript.) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : March 2014 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Mar 7 09:43:31 2014 Return-Path: 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 78EE41A0083 for ; Fri, 7 Mar 2014 09:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 flCuasi90_EW for ; Fri, 7 Mar 2014 09:43:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 12B891A00AA for ; Fri, 7 Mar 2014 09:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=975; q=dns/txt; s=iport; t=1394214205; x=1395423805; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=8Tz7M3IeTLXjE7Cy0evRZVBc/u2+jt317LRTA8e2hio=; b=l8+bBjpf9DCKJytqBo9/y3e64XAs1C00shnFxduSF7nzfgejowCYyBJv rdLJ1V0BUl7Hxzpkd6rCJpRUoyqlQn5lIXwBkBqtGEMvz1PZl9YigZmRB Aylu7nr+WB8YfwotfRsJhceJ9xTOz1rhVmN9ItDDZEOMu6v3hOpGyreIu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQPAL8EGlOtJV2d/2dsb2JhbABagwY7V6g5BAaZdRZ0gyQ9FhgDAgECAUsNBgIBAQWHcA2fULBGF5MaBIkYjyuSK4Mtgis X-IronPort-AV: E=Sophos;i="4.97,609,1389744000"; d="scan'208";a="25753338" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 07 Mar 2014 17:43:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s27HhOOt010012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Mar 2014 17:43:24 GMT Received: from che-vpn-cluster-2-287.cisco.com (10.86.243.32) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Mar 2014 11:43:23 -0600 Message-ID: <531A0539.2050502@cisco.com> Date: Fri, 7 Mar 2014 17:43:21 +0000 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.86.243.32] Archived-At: http://mailarchive.ietf.org/arch/msg/json/O9ot1d1RiLnJwBI8YE0Sidf2laA Subject: [Json] Minutes for IETF 89 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:43:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The minutes for the JSON WG session have been posted to the data tracker: < http://www.ietf.org/proceedings/89/minutes/minutes-89-json > Please send any corrections or additions to the chairs as soon as possible. Thanks! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTGgU5AAoJEDWi+S0W7cO1TJoH/0jw1/yYYKv1VFazYc7ULmkK ykZKbP/rQFENQ2DoHD7gmwhhvuSEt5WXeEn3Tw7zUMVoK1Cje8TEPX7fVvA0n0xZ 4Q7eWJDz/Js1LujmVJE7zZF6ZaxBO++z2Z32j21Iz5jgzSadGRAslyPVWxgG7A7u Qm6WY/v5JRkgrgbzcqyJWH4IHkjn/ndteC80cQHh8QrgilDeYG8vHg1uNmhUve2u 74R0otZfxa410DhD1rME7F8E5cE8uodtJYYqwJuADJLLL8GidXO9S+anQ/yxDsKZ 1mzspeKPLBgxcHiMxfmEwm3Q46SR1gJX9ZmJYzRQRk3PdMXTVZ3yTRyQ+AiPEis= =yG8D -----END PGP SIGNATURE----- From nobody Fri Mar 7 11:11:29 2014 Return-Path: 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 951841A0073 for ; Fri, 7 Mar 2014 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 fMlJqz05VwBX for ; Fri, 7 Mar 2014 11:11:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD9A1A0026 for ; Fri, 7 Mar 2014 11:11:17 -0800 (PST) Received: from netb ([82.113.121.197]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lo3IS-1Woi9b2JDs-00g2b8; Fri, 07 Mar 2014 20:11:10 +0100 From: Bjoern Hoehrmann To: Matt Miller Date: Fri, 07 Mar 2014 20:11:08 +0100 Message-ID: References: <531A0539.2050502@cisco.com> In-Reply-To: <531A0539.2050502@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9dqLnduBsjhqSz5Lc7u31hz63uSePhhHkLF3MjYKIXPCqPHS4z/ Q3RLp6bpu1faVbKoXA/NmdqLv9QtfC+17ZOtzcpV2HhrBaelTuDqpFqqZCl/G3dgTKUa3B0 FdM54GyLoMoDDKrXigMz19TwpLZdRA9t4AUzSY8gAFOV5Khn3hjugF23vwtXMfJrCfLWG0A v/r/W4fvL0i/f2YIp2l7g== Archived-At: http://mailarchive.ietf.org/arch/msg/json/72Cph_1KE0K6lwRwwGsMkpnlxqA Cc: IETF JSON WG Subject: Re: [Json] Minutes for IETF 89 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 19:11:26 -0000 * Matt Miller wrote: >The minutes for the JSON WG session have been posted to the data >tracker: < http://www.ietf.org/proceedings/89/minutes/minutes-89-json > That comes out as HTTP/1.1 200 OK Date: Fri, 07 Mar 2014 19:09:07 GMT Server: Apache Content-Location: minutes-89-json.txt Vary: negotiate,Accept-Encoding TCN: choice Last-Modified: Fri, 07 Mar 2014 17:41:05 GMT ETag: "95a2f68-2240-4f407c22322da;4f407c222d4ba" Accept-Ranges: bytes Content-Length: 8768 Content-Type: text/plain without a charset parameter in the Content-Type header, but the document seems to be UTF-8 encoded, which has to be declared there. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Fri Mar 7 12:03:01 2014 Return-Path: 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 9BB6F1A017E for ; Fri, 7 Mar 2014 12:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 PgrM6JZzPMsw for ; Fri, 7 Mar 2014 12:02:57 -0800 (PST) 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 5EFE01A014D for ; Fri, 7 Mar 2014 12:02:57 -0800 (PST) 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.5/8.14.5) with ESMTP id s27K2hnu003683; Fri, 7 Mar 2014 21:02:43 +0100 (CET) Received: from [10.109.74.208] (unknown [62.232.113.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E7F85FCB; Fri, 7 Mar 2014 21:02:42 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Fri, 7 Mar 2014 20:02:41 +0000 X-Mao-Original-Outgoing-Id: 415915361.833313-c92584e35d836aafe5e60db92088a7de Content-Transfer-Encoding: quoted-printable Message-Id: <1B908B4B-BFD0-4D1C-BF58-CE89B9130FF4@tzi.org> References: <531A0539.2050502@cisco.com> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/g1qlKLuuf8h3aqwzrQyXrxk-H58 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Minutes for IETF 89 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:02:58 -0000 On 07 Mar 2014, at 19:11, Bjoern Hoehrmann wrote: > without a charset parameter in the Content-Type header Tell me about it. I=92ve been trying to get the secretariat react to the innovation of = UTF-8 for half a decade now. (The ticket number for my latest attempt is #43750.) Maybe we can join forces to effect that change=85 Gr=FC=DFe, Carsten From nobody Fri Mar 7 13:09:43 2014 Return-Path: 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 AC72C1A01EE for ; Fri, 7 Mar 2014 13:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 YU_FHwB14flO for ; Fri, 7 Mar 2014 13:09:38 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 452FC1A0102 for ; Fri, 7 Mar 2014 13:09:38 -0800 (PST) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s27L9JbN030691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Mar 2014 16:09:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1394226561; bh=a0FcbAfzomjAQNEDCRPA7gRbBBNhhM6KX2Nl07l3D6A=; h=From:To:Subject:Cc:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=Kq79Al+ZJ+/eNVj9lLbaR5CzWXRL/jMy7oTZF7eMWya8PhhOLU+abNIL9Srm4DHok EzQ2UP9HqenQL60M1lA6UfJ+pTuf3eIRSBJ1o1pwzVpK9rSUpJGsNRoWwtHguBiI8s JX+Q4LMVGYowMbCICQbW1GJ1x19hWRIwanzK4OFg= From: "Paul E. Jones" To: "Joe Hildebrand (jhildebr)" , "Tim Bray" Date: Fri, 07 Mar 2014 21:09:39 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.19861.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/k4Ld3vA0oKREDaOU-AwcPuiWAtw Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:09:39 -0000 Joe, But if my understanding is correct, it's not just a matter of=20 backward-compatibility. There is the question of "how does a serializer= =20 write out data now"? As Marc pointed out, if one has two integers and requests a stateless=20 serializing function to write those out to a file or on the wire, it=20 will write out "1" and "999", using his examples. Reading it back in,=20 it would look like a single integer ("1999"). This means the serializer= =20 would have to be explicitly told whether to insert space before or after= =20 writing out data. Alternatively, the application would have to ask the=20 serializer to serialize it to a string and the application deal with=20 whitespace itself. Paul ------ Original Message ------ From: "Joe Hildebrand (jhildebr)" To: "Paul E. Jones" ; "Tim Bray"=20 Cc: "Pete Resnick" ; "Bjoern Hoehrmann"=20 ; "Paul Hoffman" ;=20 "json@ietf.org" ; "Matt Miller (mamille2)"=20 ; "Barry Leiba" ;=20 "rfc7158@schmorp.de" ; "RFC Errata System"=20 Sent: 3/7/2014 8:09:30 AM Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >Paul: ECMA's version of JSON has allowed anything at the top level for >quite a while. The WG explicitly decided that having the two specs in >sync was more important to us than the backward-compatility issue,=20 >which >we documented. This isn't a "mistake" in the sense that we didn't know=20 >it >was happening - it was the consensus of the people who were=20 >participating. > > >On 3/4/14 8:12 PM, "Paul E. Jones" wrote: > >>Tim, >> >>Yeah, I saw that. However, I still think this only opens the door for >>future implementations to produce things that do not work reliably. As >>Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears= =20 >>to >>have disappeared), a serializer that >> is requested to serialize a series of integers like 1 and 999 might >>produce 1999. Reading that back in, the single value 1999 would be=20 >>read. >> Likewise, a serializer might produce truefalse as output, but then=20 >>fail >>when one tries to read that back. One might >> argue to start all serialization with whitespace to avoid having=20 >>values >>serialized adjacent to each other. That would work, but unfortunate. >> >>Maybe I missed it, but I could not see _why_ the change was made to=20 >>this >>production. What was wrong with allowing only an object or array? >> >>Looking at some of the messages hanging off of the link Bj=C3=B6rn=20 >>provided, I >>can see people are worried, too, about the BOM. The previous text made >>it very clear how to determine whether the text is UTF-16LE or=20 >>UTF-16BE, >>for example. That text seems to >> have disappeared. Is there a reason? I think the same approach=20 >>spelled >>out in Section 3 of RFC 4627 would still work, no? >> >>Paul >> >>------ Original Message ------ >>From: "Tim Bray" >>To: "Paul E. Jones" >>Cc: "Bjoern Hoehrmann" ; "RFC Errata System" >>; "Pete Resnick"=20 >>; >> "Paul Hoffman" ; "json@ietf.org"=20 >>; >>"Matthew Miller" ; "Barry Leiba" >>; >>rfc7158@schmorp.de >>Sent: 3/4/2014 12:27:51 PM >>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >> >> >>On this issue, also please read the interoperability note in the >>paragraph before the new production. >> >> >>On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones >> wrote: >> >>I've not been following the list closely, as I thought this was more=20 >>of >>an editorial exercise than anything else. This is definitely more than >>editorial. This could definitely break things and the commenter is=20 >>right >>that there are instances where there could >> be misinterpretation. >> >>Why was it decided to change this: >> >> JSON-text =3D object / array >> >>to >> >> JSON-text =3D ws value ws >> >>Was there some misunderstanding of what 4627 said? >> >>Paul >> >>------ Original Message ------ >>From: "Bjoern Hoehrmann" >>To: "RFC Errata System" >>Cc: presnick@qti.qualcomm.com; >>paul.hoffman@vpnc.org ; json@ietf.org; >>tbray@textuality.com ;=20 >>mamille2@cisco.com; >>barryleiba@computer.org; >>rfc7158@schmorp.de ;=20 >>rfc-editor@rfc-editor.org >>Sent: 3/2/2014 4:31:07 PM >>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) >> >> >> >>* RFC Errata System wrote: >> >>Since RFC7158 breaks compatibility with the specifications, this=20 >>should be >>duly noted. >> >> >> >>It is in Appendix A., "Changes from RFC 4627": >> >> o Changed the definition of "JSON text" so that it can be any JSON >> value, removing the constraint that it be an object or array. >> >>Failing to note this in the Introduction is not ideal, but the errata >>system is not a good place to record that (holding it for document up- >>date probably does not make sense, if and when the document does get >>updated, this particular issue will not require prominent notice). >>-- >>Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 >>http://bjoern.hoehrmann.de >>Am Badedeich 7 =C2=B7 Telefon: >>+49(0)160/4415681 =C2=B7 >>http://www.bjoernsworld.de >>25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 >>http://www.websitedev.de/ >> >> >> >>_______________________________________________ >>json mailing list >>json@ietf.org >>https://www.ietf.org/mailman/listinfo/json >> >> >> >> >> >> >> >> >> >> >> >> >> > > >-- >Joe Hildebrand > > > From nobody Sat Mar 8 20:50:22 2014 Return-Path: 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 0ECDB1A01E2 for ; Sat, 8 Mar 2014 20:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001] 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 mF4IdYM78uZo for ; Sat, 8 Mar 2014 20:50:20 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id A09461A01BC for ; Sat, 8 Mar 2014 20:50:19 -0800 (PST) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB323.namprd02.prod.outlook.com (10.141.91.18) with Microsoft SMTP Server (TLS) id 15.0.893.10; Sun, 9 Mar 2014 04:50:06 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Sun, 9 Mar 2014 04:50:06 +0000 From: Larry Masinter To: "json@ietf.org" Thread-Topic: comments on Ihttp://tools.ietf.org/html/draft-bray-i-json-01 Thread-Index: Ac87Ub0Jge6iJa+uS2GWj5EoJw92cw== Date: Sun, 9 Mar 2014 04:50:05 +0000 Message-ID: <4c3a1d93ddbf4909ba8fac74253230b9@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.239.250.1] x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(93136001)(93516002)(83072002)(65816001)(85852003)(66066001)(46102001)(80022001)(15202345003)(77982001)(59766001)(74316001)(79102001)(76176001)(54316002)(90146001)(220493001)(56816005)(74706001)(74366001)(47736001)(53806001)(54356001)(86362001)(81686001)(51856001)(76482001)(69226001)(76576001)(76796001)(76786001)(50986001)(33646001)(49866001)(83322001)(47976001)(19580395003)(80976001)(81342001)(4396001)(81542001)(63696002)(15975445006)(87936001)(81816001)(2656002)(92566001)(95666003)(74662001)(31966008)(47446002)(74502001)(94946001)(97336001)(85306002)(95416001)(87266001)(97186001)(94316002)(74876001)(21314002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB323; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:204.239.250.1; FPR:FC40C2D4.9F131710.31D5BF7F.46E5F9ED.20275; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/lfsywbgEgd8WpHwcbyvTDBbZTMI Subject: [Json] comments on Ihttp://tools.ietf.org/html/draft-bray-i-json-01 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 04:50:22 -0000 I have trouble with lots of the normative language in the I-JSON spec. If you're defining a profile, then go ahead and define the set of values that are allowed and define values that generators MUST NOT generate in order to be conforming, and the cases where parsers which are checking=20 for conformance to the profile MUST check. So: numbers:=20 > Implementations which generate I-JSON messages MUST NOT assume that > receiving implementations can process numeric values with greater > magnitude or precision than provided by those numbers. As written, it sounds like a constraint on the mental state of the author of the generating implementation. " MUST NOT assume that the order of object members" I think this is a constraint on receivers of JSON messages, that they MUST process all permutations equivalently. I-JSON has no length limits. Security applications probably need to agree on length limits. ---- Specifications whose messages are specified to be I-JSON messages SHOULD specify the use of a media type of the form "application/XXX+i-json", where XXX is specific to the specification. I argued against application/i-json in the meeting, but it's not in the draft. Is there anyone who still wants it? I see no value to application/XXXX+i-json over application/XXX+json since any application needs to define additional constraaints. For example, i-json has no length limits, while any practical implementation will have some, and security applications that want to insist on consistent behavior will need length limits. Larry -- http://larry.masinter.net From nobody Sun Mar 9 01:16:07 2014 Return-Path: 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 EFE5A1A01BB for ; Sat, 8 Mar 2014 20:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001] 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 x9KrkIH_C5jt for ; Sat, 8 Mar 2014 20:27:16 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 27FBA1A01AF for ; Sat, 8 Mar 2014 20:27:15 -0800 (PST) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB324.namprd02.prod.outlook.com (10.141.91.26) with Microsoft SMTP Server (TLS) id 15.0.888.9; Sun, 9 Mar 2014 04:27:09 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Sun, 9 Mar 2014 04:27:09 +0000 From: Larry Masinter To: "Paul E. Jones" , "Joe Hildebrand (jhildebr)" , Tim Bray Thread-Topic: serializing sequences of JSON values Thread-Index: Ac87TsixeUQAkrJATR2RmgrqNDBDCA== Date: Sun, 9 Mar 2014 04:27:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [204.239.250.1] x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(49866001)(74662001)(47736001)(85306002)(50986001)(47446002)(74502001)(47976001)(85852003)(83072002)(80022001)(95416001)(66066001)(74876001)(65816001)(4396001)(81816001)(92566001)(558084003)(95666003)(2656002)(90146001)(56816005)(87266001)(81342001)(69226001)(74316001)(81542001)(87936001)(74366001)(77982001)(76576001)(76786001)(80976001)(59766001)(76796001)(79102001)(93136001)(97186001)(83322001)(76176001)(86362001)(97336001)(93516002)(33646001)(63696002)(31966008)(74706001)(94946001)(54356001)(53806001)(54316002)(76482001)(51856001)(81686001)(46102001)(94316002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB324; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:204.239.250.1; FPR:DC97F5DF.A93403E3.2E3B38A.DC6FA2F2.200A6; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/f0J7-ZrvzO0ig6tbu5LUXjvWbKE X-Mailman-Approved-At: Sun, 09 Mar 2014 01:16:03 -0800 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" Subject: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 04:27:19 -0000 PiAgVGhpcyBtZWFucyB0aGUgc2VyaWFsaXplciB3b3VsZCBoYXZlIHRvIGJlIGV4cGxpY2l0bHkg dG9sZCB3aGV0aGVyIHRvIGluc2VydCBzcGFjZSBiZWZvcmUgb3IgYWZ0ZXINCj4gd3JpdGluZyBv dXQgZGF0YS4gIA0KDQpJZiB5b3Ugd2FudCB0byB3cml0ZSBvdXQgYSBzZXF1ZW5jZSBvZiBKU09O IHZhbHVlcyB5b3Ugd291bGQgd3JpdGUgdGhlbSBvdXQgYXMgYW4gYXJyYXkgd2l0aCBbXSBhcm91 bmQgYW5kIGNvbW1hIHNlcGFyYXRvcnMuDQoNCg0KDQo= From nobody Sun Mar 9 08:08:23 2014 Return-Path: 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 CE4F91A0204 for ; Sun, 9 Mar 2014 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 URacZhHb-rkl for ; Sun, 9 Mar 2014 07:36:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7871A013F for ; Sun, 9 Mar 2014 07:36:23 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WMepk-00048X-9R; Sun, 09 Mar 2014 10:36:08 -0400 Date: Sun, 9 Mar 2014 10:36:08 -0400 From: John Cowan To: Larry Masinter Message-ID: <20140309143608.GA14656@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/5HKxAzePQZSZ2rtAgMrVtOgpuKk X-Mailman-Approved-At: Sun, 09 Mar 2014 08:08:20 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 14:36:26 -0000 Larry Masinter scripsit: > If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators. That would be a single JSON value, not a sequence thereof. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org From nobody Sun Mar 9 08:37:44 2014 Return-Path: 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 233071A0268 for ; Sun, 9 Mar 2014 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5L0hjaAeljNT for ; Sun, 9 Mar 2014 08:37:40 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 554DF1A0237 for ; Sun, 9 Mar 2014 08:37:40 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hq11so6269397vcb.28 for ; Sun, 09 Mar 2014 08:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uVwG6BavoyG8Yd9xlIMEFIQa3cEAe5FMZpz8oGIs+Pw=; b=YB4Vei5jqyQ1eUft1UxM3tG/LLz0CMsj4EOFnq9241XuBEjx9V+N7dHvFv7FKxmmS2 wZz43bvF2r9ElMorlm/jyQiJaRlDddi+KnZJtUoSd4D8Y8scLTAFDup3rEdOtGKUkpSp vwDrra7+1jtF8xOkfycJTDE7gQ1fhjnE7R3tgA6H1VE50rzZXofC+8E5/aK6vVtraL0W k2AGz5NNo9GhJIfKnkq6YmkkdUGdbbc7VSxF0bpjKs1wJ4/wZQtR8oHnL7XE7K4LXE4T Rk7fW3tULZlTyXJtZJxZrWRpbR00qmq7zWrhVtSBZJu3XoWYtSYQRwBeWlx7ph7Nc7pX ocoQ== X-Gm-Message-State: ALoCoQlxLJXkwuZ500NcudY499Q2+z6I7nMza/do5Hycz1rxAql3YAsNhIMiuRkdxWtszzH2e3O9 MIME-Version: 1.0 X-Received: by 10.58.133.15 with SMTP id oy15mr18406603veb.19.1394379455001; Sun, 09 Mar 2014 08:37:35 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Sun, 9 Mar 2014 08:37:34 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Sun, 9 Mar 2014 08:37:34 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6d9f8219212904f42e4400 Archived-At: http://mailarchive.ietf.org/arch/msg/json/jjtQS1KZNn0gF4q5cBbee79uJZI Subject: [Json] The London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 15:37:42 -0000 --047d7b6d9f8219212904f42e4400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was sort of hoping the chairs would take the sense of the WG as to whether we should proceed with a re-chartering based on I-JSON + maybe nomenclature. There was lots of discussion on the bits of I-JSON that need discussion, but very little on =E2=80=9Cis this worth specifying?=E2=80=9D To our chairs: Your sense of this issue? --047d7b6d9f8219212904f42e4400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was sort of hoping the chairs would take the sense of th= e WG as to whether we should proceed with a re-chartering based on I-JSON += maybe nomenclature. =C2=A0There was lots of discussion on the bits of I-JS= ON that need discussion, but very little on =E2=80=9Cis this worth specifyi= ng?=E2=80=9D

To our chairs: Your sense of this issue?
--047d7b6d9f8219212904f42e4400-- From nobody Sun Mar 9 09:02:19 2014 Return-Path: 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 493AE1A0268 for ; Sun, 9 Mar 2014 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.208 X-Spam-Level: * X-Spam-Status: No, score=1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BIGGERMEM1=2.555, HELO_MISMATCH_COM=0.553] autolearn=no 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 sKD8VnKet5Kh for ; Sun, 9 Mar 2014 09:02:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 08C2C1A0262 for ; Sun, 9 Mar 2014 09:02:17 -0700 (PDT) Received: from [192.168.1.27] (host86-189-7-81.range86-189.btcentralplus.com [86.189.7.81]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s29G261O044742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Mar 2014 09:02:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host host86-189-7-81.range86-189.btcentralplus.com [86.189.7.81] claimed to be [192.168.1.27] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sun, 9 Mar 2014 16:02:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7087186A-DA29-41A1-9D4F-94DA15053D9D@vpnc.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/SOQZraFBKkLFqJ2e2hQ7o_Vseh4 Cc: "json@ietf.org" Subject: Re: [Json] The London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:02:18 -0000 On Mar 9, 2014, at 3:37 PM, Tim Bray wrote: > I was sort of hoping the chairs would take the sense of the WG as to = whether we should proceed with a re-chartering based on I-JSON + maybe = nomenclature. There was lots of discussion on the bits of I-JSON that = need discussion, but very little on =93is this worth specifying?=94 >=20 > To our chairs: Your sense of this issue? Matt said (after you had boarded a plane) that we need to discuss this = on the mailing list. We have a much larger set of members who don't come = to meetings than those in London. --Paul Hoffman From nobody Sun Mar 9 19:01:44 2014 Return-Path: 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 154DE1A0388 for ; Sun, 9 Mar 2014 19:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 OwIhrzXdnZ41 for ; Sun, 9 Mar 2014 19:01:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC21A0390 for ; Sun, 9 Mar 2014 19:01:40 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB323.namprd02.prod.outlook.com (10.141.91.18) with Microsoft SMTP Server (TLS) id 15.0.893.10; Mon, 10 Mar 2014 02:01:34 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Mon, 10 Mar 2014 02:01:34 +0000 From: Larry Masinter To: Tim Bray , "json@ietf.org" Thread-Topic: [Json] The London meeting Thread-Index: AQHPO63SLJH4uoC8/0WQSsofERHmWZrZkGEQ Date: Mon, 10 Mar 2014 02:01:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(377454003)(2656002)(95666003)(92566001)(74662001)(31966008)(63696002)(16236675002)(81816001)(94946001)(87936001)(19300405004)(97336001)(85306002)(94316002)(97186001)(74876001)(74502001)(81542001)(95416001)(87266001)(15975445006)(49866001)(56816005)(74706001)(83072002)(74316001)(56776001)(74366001)(47736001)(81342001)(54316002)(93516002)(66066001)(46102001)(65816001)(85852003)(93136001)(15202345003)(59766001)(77982001)(80022001)(83322001)(47976001)(79102001)(90146001)(16601075003)(4396001)(80976001)(19580395003)(69226001)(76482001)(81686001)(54356001)(53806001)(86362001)(51856001)(19580405001)(50986001)(33646001)(76796001)(76786001)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB323; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:FC7EF697.BCF657D9.B9F47570.4C622D32.20216; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_c6dc523d00ac4619a7d12dcd7bb6f90eBL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/RSlyxGssKPsnZ4zHxr0dribj3Uo Subject: Re: [Json] The London meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 02:01:43 -0000 --_000_c6dc523d00ac4619a7d12dcd7bb6f90eBL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBqdXN0IHdvbmRlciBpZiB3aGF04oCZcyBuZWVkZWQgaXMgYSBzaW5nbGUgcHJvZmlsZS4NCg0K Rm9yIGV4YW1wbGUsIHNlY3VyaXR5LWNvbnNjaW91cyBhcHBsaWNhdGlvbnMgd2hpY2ggYXJlIGNv bmNlcm5lZCBhYm91dCBzcG9vZmluZyAtLSB0aGF0IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMg b2YgSlNPTi5wYXJzZShzdHJpbmcgQSkgdnMuIEpTT04ucGFyc2Uoc3RyaW5nIEIpIHdpbGwgeWll bGQgZGlmZmVyZW50IGFuc3dlcnMgdG8gd2hldGhlciB0aG9zZSBhcmUgZXF1aXZhbGVudCDigJMg bWlnaHQgZ2l2ZSBkaWZmZXJlbnQgYW5zd2Vycy4NCg0KSWYgdGhlIGdvYWwgaXMgdG8gaW5zdXJl IHRoYXQgZG9lc27igJl0IGhhcHBlbiwgeW91IHNob3VsZCBzdGF0ZSB0aGUgZ29hbC4gUmlnaHQg bm93IOKAnGlzIHRoaXMgd29ydGggc3BlY2lmeWluZz/igJ0gc2VlbXMgdW5zdXBwb3J0ZWQgYnkg Y29uY3JldGUgdXNlIGNhc2VzLiBFdmVuIGFuIGluZm9ybWF0aW9uYWwgYmFja2dyb3VuZCByZWZl cmVuY2UgZm9yIGp1c3RpZmljYXRpb24gd291bGQgaGVscC4NCg0KDQoNCg0KLS0NCmh0dHA6Ly9s YXJyeS5tYXNpbnRlci5uZXQNCg0KRnJvbToganNvbiBbbWFpbHRvOmpzb24tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBTdW5kYXksIE1hcmNoIDA5LCAyMDE0 IDg6MzggQU0NClRvOiBqc29uQGlldGYub3JnDQpTdWJqZWN0OiBbSnNvbl0gVGhlIExvbmRvbiBt ZWV0aW5nDQoNCkkgd2FzIHNvcnQgb2YgaG9waW5nIHRoZSBjaGFpcnMgd291bGQgdGFrZSB0aGUg c2Vuc2Ugb2YgdGhlIFdHIGFzIHRvIHdoZXRoZXIgd2Ugc2hvdWxkIHByb2NlZWQgd2l0aCBhIHJl LWNoYXJ0ZXJpbmcgYmFzZWQgb24gSS1KU09OICsgbWF5YmUgbm9tZW5jbGF0dXJlLiAgVGhlcmUg d2FzIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgYml0cyBvZiBJLUpTT04gdGhhdCBuZWVkIGRp c2N1c3Npb24sIGJ1dCB2ZXJ5IGxpdHRsZSBvbiDigJxpcyB0aGlzIHdvcnRoIHNwZWNpZnlpbmc/ 4oCdDQoNClRvIG91ciBjaGFpcnM6IFlvdXIgc2Vuc2Ugb2YgdGhpcyBpc3N1ZT8NCg== --_000_c6dc523d00ac4619a7d12dcd7bb6f90eBL2PR02MB307namprd02pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBqdXN0IHdvbmRlciBpZiB3aGF04oCZcyBuZWVkZWQgaXMgYSBzaW5nbGUgcHJvZmlsZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkZvciBleGFtcGxlLCBzZWN1cml0eS1jb25zY2lvdXMgYXBwbGljYXRpb25zIHdoaWNo IGFyZSBjb25jZXJuZWQgYWJvdXQgc3Bvb2ZpbmcgLS0gdGhhdCBkaWZmZXJlbnQgaW1wbGVtZW50 YXRpb25zIG9mIEpTT04ucGFyc2Uoc3RyaW5nIEEpIHZzLiBKU09OLnBhcnNlKHN0cmluZw0KIEIp IHdpbGwgeWllbGQgZGlmZmVyZW50IGFuc3dlcnMgdG8gd2hldGhlciB0aG9zZSBhcmUgZXF1aXZh bGVudCDigJMgbWlnaHQgZ2l2ZSBkaWZmZXJlbnQgYW5zd2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBn b2FsIGlzIHRvIGluc3VyZSB0aGF0IGRvZXNu4oCZdCBoYXBwZW4sIHlvdSBzaG91bGQgc3RhdGUg dGhlIGdvYWwuIFJpZ2h0IG5vdyDigJxpcyB0aGlzIHdvcnRoIHNwZWNpZnlpbmc/4oCdIHNlZW1z IHVuc3VwcG9ydGVkIGJ5IGNvbmNyZXRlIHVzZSBjYXNlcy4gRXZlbg0KIGFuIGluZm9ybWF0aW9u YWwgYmFja2dyb3VuZCByZWZlcmVuY2UgZm9yIGp1c3RpZmljYXRpb24gd291bGQgaGVscC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmh0dHA6Ly9sYXJyeS5tYXNpbnRl ci5uZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4ganNvbiBb bWFpbHRvOmpzb24tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGltIEJy YXk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAwOSwgMjAxNCA4OjM4IEFNPGJyPg0K PGI+VG86PC9iPiBqc29uQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtKc29uXSBUaGUg TG9uZG9uIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdh cyBzb3J0IG9mIGhvcGluZyB0aGUgY2hhaXJzIHdvdWxkIHRha2UgdGhlIHNlbnNlIG9mIHRoZSBX RyBhcyB0byB3aGV0aGVyIHdlIHNob3VsZCBwcm9jZWVkIHdpdGggYSByZS1jaGFydGVyaW5nIGJh c2VkIG9uIEktSlNPTiAmIzQzOyBtYXliZSBub21lbmNsYXR1cmUuICZuYnNwO1RoZXJlIHdhcyBs b3RzIG9mIGRpc2N1c3Npb24gb24gdGhlIGJpdHMgb2YgSS1KU09OIHRoYXQgbmVlZCBkaXNjdXNz aW9uLCBidXQgdmVyeQ0KIGxpdHRsZSBvbiDigJxpcyB0aGlzIHdvcnRoIHNwZWNpZnlpbmc/4oCd PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBvdXIgY2hh aXJzOiBZb3VyIHNlbnNlIG9mIHRoaXMgaXNzdWU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c6dc523d00ac4619a7d12dcd7bb6f90eBL2PR02MB307namprd02pro_-- From nobody Mon Mar 10 00:55:36 2014 Return-Path: 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 38E961A025E for ; Sun, 9 Mar 2014 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 oIIBrVAq0OJf for ; Sun, 9 Mar 2014 09:41:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 985341A0277 for ; Sun, 9 Mar 2014 09:41:55 -0700 (PDT) Received: from [10.54.74.194] (161-239.197-178.cust.bluewin.ch [178.197.239.161]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s29GfNVu008279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Mar 2014 12:41:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1394383286; bh=c7FYpivKLERhVe4vjqxt20nToTbkeeSXnom5ePZVBSs=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=dQdjinJ7FOFaCE3UT++xT3+BmNVvbGeqA4C6MV9xsy5joS3OhHzIaTwLcRjlU328t 2HwLXMOkh6P/kZ7ACwaOGPA3vj3iooXf8dv/UBJbMn43ZEFj2QasSOXSKRbrt+aKkO gW8m5hiKeElwDEaUl2ILYt7LJrwAdTshak7x1qxU= User-Agent: K-9 Mail for Android In-Reply-To: <20140309143608.GA14656@mercury.ccil.org> References: <20140309143608.GA14656@mercury.ccil.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----0GIV87QKVNN717ZVMU3CEZTYZ6X22Y" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sun, 09 Mar 2014 12:41:21 -0400 To: John Cowan , Larry Masinter Message-ID: <65449749-1e0e-40c8-9277-bd255b4c302f@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/json/MyDiLchjuSaJ70Uh8I1znZarW8k X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:41:57 -0000 ------0GIV87QKVNN717ZVMU3CEZTYZ6X22Y Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Right. That gets us back to the old definition. Writing an array or object makes sense, but an integer and then another seems like it just makes things unnecessarily confusing. Somewhere, somehow there must be whitespace inserted between those. Paul -------- Original Message -------- From: John Cowan Sent: March 9, 2014 10:36:08 AM EDT To: Larry Masinter Cc: "Paul E. Jones" , "Joe Hildebrand (jhildebr)" , Tim Bray , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Matt Miller (mamille2)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values Larry Masinter scripsit: > If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators. That would be a single JSON value, not a sequence thereof. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org ------0GIV87QKVNN717ZVMU3CEZTYZ6X22Y Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Right. That gets us back to the old definition. Writing an array or object makes sense, but an integer and then another seems like it just makes things unnecessarily confusing. Somewhere, somehow there must be whitespace inserted between those.

Paul

From: John Cowan <cowan@mercury.ccil.org>
Sent: March 9, 2014 10:36:08 AM EDT
To: Larry Masinter <masinter@adobe.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, Tim Bray <tbray@textuality.com>, Pete Resnick <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>, Barry Leiba <barryleiba@computer.org>, "rfc7158@schmorp.de" <rfc7158@schmorp.de>
Subject: Re: [Json] serializing sequences of JSON values

Larry Masinter scripsit:

 If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators.

That would be a single JSON value, not a sequence thereof.
------0GIV87QKVNN717ZVMU3CEZTYZ6X22Y-- From nobody Mon Mar 10 00:55:38 2014 Return-Path: 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 481031A0268 for ; Sun, 9 Mar 2014 09:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 H8v5DBOQcjfa for ; Sun, 9 Mar 2014 09:44:40 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id ACF921A0277 for ; Sun, 9 Mar 2014 09:44:39 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so363188vcb.39 for ; Sun, 09 Mar 2014 09:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=//QypL2fAD8swhiEDD7HKLtVlq7uLy5oWtxwwqAFuyM=; b=PNFs45g05xl96g6T50+hriNieH9UqWWioMtCPh/0iucwaAH4uFxPGoeRvVQ2Vggemo 9nelGo/Yu3hn68x7VuAkMu8AbAdwh1T/Eou5+F1hcJW8SXAaaYy/eI0j7wfXbwhrshQ7 7s19QyONjyLQAQ3QnJgDvFvtSuN12eDPAsO3X8gCgAyDjMbGoxWFGUnLcyc7pYk1ZNx6 cxkiwyJOK3znK6TDXsR1qca/dYnMWIpiBz8aUbC8if6//epXv+0j9M50iRnLY4AS24IS MZNRwQCgK3N9cH3TRouEBiL8L9pxe4T5hP1B3rZ+vHIBYCPdheBL3a+3r0v7VmJORz/j 2jIQ== X-Gm-Message-State: ALoCoQmzg7P77NJJMMZCL3+aJ081JKCHshuMNOUlyoBba1TS6O/U7SP3HDr7fe4OysqrX3+i1Tm0 MIME-Version: 1.0 X-Received: by 10.220.12.140 with SMTP id x12mr18842820vcx.19.1394383474503; Sun, 09 Mar 2014 09:44:34 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Sun, 9 Mar 2014 09:44:34 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <65449749-1e0e-40c8-9277-bd255b4c302f@email.android.com> References: <20140309143608.GA14656@mercury.ccil.org> <65449749-1e0e-40c8-9277-bd255b4c302f@email.android.com> Date: Sun, 9 Mar 2014 09:44:34 -0700 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c3d97cadcb2304f42f3342 Archived-At: http://mailarchive.ietf.org/arch/msg/json/6g0FJuICB5F5JQgdlj8qAelOBvQ X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Barry Leiba , John Cowan , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , Larry Masinter , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , "json@ietf.org" , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 16:44:42 -0000 --001a11c3d97cadcb2304f42f3342 Content-Type: text/plain; charset=UTF-8 So, all the specifications are now consistent, which is a good thing, but note the advice in the spec: If you want interoperability, use a list or an object. -T On Sun, Mar 9, 2014 at 9:41 AM, Paul E. Jones wrote: > Right. That gets us back to the old definition. Writing an array or object > makes sense, but an integer and then another seems like it just makes > things unnecessarily confusing. Somewhere, somehow there must be whitespace > inserted between those. > > Paul > > ------------------------------ > *From:* John Cowan > *Sent:* March 9, 2014 10:36:08 AM EDT > *To:* Larry Masinter > *Cc:* "Paul E. Jones" , "Joe Hildebrand > (jhildebr)" , Tim Bray , Pete > Resnick , Bjoern Hoehrmann , > Paul Hoffman , "json@ietf.org" , > "Matt Miller (mamille2)" , Barry Leiba < > barryleiba@computer.org>, "rfc7158@schmorp.de" > *Subject:* Re: [Json] serializing sequences of JSON values > > Larry Masinter scripsit: > > If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators. >> > > That would be a single JSON value, not a sequence thereof. > > --001a11c3d97cadcb2304f42f3342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So,= all the specifications are now consistent, which is a good thing, but note= the advice in the spec: If you want interoperability, use a list or an obj= ect. =C2=A0-T


On Sun,= Mar 9, 2014 at 9:41 AM, Paul E. Jones <paulej@packetizer.com><= /span> wrote:
Right. That gets us back to the old def= inition. Writing an array or object makes sense, but an integer and then a= nother seems like it just makes things unnecessarily confusing. Somewhere,= somehow there must be whitespace inserted between those.

Paul

From: John Cowan <cowan@mercury.ccil.org>
Sent: March 9, 2014 10:36:08 AM EDT
To: Larry Masinter <masinter@adobe.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, "Joe Hildebran= d (jhildebr)" <jhildebr@cisco.com>, Tim Bray <tbray@textuality.com>, Pete Resnick <= presnick@qti= .qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.= org" <json@i= etf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>, Barry Leib= a <barrylei= ba@computer.org>, "rfc7158@schmorp.de" <rfc7158@schmorp.de>
Subject: Re: [Json] serializing sequences of JSON values

Larry Masinter scripsit:

 If you want to write out a sequence of JSON values you would write them=
 out as an array with [] around and comma separators.



That would be a single JSON value, not a sequence thereof.=

--001a11c3d97cadcb2304f42f3342-- From nobody Mon Mar 10 00:55:40 2014 Return-Path: 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 86DC71A028B for ; Sun, 9 Mar 2014 10:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 TrTHqA9LG54o for ; Sun, 9 Mar 2014 10:33:35 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E343E1A0064 for ; Sun, 9 Mar 2014 10:33:34 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so7437419wes.16 for ; Sun, 09 Mar 2014 10:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=as5dik2xHhmFAP8Ym70eNaW9aILFYVWl3JAaaC+RIkA=; b=NK2AbuPuUGa5AnuTWWKzbjn1ACYy/YcF4A0epMd/Vj1vFTvaap+SGs/+v8xq1sSni+ DhMW12Wj/Vv9iFqt5eyNEJKdqkvTPyXylHf/S5LvtWHKIMz8lMtHiuNVXSh/fQwM6Ird J5yBshcYrwJUVF7jhCPYtqvGIcIU2hTfdPAzkdZDmLyR2Ie8Oz3ie3bblB/1g85jK/Gj U4ejpb3/X2gLIRK0Sfe9DqWCMADXvD1F1A/7eBSjsIbSAcWmxc6IL0SAqLdRPMiH1hVC CjlH2G0YqVHmHTZbuFGoJWAkRdWv7Z458ib8R7WMZ5CEQtHEHm9R59tK9Zt+5QtGG9rU fpGw== MIME-Version: 1.0 X-Received: by 10.180.7.130 with SMTP id j2mr6090016wia.25.1394386409485; Sun, 09 Mar 2014 10:33:29 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Sun, 9 Mar 2014 10:33:29 -0700 (PDT) In-Reply-To: <20140309143608.GA14656@mercury.ccil.org> References: <20140309143608.GA14656@mercury.ccil.org> Date: Sun, 9 Mar 2014 17:33:29 +0000 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=f46d044287d89dfd6904f42fe2ed Archived-At: http://mailarchive.ietf.org/arch/msg/json/W2WT5rprPlAlMkOltjJgduT9Z78 X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Barry Leiba , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Larry Masinter , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 17:33:37 -0000 --f46d044287d89dfd6904f42fe2ed Content-Type: text/plain; charset=ISO-8859-1 The way real-life serializers do this is to keep track of state. If a root value has been output, then insert a separator. If not, then not. Expecting caller to pass this state would indeed be silly. I still find it fascinating how much of discussion is based on theoretical aspect of ifs, whys and maybes. But not in observing how things have been done for years now. -+ Tatu +- On Sun, Mar 9, 2014 at 2:36 PM, John Cowan wrote: > Larry Masinter scripsit: > > > If you want to write out a sequence of JSON values you would write them > out as an array with [] around and comma separators. > > That would be a single JSON value, not a sequence thereof. > > -- > Income tax, if I may be pardoned for saying so, John Cowan > is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --f46d044287d89dfd6904f42fe2ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The way real-life serializers do this is to keep trac= k of state. If a root value has been output, then insert a separator. If no= t, then not. Expecting caller to pass this state would indeed be silly.

I still find it fascinating how much of discussion is based = on theoretical aspect of ifs, whys and maybes. But not in observing how thi= ngs have been done for years now.

-+ Tatu +-



On = Sun, Mar 9, 2014 at 2:36 PM, John Cowan <cowan@mercury.ccil.org&g= t; wrote:
Larry Masinter scripsit:

> If you want to write out a sequence of JSON values you would write the= m out as an array with [] around and comma separators.

That would be a single JSON value, not a sequence thereof.

--
Income tax, if I may be pardoned for saying so, =A0 =A0 =A0 =A0 John Cowan<= br> is a tax on income. =A0--Lord Macnaghten (1901) =A0 =A0 =A0 =A0 =A0 cowan@ccil.org

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--f46d044287d89dfd6904f42fe2ed-- From nobody Mon Mar 10 00:55:42 2014 Return-Path: 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 B67511A022C for ; Sun, 9 Mar 2014 15:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.209 X-Spam-Level: **** X-Spam-Status: No, score=4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 Uv3BXrxy1_zR for ; Sun, 9 Mar 2014 15:37:06 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id D805A1A0225 for ; Sun, 9 Mar 2014 15:37:06 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id DF5AB31805C for ; Sun, 9 Mar 2014 15:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vJRSWM+GQ9MNJZ1KbmzW xh6/MUQ=; b=slwt6rRHXeK/+k9a4Rb/a4lEhc5zzjnJwDejBYQP9XuwrUBAroUa 0ncDLZEl2SzHB6hGVV2UVjzvmck3hHfA607cXMShXtLtf+SGEh/VD9FbJfCwhXfB 6yh1q/gWNiGNg6vIE050KDGxIfgf4syflXygXLGGk9EC0+jN+eezaww= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 903D5318059 for ; Sun, 9 Mar 2014 15:37:01 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so7722238wgg.13 for ; Sun, 09 Mar 2014 15:37:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d/NvExpfWeZWW5BeGZnqavIJ6x/CR07mtSEdny93gnM=; b=l1oTH71H0RXLnLLKSMrMX1jAUX6dzHz3IYAWVJ891K9ULTE2B3KqgpqOu/LzFVwq++ dYPGejVRvIDr5dDIniZA900nxMEVS9XKGPvU1ueJTFYvB0D9vnEmHE5J+o6mgWHCLX2Q TDXzKgPKSs3z/hwQrr/iK1rRCQxGTbGtUwbpuA1ANXC6CaRitd58wsuT/wY8lrOUPz7R PVx+JHgyaenTI86kYwUsMjZC5IkiSMd3kTC2l/YabrjUXo+FHt+ISwPHCgg5xX+oLHtL rSvFydYsz5l2tTrs3QrVq8SQfvr/KJr2vjL+x2MjbRNg3D87fz0LRatuJJ7Dp0KRfE/A F1AA== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr5707515wij.42.1394404620534; Sun, 09 Mar 2014 15:37:00 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 9 Mar 2014 15:37:00 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 9 Mar 2014 15:37:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Mar 2014 17:37:00 -0500 Message-ID: From: Nico Williams To: Larry Masinter Content-Type: multipart/alternative; boundary=e89a8f5032e214881b04f434201f Archived-At: http://mailarchive.ietf.org/arch/msg/json/Tff0su-7NB8KFvtwFIMu9QbKmJI X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 22:37:07 -0000 --e89a8f5032e214881b04f434201f Content-Type: text/plain; charset=UTF-8 On Mar 9, 2014 4:16 AM, "Larry Masinter" wrote: > > > This means the serializer would have to be explicitly told whether to insert space before or after > > writing out data. > > If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators. Doesn't work for log files... --e89a8f5032e214881b04f434201f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 9, 2014 4:16 AM, "Larry Masinter" <masinter@adobe.com> wrote:
>
> > =C2=A0This means the serializer would have to be explicitly told = whether to insert space before or after
> > writing out data.
>
> If you want to write out a sequence of JSON values you would write the= m out as an array with [] around and comma separators.

Doesn't work for log files...

--e89a8f5032e214881b04f434201f-- From nobody Mon Mar 10 00:55:50 2014 Return-Path: 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 BE79E1A03B9 for ; Sun, 9 Mar 2014 20:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 3s0CifBIupb5 for ; Sun, 9 Mar 2014 20:38:05 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 009811A03BA for ; Sun, 9 Mar 2014 20:38:04 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id e9so6991628qcy.40 for ; Sun, 09 Mar 2014 20:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CBTBkv50sY3ImZbdthL5zxx7tpY5s3O/rkR89U5wFS4=; b=Sxos/FEXMyTQzDhtxfj3CCKSUmOu/A/xBt+HUKUP3+H2p92+rBobc+nALlE+O3t2BC ylgnBQYSz3XDFhfpDR6GhUqBTmruVHe/zan1SQ8XhKiRWzTBVcnMn05DBCFLTa7OBOc9 DTPsB8GRgcbvf5FAkycWoM6jx+dN5xb3cwGSSXIogEOfIu7uqsUDvhjCtOonKFRS2rGc McgMMRYljc/Yk0QB294pYaiOtXZvsP6PBCSVW2u1FBUDMsRm0VMqwbzgfWjUI3DUrHTI ZtwC30/9qkrhnsJgNi+ZRDK9KzDMyZOOv5J+F664qk5+oCYCWi66xEKPB5thtdeW6GzN a/TA== MIME-Version: 1.0 X-Received: by 10.140.32.37 with SMTP id g34mr32535117qgg.37.1394422679523; Sun, 09 Mar 2014 20:37:59 -0700 (PDT) Received: by 10.140.42.164 with HTTP; Sun, 9 Mar 2014 20:37:59 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Mar 2014 20:37:59 -0700 Message-ID: From: R S To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a1139717a7ad76f04f4385425 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4LqRPX_sMaqlHReYKtGpUtbBWxg X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Matt Miller \(mamille2\)" , Barry Leiba , "rfc7158@schmorp.de" , RFC Errata System Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 03:38:09 -0000 --001a1139717a7ad76f04f4385425 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The new RFC is backward compatible: "In telecommunications and computing, a product or technology is backward or downward compatible if it can work with input generated by an older product or technology" > this only opens the door for > future implementations to produce things that do not work reliably. Nope. This door has been wide open for quite some time, as both the new and old RFC state: "A JSON parser MAY accept non-JSON forms or extensions." - Rob On Fri, Mar 7, 2014 at 5:09 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Paul: ECMA's version of JSON has allowed anything at the top level for > quite a while. The WG explicitly decided that having the two specs in > sync was more important to us than the backward-compatility issue, which > we documented. This isn't a "mistake" in the sense that we didn't know i= t > was happening - it was the consensus of the people who were participating= . > > > On 3/4/14 8:12 PM, "Paul E. Jones" wrote: > > >Tim, > > > >Yeah, I saw that. However, I still think this only opens the door for > >future implementations to produce things that do not work reliably. As > >Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears t= o > >have disappeared), a serializer that > > is requested to serialize a series of integers like 1 and 999 might > >produce 1999. Reading that back in, the single value 1999 would be read= . > > Likewise, a serializer might produce truefalse as output, but then fail > >when one tries to read that back. One might > > argue to start all serialization with whitespace to avoid having values > >serialized adjacent to each other. That would work, but unfortunate. > > > >Maybe I missed it, but I could not see _why_ the change was made to this > >production. What was wrong with allowing only an object or array? > > > >Looking at some of the messages hanging off of the link Bj=F6rn provided= , I > >can see people are worried, too, about the BOM. The previous text made > >it very clear how to determine whether the text is UTF-16LE or UTF-16BE, > >for example. That text seems to > > have disappeared. Is there a reason? I think the same approach spelle= d > >out in Section 3 of RFC 4627 would still work, no? > > > >Paul > > > >------ Original Message ------ > >From: "Tim Bray" > >To: "Paul E. Jones" > >Cc: "Bjoern Hoehrmann" ; "RFC Errata System" > >; "Pete Resnick" ; > > "Paul Hoffman" ; "json@ietf.org" = ; > >"Matthew Miller" ; "Barry Leiba" > >; > >rfc7158@schmorp.de > >Sent: 3/4/2014 12:27:51 PM > >Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) > > > > > >On this issue, also please read the interoperability note in the > >paragraph before the new production. > > > > > >On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones > > wrote: > > > >I've not been following the list closely, as I thought this was more of > >an editorial exercise than anything else. This is definitely more than > >editorial. This could definitely break things and the commenter is righ= t > >that there are instances where there could > > be misinterpretation. > > > >Why was it decided to change this: > > > > JSON-text =3D object / array > > > >to > > > > JSON-text =3D ws value ws > > > >Was there some misunderstanding of what 4627 said? > > > >Paul > > > >------ Original Message ------ > >From: "Bjoern Hoehrmann" > >To: "RFC Errata System" > >Cc: presnick@qti.qualcomm.com; > >paul.hoffman@vpnc.org ; json@ietf.org; > >tbray@textuality.com ; mamille2@cisco.com; > >barryleiba@computer.org; > >rfc7158@schmorp.de ; rfc-editor@rfc-editor.or= g > >Sent: 3/2/2014 4:31:07 PM > >Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907) > > > > > > > >* RFC Errata System wrote: > > > >Since RFC7158 breaks compatibility with the specifications, this should = be > >duly noted. > > > > > > > >It is in Appendix A., "Changes from RFC 4627": > > > > o Changed the definition of "JSON text" so that it can be any JSON > > value, removing the constraint that it be an object or array. > > > >Failing to note this in the Introduction is not ideal, but the errata > >system is not a good place to record that (holding it for document up- > >date probably does not make sense, if and when the document does get > >updated, this particular issue will not require prominent notice). > >-- > >Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 > >http://bjoern.hoehrmann.de > >Am Badedeich 7 =B7 Telefon: > >+49(0)160/4415681 =B7 > >http://www.bjoernsworld.de > >25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 > >http://www.websitedev.de/ > > > > > > > >_______________________________________________ > >json mailing list > >json@ietf.org > >https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a1139717a7ad76f04f4385425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The = new RFC is backward compatible:

<= div class=3D"gmail_quote">"In telecommunications and computing, a prod= uct or technology is backward or downward compatible if it can work with in= put generated by an older product or technology"
<http://en.wikipedia.org/wiki/Backward_compatibility= >

&= gt; this only opens the door for
> future implementations to produce things that do not work reliably.

Nope. Th= is door has been wide open for quite some time, as both the new and old RFC= state:

"A JSON parser MAY accept non-JSON= forms or extensions."

- Rob

On Fri= , Mar 7, 2014 at 5:09 AM, Joe Hildebrand (jhildebr) <<= a href=3D"mailto:jhildebr@cisco.com" target=3D"_blank">jhildebr@cisco.com> wrote:
Paul: ECMA's version of JSON has allowed anything at t= he top level for
quite a while. =A0The WG explicitly decided that having the two specs in sync was more important to us than the backward-compatility issue, which we documented. =A0This isn't a "mistake" in the sense that we= didn't know it
was happening - it was the consensus of the people who were participating.<= br>

On 3/4/14 8:12 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:

>Tim,
>
>Yeah, I saw that. =A0However, I still think this only opens the door fo= r
>future implementations to produce things that do not work reliably. =A0= As
>Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears = to
>have disappeared), a serializer that
> is requested to serialize a series of integers like 1 and 999 might >produce 1999. =A0Reading that back in, the single value 1999 would be r= ead.
> Likewise, a serializer might produce truefalse as output, but then fai= l
>when one tries to read that back. =A0One might
> argue to start all serialization with whitespace to avoid having value= s
>serialized adjacent to each other. =A0That would work, but unfortunate.=
>
>Maybe I missed it, but I could not see _why_ the change was made to thi= s
>production. =A0What was wrong with allowing only an object or array? >
>Looking at some of the messages hanging off of the link Bj=F6rn provide= d, I
>can see people are worried, too, about the BOM. =A0The previous text ma= de
>it very clear how to determine whether the text is UTF-16LE or UTF-16BE= ,
>for example. =A0That text seems to
> have disappeared. =A0Is there a reason? =A0I think the same approach s= pelled
>out in Section 3 of RFC 4627 would still work, no?
>
>Paul
>
>------ Original Message ------
>From: "Tim Bray" <tbray@textuality.com>
>To: "Paul E. Jones" <paulej@packetizer.com>
>Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>; "RFC Errata System"
><rfc-editor@rfc-editor.= org>; "Pete Resnick" <presnick@qti.qualcomm.com>;
> "Paul Hoffman" <= paul.hoffman@vpnc.org>; "json@= ietf.org" <json@ietf.org&g= t;;
>"Matthew Miller" <ma= mille2@cisco.com>; "Barry Leiba"
><barryleiba@computer.org<= /a>>;
>rfc7158@schmorp.de
>Sent: 3/4/2014 12:27:51 PM
>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
>
>
>On this issue, also please read the interoperabil= ity note in the
>paragraph before the new production.
>
>
>On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones
><paulej@packetizer.com&= gt; wrote:
>
>I've not been following the list closely, as I thought this was mor= e of
>an editorial exercise than anything else. =A0This is definitely more th= an
>editorial. =A0This could definitely break things and the commenter is r= ight
>that there are instances where there could
> be misinterpretation.
>
>Why was it decided to change this:
>
> =A0 =A0JSON-text =3D object / array
>
>to
>
> =A0 =A0JSON-text =3D ws value ws
>
>Was there some misunderstanding of what 4627 said?
>
>Paul
>
>------ Original Message ------
>From: "Bjoern Hoehrmann" <derhoermi@gmx.net>
>To: "RFC Errata System" <rfc-editor@rfc-editor.org>
>Cc: presnick@qti.qualcomm.= com;
>paul.hof= fman@vpnc.org <mailto:paul.= hoffman@vpnc.org>; json@ietf.org;
>tbray@textuality.com <ma= ilto:tbray@textuality.com>; = mamille2@cisco.com;
>barryleiba@computer.org;=
>rfc7158@schmorp.de <mailto= :rfc7158@schmorp.de>; rfc-editor@rfc-editor.org
>Sent: 3/2/2014 4:31:07 PM
>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
>
>
>
>* RFC Errata System wrote:
>
>Since RFC7158 breaks compatibility with the specifications, this should= be
>duly noted.
>
>
>
>It is in Appendix A., "Changes from RFC 4627":
>
> =A0 o Changed the definition of "JSON text" so that it can b= e any JSON
> =A0 =A0 =A0value, removing the constraint that it be an object or arra= y.
>
>Failing to note this in the Introduction is not ideal, but the errata >system is not a good place to record that (holding it for document up-<= br> >date probably does not make sense, if and when the document does get >updated, this particular issue will not require prominent notice).
>--
>Bj=F6rn H=F6hrmann =B7 mailto:bj= oern@hoehrmann.de =B7
>http://b= joern.hoehrmann.de <http://bjoern.hoehrmann.de/>
>Am Badedeich 7 =B7 Telefon:
>+49(0= )160/4415681 <tel:%2B49%280%29160%2F4415681> =B7
>http://www.bjo= ernsworld.de <http://www.bjoernsworld.de/>
>25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7
>http://ww= w.websitedev.de/ <http://www.websitedev.de/>
>
>
>
>_______________________________________________
>json mailing list
>json@ietf.org
>https://www.ietf.org/mailman/listinfo/json
>
>
>
>
>
>
>
>
>
>
>
>
>


--
Joe Hildebrand



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a1139717a7ad76f04f4385425-- From nobody Mon Mar 10 00:55:52 2014 Return-Path: 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 724651A03C6 for ; Sun, 9 Mar 2014 21:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 xgFkSCmpy6-3 for ; Sun, 9 Mar 2014 21:10:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 577D51A03C5 for ; Sun, 9 Mar 2014 21:10:33 -0700 (PDT) Received: from [162.188.85.210] (mb95636d0.tmodns.net [208.54.86.185]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s2A4A7dB019382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2014 00:10:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1394424614; bh=vEDazpbl/6uzveotl0PiUhiBf0MSzuCdtFGwr9CMn1Y=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=MCgM0+gMCxE9a3CKW2/lgqe8QpHK3uqmDuA7WxcJ9rjL0i5oy7IW/IlUPhynfc7SE cRkcD//degWRqUE9HDsUu81t5ecNUi/ObcYSbDKnsDTxkO3U5saYEkX2ofYPmjYWJE GGaHmxquzdV9HvWqE/3xme29qbviKwHhyoPOBn7I= User-Agent: K-9 Mail for Android In-Reply-To: References: <20140309143608.GA14656@mercury.ccil.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ZPK1JEB2KM0HBQ0XYL0RQ3345XPXB3" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Mon, 10 Mar 2014 05:10:00 +0100 To: Tatu Saloranta , John Cowan Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/json/YD1psEhh1lrbq43fXQXJnLG3Ojg X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700 Cc: Barry Leiba , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Larry Masinter , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 04:10:35 -0000 ------ZPK1JEB2KM0HBQ0XYL0RQ3345XPXB3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Those I've used keep track of state only insofar as what is required to write out an object or array. At least those I've used do not keep track of state between serialization calls. In any case, I won't keep belaboring the issue. It's done. Paul -------- Original Message -------- From: Tatu Saloranta Sent: March 9, 2014 6:33:29 PM CET To: John Cowan Cc: Larry Masinter , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand (jhildebr)" , "Matt Miller (mamille2)" , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values The way real-life serializers do this is to keep track of state. If a root value has been output, then insert a separator. If not, then not. Expecting caller to pass this state would indeed be silly. I still find it fascinating how much of discussion is based on theoretical aspect of ifs, whys and maybes. But not in observing how things have been done for years now. -+ Tatu +- On Sun, Mar 9, 2014 at 2:36 PM, John Cowan wrote: > Larry Masinter scripsit: > > > If you want to write out a sequence of JSON values you would write them > out as an array with [] around and comma separators. > > That would be a single JSON value, not a sequence thereof. > > -- > Income tax, if I may be pardoned for saying so, John Cowan > is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > ------ZPK1JEB2KM0HBQ0XYL0RQ3345XPXB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Those I've used keep track of state only insofar as what is required to write out an object or array. At least those I've used do not keep track of state between serialization calls.

In any case, I won't keep belaboring the issue. It's done.

Paul

From: Tatu Saloranta <tsaloranta@gmail.com>
Sent: March 9, 2014 6:33:29 PM CET
To: John Cowan <cowan@mercury.ccil.org>
Cc: Larry Masinter <masinter@adobe.com>, Pete Resnick <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, Tim Bray <tbray@textuality.com>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, Barry Leiba <barryleiba@computer.org>, "rfc7158@schmorp.de" <rfc7158@schmorp.de>
Subject: Re: [Json] serializing sequences of JSON values

The way real-life serializers do this is to keep track of state. If a root value has been output, then insert a separator. If not, then not. Expecting caller to pass this state would indeed be silly.

I still find it fascinating how much of discussion is based on theoretical aspect of ifs, whys and maybes. But not in observing how things have been done for years now.

-+ Tatu +-



On Sun, Mar 9, 2014 at 2:36 PM, John Cowan <cowan@mercury.ccil.org> wrote:
Larry Masinter scripsit:

> If you want to write out a sequence of JSON values you would write them out as an array with [] around and comma separators.

That would be a single JSON value, not a sequence thereof.

--
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           cowan@ccil.org

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

------ZPK1JEB2KM0HBQ0XYL0RQ3345XPXB3-- From nobody Mon Mar 10 11:16:06 2014 Return-Path: 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 CAF701A0668 for ; Mon, 10 Mar 2014 11:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.177 X-Spam-Level: * X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FRT_ADOBE2=2.455, SPF_PASS=-0.001] autolearn=no 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 iBrQdT50ErwX for ; Mon, 10 Mar 2014 11:14:55 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 99D221A04E7 for ; Mon, 10 Mar 2014 11:14:55 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id x10so7390886pdj.37 for ; Mon, 10 Mar 2014 11:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=u90TbgNIp17DscybYEWeOccqICweBwa10NsWvn0nl2k=; b=wrN2PNCgSShUgPcKrIe8F+xGfedYf6JnEGL6c6FIS9JmsqchRLTFMHIvRLgbjh9HRl Egbc2AItK9ZRdxqmu5DXvjFLAEdKFYEcKvSdO1pkk3DK6EgE9mVE644Kgan7PLgnou9m LbaxZ4Edqe+7y+iLVPOtb3MQX1KETYR4NS2ZssHkgSFXYcr1hFy/Pjo1Npjq9xqPrpVr 5GPbCfP1N9ks/ZsDms9WDZZwG7pBCgc3zAZqVPp9YZn0AZTxxiH2cpaodtvrcID5ckSq goeESxQScu+iGEvYOnTjfbnTVZnblN2aCcpjxnaHbenkAKEVnqqYeZRv80MjupGA4K4F p89A== X-Received: by 10.66.250.202 with SMTP id ze10mr5399067pac.153.1394475289648; Mon, 10 Mar 2014 11:14:49 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.7.5 with HTTP; Mon, 10 Mar 2014 11:14:29 -0700 (PDT) In-Reply-To: References: From: Jacob Davies Date: Mon, 10 Mar 2014 11:14:29 -0700 X-Google-Sender-Auth: lx4pDCatJGkvsVJ2eX8Bv54WP_g Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/9hvA2JOr3Uex80M_QKU4jGRrwuE X-Mailman-Approved-At: Mon, 10 Mar 2014 11:16:03 -0700 Cc: Barry Leiba , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Larry Masinter , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:14:57 -0000 Does either the old or new specification say anything about multiple values in sequence? I'm pretty darn sure the old version at least said that application/json documents contain one and only one value, and says nothing about serializing JSON in other formats, so encapsulation is not addressed. I also don't see how any process that expects to read sequences of self-delimited JSON objects and arrays is going to blithely accept numbers and strings and whatnot. I find the idea unlikely that there is some running code that 1. expects sequences of JSON values with no delimiters, 2. uses a parser that precisely followed the JSON specification and rejected anything but JSON objects and arrays prior to this change, 3. has that parser change under it to accept all kinds of values and 4. is so indifferent to the contents of what it is processing that it doesn't notice that it's getting numbers and strings instead of objects or arrays. On Sun, Mar 9, 2014 at 3:37 PM, Nico Williams wrote: > > On Mar 9, 2014 4:16 AM, "Larry Masinter" wrote: >> >> > This means the serializer would have to be explicitly told whether to >> > insert space before or after >> > writing out data. >> >> If you want to write out a sequence of JSON values you would write them >> out as an array with [] around and comma separators. > > Doesn't work for log files... > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Mar 10 12:17:24 2014 Return-Path: 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 793E11A050E for ; Mon, 10 Mar 2014 11:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 xKblj_zK50nL for ; Mon, 10 Mar 2014 11:47:50 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0825C1A03FC for ; Mon, 10 Mar 2014 11:47:49 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gl10so5033918lab.0 for ; Mon, 10 Mar 2014 11:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7RAmR2f6VBl4L5ko76M9NH6apGPtWdrYEPVMXBsTKo=; b=mIQGtj75CKrcVzek4/+hsyA3TPiktFDA/q6iGIYrM0Od4sMbzUsyzfVcebykAmLZ8d oR8bCTVfyqWPq3075s3zpuVH7P/psHbks7NXBrfnyVlWD9hniGq8UsgPBoBRK/8ixdTu pyy2sDuOMEZb0pkTBDaoxZ1KM42UkLuwvnCb4e6U2Pzg9h+Qk7yHVhx0ZPZr9GZ/nkXH G4gPCw0wS13cnA2HEM+vvuf+aaiqVKxJdsa3IIKPtsZj2UMKch0697b7OilGNwTVDplk oilHQTXLxo1xtwxrryGdY4ch9x7HAR87w3Afv2c9x8RsX3ZCjeETXs0z8ehVbAcpHi/J EHHg== MIME-Version: 1.0 X-Received: by 10.152.209.70 with SMTP id mk6mr12462516lac.13.1394477264008; Mon, 10 Mar 2014 11:47:44 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Mon, 10 Mar 2014 11:47:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 14:47:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11380246f7fe7d04f44509bb Archived-At: http://mailarchive.ietf.org/arch/msg/json/IhLjlXGaW4QpQbwYtPWVeEA7khg X-Mailman-Approved-At: Mon, 10 Mar 2014 12:17:21 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , Larry Masinter , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Nico Williams , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:47:52 -0000 --001a11380246f7fe7d04f44509bb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 2:14 PM, Jacob Davies wrote: > Does either the old or new specification say anything about multiple > values in sequence? I'm pretty darn sure the old version at least said > that application/json documents contain one and only one value, and > says nothing about serializing JSON in other formats, so encapsulation > is not addressed. I also don't see how any process that expects to > read sequences of self-delimited JSON objects and arrays is going to > blithely accept numbers and strings and whatnot. True, but there are multiple ways that sequences can be fashioned and this is a standards organization so we should pick exactly one separator. The log file use case is critical for me. The stupidity of the restriction in XML is tedious enough without repeating it in the JSON world. People want to write append only logs of information. So the sequence syntax does not work. Having to back up and erase the last closing square brace makes the logging process slower by an order of magnitude. At the moment I only log full objects and so there is no ambiguity. But I would much prefer to have a more general approach. I see the following options: A) Observe an implicit delimiter on sequences [...][...] or objects {...}{...} B) Observe White space as a delimiter C) Observe a comma as a delimiter These are not disjoint sets. I think I am going to change my code to accept A, B or C. However at the moment I only generate sequences consistent with A. I think that C is the approach that fits best with JSON. For better or worse, JSON uses the comma as an item separator and does not ignore superfluous entries. So this requires a little more state handling than absolutely necessary. My vote would be to require C for the log file use case for consistency but as I say, I will change my code to accept A, B or C. I find the idea > unlikely that there is some running code that 1. expects sequences of > JSON values with no delimiters, 2. uses a parser that precisely > followed the JSON specification and rejected anything but JSON objects > and arrays prior to this change, 3. has that parser change under it to > accept all kinds of values and 4. is so indifferent to the contents of > what it is processing that it doesn't notice that it's getting numbers > and strings instead of objects or arrays. I am not sure what 3 or 4 mean. But I have 1 and 2 already. The parser returns each time that a full object is read. If there is nothing to be read then it returns a null object. The encoder updates the log using append only writes that can be flagged as atomic on most O/S. -- Website: http://hallambaker.com/ --001a11380246f7fe7d04f44509bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 10, 2014 at 2:14 PM, Jacob Davies <jacob@well.com> wrot= e:
Does either the old or new specification say anything about multiple
values in sequence? I'm pretty darn sure the old version at least said<= br> that application/json documents contain one and only one value, and
says nothing about serializing JSON in other formats, so encapsulation
is not addressed. I also don't see how any process that expects to
read sequences of self-delimited JSON objects and arrays is going to
blithely accept numbers and strings and whatnot.

True, but there are multiple ways that sequences can be fashioned and= this is a standards organization so we should pick exactly one separator.= =A0

The log file use case is critical for me. The stupidity= of the restriction in XML is tedious enough without repeating it in the JS= ON world. People want to write append only logs of information. So the sequ= ence syntax does not work. Having to back up and erase the last closing squ= are brace makes the logging process slower by an order of magnitude.=A0


At the moment I only log full objects an= d so there is no ambiguity. But I would much prefer to have a more general = approach. I see the following options:

A) Observe = an implicit delimiter on sequences [...][...] or objects {...}{...}=A0

B) Observe=A0White space as a delimiter

<= /div>
C)=A0Observe=A0a comma as a delimiter

These are not disjoint sets. I think I am going to change my c= ode to accept A, B or C. However at the moment I only generate sequences co= nsistent with A.

I think that C is the approach that fits best with JSON= . For better or worse, JSON uses the comma as an item separator and does no= t ignore superfluous entries. So this requires a little more state handling= than absolutely necessary.

My vote would be to require C for the log file use case= for consistency but as I say, I will change my code to accept A, B or C.


I find the idea
unlikely that there is some running code that 1. expects sequences of
JSON values with no delimiters, 2. uses a parser that precisely
followed the JSON specification and rejected anything but JSON objects
and arrays prior to this change, 3. has that parser change under it to
accept all kinds of values and 4. is so indifferent to the contents of
what it is processing that it doesn't notice that it's getting numb= ers
and strings instead of objects or arrays.

I= am not sure what 3 or 4 mean. But I have 1 and 2 already. The parser retur= ns each time that a full object is read. If there is nothing to be read the= n it returns a null object. The encoder updates the log using append only w= rites that can be flagged as atomic on most O/S.

--
Website: ht= tp://hallambaker.com/
--001a11380246f7fe7d04f44509bb-- From nobody Mon Mar 10 12:38:44 2014 Return-Path: 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 DA5E91A04C2 for ; Mon, 10 Mar 2014 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no 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 PFioCf1Acxa2 for ; Mon, 10 Mar 2014 12:38:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EC6691A04BC for ; Mon, 10 Mar 2014 12:38:09 -0700 (PDT) Received: from [156.106.217.17] ([156.106.217.17]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s2AJZXtw020352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Mar 2014 15:35:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1394480136; bh=nYd9hjXsMO3zxQGoarCb9aKwls60GtuLgC8q5T4SLwM=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=M1TNYqiobQowxfLyVFpM4/zTlmf+T+Y9Uvee+eO2Gp3D/eNSMZ6YbFTRAlQxGZyAg fYRgxUrU/X0fD8F9fc59rNPyze73+TMtwcYCuRomYriU7/4SIrq7DeEc3BOdGIXHsY 16j0vwxHBjBqVmne0t8RUB7ahJODGG5hheA+qXY8= From: "Paul E. Jones" To: "Phillip Hallam-Baker" , "Jacob Davies" Date: Mon, 10 Mar 2014 19:35:34 +0000 Content-Type: multipart/alternative; boundary="------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.19861.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/7x9wqaB7n79my6wlGeFfL7z-RfQ X-Mailman-Approved-At: Mon, 10 Mar 2014 12:38:42 -0700 Cc: Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , Larry Masinter , "json@ietf.org" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Nico Williams , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:38:13 -0000 --------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Why would sequences of objects not be preferred for logging. If I were=20 writing to a log file, that would definitely be my preference. One=20 reason is that log files tend to have a number of pieces of information=20 to convey per entry, thus they can fit well into a JSON object (even if=20 it is a simple object). Paul ------ Original Message ------ From: "Phillip Hallam-Baker" To: "Jacob Davies" Cc: "Nico Williams" ; "Barry Leiba"=20 ; "Pete Resnick" ;=20 "Bjoern Hoehrmann" ; "Paul Hoffman"=20 ; "json@ietf.org" ; "Paul E.=20 Jones" ; "Tim Bray" ; "Joe=20 Hildebrand (jhildebr)" ; "Matt Miller (mamille2)"=20 ; "Larry Masinter" ;=20 "rfc7158@schmorp.de" Sent: 3/10/2014 2:47:43 PM Subject: Re: [Json] serializing sequences of JSON values >On Mon, Mar 10, 2014 at 2:14 PM, Jacob Davies wrote: >>Does either the old or new specification say anything about multiple >>values in sequence? I'm pretty darn sure the old version at least said >>that application/json documents contain one and only one value, and >>says nothing about serializing JSON in other formats, so encapsulation >>is not addressed. I also don't see how any process that expects to >>read sequences of self-delimited JSON objects and arrays is going to >>blithely accept numbers and strings and whatnot. > >True, but there are multiple ways that sequences can be fashioned and=20 >this is a standards organization so we should pick exactly one=20 >separator. > >The log file use case is critical for me. The stupidity of the=20 >restriction in XML is tedious enough without repeating it in the JSON=20 >world. People want to write append only logs of information. So the=20 >sequence syntax does not work. Having to back up and erase the last=20 >closing square brace makes the logging process slower by an order of=20 >magnitude. > > >At the moment I only log full objects and so there is no ambiguity. But= =20 >I would much prefer to have a more general approach. I see the=20 >following options: > >A) Observe an implicit delimiter on sequences [...][...] or objects=20 >{...}{...} > >B) Observe White space as a delimiter > >C) Observe a comma as a delimiter > > >These are not disjoint sets. I think I am going to change my code to=20 >accept A, B or C. However at the moment I only generate sequences=20 >consistent with A. > >I think that C is the approach that fits best with JSON. For better or=20 >worse, JSON uses the comma as an item separator and does not ignore=20 >superfluous entries. So this requires a little more state handling than= =20 >absolutely necessary. > >My vote would be to require C for the log file use case for consistency= =20 >but as I say, I will change my code to accept A, B or C. > > >>I find the idea >>unlikely that there is some running code that 1. expects sequences of >>JSON values with no delimiters, 2. uses a parser that precisely >>followed the JSON specification and rejected anything but JSON objects >>and arrays prior to this change, 3. has that parser change under it to >>accept all kinds of values and 4. is so indifferent to the contents of >>what it is processing that it doesn't notice that it's getting numbers >>and strings instead of objects or arrays. > >I am not sure what 3 or 4 mean. But I have 1 and 2 already. The parser=20 >returns each time that a full object is read. If there is nothing to be= =20 >read then it returns a null object. The encoder updates the log using=20 >append only writes that can be flagged as atomic on most O/S. > >-- >Website: http://hallambaker.com/ --------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Why would sequences of objects not be preferred for logging.  = If I were writing to a log file, that would definitely be my preference.&nb= sp; One reason is that log files tend to have a number of pieces of informa= tion to convey per entry, thus they can fit well into a JSON object (even= if it is a simple object).
 
Paul
 
------ Original Message ------
From: "Phillip Hallam-Baker" <h= allam@gmail.com>
To: "Jacob Davies" <jacob@well.co= m>
Cc: "Nico Williams" <nico@= cryptonector.com>; "Barry Leiba" <barryleiba@computer.org>; "Pete Resnick" <presnick@qti.qualcomm.com>; "Bjoe= rn Hoehrmann" <derhoermi@gmx.net>; "Paul Hoffman" <paul.hof= fman@vpnc.org>; "json@ietf.org" <json@ietf.org>; "Paul E. Jones" <paulej@packetizer.com>; "Tim Bray" <tbray@textuality.com>; "Joe Hildebrand (jhildeb= r)" <jhildebr@cisco.com>;= "Matt Miller (mamille2)" <mamille= 2@cisco.com>; "Larry Masinter" <masinter@adobe.com>; "rfc7158@schmorp.de" <rfc7158@schmorp.de>
Sent: 3/10/2014 2:47:43 PM
Subject: Re: [Json] serializing sequences of JSON values
 
On Mon, Mar 10, 2014 at 2:14 PM, Jacob Davies <jacob@well.com> wrote:
Does either the = old or new specification say anything about multiple
values in sequence?= I'm pretty darn sure the old version at least said
that application/jso= n documents contain one and only one value, and
says nothing about seria= lizing JSON in other formats, so encapsulation
is not addressed. I also= don't see how any process that expects to
read sequences of self-delimi= ted JSON objects and arrays is going to
blithely accept numbers and stri= ngs and whatnot.

True, but there are multiple ways that sequences can be fashioned and= this is a standards organization so we should pick exactly one separator.&= nbsp;

The log file use case is critical for me. The stupidity of the restric= tion in XML is tedious enough without repeating it in the JSON world. Peopl= e want to write append only logs of information. So the sequence syntax = does not work. Having to back up and erase the last closing square brace= makes the logging process slower by an order of magnitude. 


At the moment I only log full objects and so there is no ambiguity.= But I would much prefer to have a more general approach. I see the followi= ng options:

A) Observe an implicit delimiter on sequences [...][...] or objects= {...}{...} 

B) Observe White space as a delimiter

C) Observe a comma as a delimiter


These are not disjoint sets. I think I am going to change my code to= accept A, B or C. However at the moment I only generate sequences consiste= nt with A.

I think that C is the approach that fits best with JSON. For better= or worse, JSON uses the comma as an item separator and does not ignore = superfluous entries. So this requires a little more state handling than = absolutely necessary.

My vote would be to require C for the log file use case for consistenc= y but as I say, I will change my code to accept A, B or C.


I find the idea
= unlikely that there is some running code that 1. expects sequences of
JS= ON values with no delimiters, 2. uses a parser that precisely
followed= the JSON specification and rejected anything but JSON objects
and array= s prior to this change, 3. has that parser change under it to
accept = all kinds of values and 4. is so indifferent to the contents of
what = it is processing that it doesn't notice that it's getting numbers
and= strings instead of objects or arrays.

I am not sure what 3 or 4 mean. But I have 1 and 2 already. The parser= returns each time that a full object is read. If there is nothing to be= read then it returns a null object. The encoder updates the log using appe= nd only writes that can be flagged as atomic on most O/S.

--
Website: http://h= allambaker.com/
--------=_MB5EC454FD-3192-4B94-A6B8-35A69536920E-- From nobody Mon Mar 10 13:10:37 2014 Return-Path: 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 1CABC1A02E6 for ; Mon, 10 Mar 2014 13:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hm--8-T_SQaS for ; Mon, 10 Mar 2014 13:10:00 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A7B041A024B for ; Mon, 10 Mar 2014 13:09:59 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so4977368lab.19 for ; Mon, 10 Mar 2014 13:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q2MrgwEJA8Ozzw6V0kwlbB6eRSYfk1pjPvBOk9knh6Q=; b=R64m9AOI/4rOqxHLYvjx08Y9i+1eZ2uY+X2mqk8LM1d3+149e2U5Qu138VP55Z1bqa SBLdPDIvBcezbKfavkh1IB4WnDmWVtVLw/M7dqQYQjUZWm0CsyyqSs4FWx5sjl/nDJLO 175Fnz3sjcoGRi/KzQH++c3cJJjBg0rPuvD1WlaSuTcG23SOabK27kz9NB2eOcNI5Q2K 0Dvj5LysQXNsxSPeJBVkQ9zKhWEntr2TRc2K+LIbbCsls57ARB/LrrxRBtz2w8jIqgQG Q7CG1VqHvVEZfM4jpipHoEvrmOVct2JvKOwNnp0wgy0zYSaIyR1Te4ZgM7ZtHQjQwRkb a3iA== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr24577331lac.0.1394482193559; Mon, 10 Mar 2014 13:09:53 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Mon, 10 Mar 2014 13:09:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 16:09:53 -0400 Message-ID: From: Phillip Hallam-Baker To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a113484bccaf50004f4462f6c Archived-At: http://mailarchive.ietf.org/arch/msg/json/_yOE07jtaexuggQsh25UuowUZGs X-Mailman-Approved-At: Mon, 10 Mar 2014 13:10:32 -0700 Cc: Tim Bray , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , Larry Masinter , "json@ietf.org" , Jacob Davies , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Nico Williams , Barry Leiba , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:10:02 -0000 --001a113484bccaf50004f4462f6c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 3:35 PM, Paul E. Jones wrote: > Why would sequences of objects not be preferred for logging. If I were > writing to a log file, that would definitely be my preference. One reason > is that log files tend to have a number of pieces of information to convey > per entry, thus they can fit well into a JSON object (even if it is a > simple object). > I can't see why I would log sequences of anything other than sequences of objects. But the choice here is between one of the following forms: A) [ {..}, {..}, {..} ] B) {..}, {..}, {..} C) {..} {..} {..} Form A is not acceptable as it makes adding data to an append-only log much more complex. We can't just rely on the O/S atomic append operation. We have to manage locks etc. That is very very expensive when more than one process is allowed to write. Forms B and C are equally acceptable but C looks more like a legal JSON value. To parse B I have to write a separate parser, to parse C I use my existing JSON parser but start it in a different production. Instead of the top level production being 'object', the top level production is 'array-entries'. -- Website: http://hallambaker.com/ --001a113484bccaf50004f4462f6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 10, 2014 at 3:35 PM, Paul E. Jones <paulej@packetizer.com&= gt; wrote:
Why would sequences of objects not be preferred for logging.=A0 If I w= ere writing to a log file, that would definitely be my preference.=A0 One r= eason is that log files tend to have a number of pieces of information to c= onvey per entry, thus they can fit well into a JSON object (even if it is a= simple object).

I can't see why I would lo= g sequences of anything other than sequences of objects. But the choice her= e is between one of the following forms:

A) [ {..}= , {..}, {..} ]
B) {..}, {..}, {..}
C) {..} {..} {..}

Form A is not acceptable as it makes adding data to an append-only log m= uch more complex. We can't just rely on the O/S atomic append operation= . We have to manage locks etc. That is very very expensive when more than o= ne process is allowed to write.

Forms B and C are equally acceptable but C looks more l= ike a legal JSON value.

To parse B I have to write= a separate parser, to parse C I use my existing JSON parser but start it i= n a different production. Instead of the top level production being 'ob= ject', the top level production is 'array-entries'.


--
Website: http://hallambaker.com/
--001a113484bccaf50004f4462f6c-- From nobody Mon Mar 10 13:19:36 2014 Return-Path: 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 CAC451A0488 for ; Mon, 10 Mar 2014 13:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.77] autolearn=no 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 17mvAqW7-lex for ; Mon, 10 Mar 2014 13:19:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D08041A024B for ; Mon, 10 Mar 2014 13:19:34 -0700 (PDT) Received: from [10.207.197.255] ([109.144.231.136]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2AKJPDj007751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Mar 2014 13:19:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [109.144.231.136] claimed to be [10.207.197.255] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Mon, 10 Mar 2014 20:19:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> References: To: "json@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/7WC-c2eJkZ3iygVCPuUi_LsWF9E Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:19:36 -0000 [ Cutting off the silly Cc list... ] [ No hat ] On Mar 10, 2014, at 7:35 PM, Paul E. Jones = wrote: > Why would sequences of objects not be preferred for logging. =20 Because the log is always open for appending, so the sequence never = terminates. This, and many other related topics, were discussed at length earlier on = the mailing list and the rough consensus was that the current wording = was sufficient. --Paul Hoffman= From nobody Mon Mar 10 13:39:36 2014 Return-Path: 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 694E11A049C for ; Mon, 10 Mar 2014 13:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 c-XVLHqPwvZk for ; Mon, 10 Mar 2014 13:39:33 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 339901A024B for ; Mon, 10 Mar 2014 13:39:32 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id c11so4947154lbj.40 for ; Mon, 10 Mar 2014 13:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bb+zAa1NBqxx+A+NiTZaCfN3Vu+Tdq9yzMCHkdj0cnk=; b=k5MhGQ0qypnWN5tMYoBRXnWXXIoUq86X5eKBdxHf+NHrGnJJrJRU0OPdJp0te0Em04 94dH5xa0txMQhDoIMKcaLA0KqeR7jkw1phgrOa5c1zyn007xwBNfZNwMW0dPnrokn+Lg dj9/HtHCfcRq+UslrooWkWNF0bDrXQaSb5fYkH7S6diF5/Gv+GBBez7uX9vV1KvNeOuE /FxxtaIOUD8fKQy/c5nZViqUo1xcN3a2rusOV1WVQIbflFE15v2ik86XuF5g2tHMh830 H+o5TmZLZOY9xfle3vHKtTK2M8kFut3cGhLoYqWhpHB14pUoMhppbb1i6n8qxz4A4Pcu G6xg== MIME-Version: 1.0 X-Received: by 10.152.2.225 with SMTP id 1mr2772647lax.37.1394483966787; Mon, 10 Mar 2014 13:39:26 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Mon, 10 Mar 2014 13:39:26 -0700 (PDT) In-Reply-To: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> Date: Mon, 10 Mar 2014 16:39:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013c61a07c47b904f446996c Archived-At: http://mailarchive.ietf.org/arch/msg/json/SN7Mqdpl9ZxjGBi6wbbqb1Dwf4A Cc: "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:39:35 -0000 --089e013c61a07c47b904f446996c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 4:19 PM, Paul Hoffman wrote: > [ Cutting off the silly Cc list... ] > > [ No hat ] > > On Mar 10, 2014, at 7:35 PM, Paul E. Jones wrote: > > > Why would sequences of objects not be preferred for logging. > > Because the log is always open for appending, so the sequence never > terminates. > > This, and many other related topics, were discussed at length earlier on > the mailing list and the rough consensus was that the current wording was > sufficient. > But the current wording does not support our use case. I suggest changing the grammar for array as follows, OLD: array = begin-array [ value *( value-separator value ) ] end-array New: array = begin-array [ array-values ] end-array array-values = value *( value-separator value ) This makes it easy for a specification that requires a log file to specify that the contents of the log are a JSON array-values production. A message oriented protocol would specify that the message contained a value or an object production as desired. -- Website: http://hallambaker.com/ --089e013c61a07c47b904f446996c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 4:19 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
[ Cutting off the silly Cc list... ]

[ No hat ]

On Mar 10, 2014, at 7:35 PM, Paul E. Jones <paulej@packetizer.com> wrote:

> Why would sequences of objects not be preferred for logging.

Because the log is always open for appending, so the sequence never t= erminates.

This, and many other related topics, were discussed at length earlier on th= e mailing list and the rough consensus was that the current wording was suf= ficient.

But the current wording does n= ot support our use case.

I suggest changing the grammar for array as follows,=A0=

OLD:
array =3D begin-arr=
ay [ value *( value-separator value ) ] end-array
=A0
New:
array =
=3D begin-array [ array-values ] end-array
ar=
ray-values =3D value *( value-separator value )

<= /div>

This makes it easy for a specification that requir= es a log file to specify that the contents of the log are a JSON array-valu= es production. A message oriented protocol would specify that the message c= ontained a value or an object production as desired.


--
Website: http://hallambaker.com/
--089e013c61a07c47b904f446996c-- From nobody Mon Mar 10 15:06:58 2014 Return-Path: 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 01BE01A058E for ; Mon, 10 Mar 2014 15:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 aLY8V_y1weOb for ; Mon, 10 Mar 2014 15:06:51 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (agjbgdcfdbfj.dreamhost.com [69.163.253.159]) by ietfa.amsl.com (Postfix) with ESMTP id D86731A0547 for ; Mon, 10 Mar 2014 15:06:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3DD9967406A for ; Mon, 10 Mar 2014 15:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=O6te9IpROLNDH5y41ySoZ/iimv4=; b=k3BoBFxbSrG 6ThCqZHuDsD287btIiBe+6+n0rcPzv8Au852ZmPPQ1B30SqQ8sjwyIiWuPUmfCUs aam897sdqpzxkBPy0vP1vT9irnjr9PPx1rhhYNcSD3WPz2X8Ie5F9I/gCeqDgZVC EaTa0mGp4NAFa85ypKA79PP718EGcwrA= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id E01A7674058 for ; Mon, 10 Mar 2014 15:06:44 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so9423788wgg.33 for ; Mon, 10 Mar 2014 15:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=/QrHwzhIrpgnRxafwhm8vUH/qbnpm3aRlfdDzsr8DJA=; b=eoWCLZbv8k7r9Rw1PKOqNrDz8kvSMK7u5YMJZClg0VX2Lt3guopU91jOzxRzYY68i2 ExT0isy2N2tlXObwbnc6XPEzNRWoBm42rikHCXipox4O58h/Taz9UUdEp7o+OndJ6WX+ 5A+DCj0ac3ufef/pzHJnTGASHTQM4py5cdYLN3wg1cwHtBuQYXDk1YV5iwJzT0taDi9B 6T8pgF+5nNewwZpik3+YB/MBKJ8Zq0iSkTvyxZRHkAwF9yJMJ0pWKD7XmcYarHd6W0JT sPrO+0auk/ucu3kkxhXUpMnlL1N2msjRVNnIdvN3j2kRvx/EDjOyEbRJbMoPDWm6Zusq smzA== MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr41010wjc.56.1394489203589; Mon, 10 Mar 2014 15:06:43 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 15:06:43 -0700 (PDT) Date: Mon, 10 Mar 2014 17:06:43 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4BrFdVdXhhGeNAwSdFoav6uPzcY Cc: "json@ietf.org" Subject: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 22:06:53 -0000 On Mon, Mar 10, 2014 at 3:19 PM, Paul Hoffman wrote: > [ No hat ] > > On Mar 10, 2014, at 7:35 PM, Paul E. Jones wrote: >> Why would sequences of objects not be preferred for logging. > > Because the log is always open for appending, so the sequence never terminates. This. Other use cases relate to transferring large sequences of texts. For example, serializing a database: it may be easier to arrange for the encoding of such a serialization as multiple top-level values than as one large array (because, e.g., the encoder may not support online functionality). Yes, yes, the application could emit a '[' to start, ',' between top-level values, and a ']' at the end. But if the sequence is indeterminate in length (because it is an event log including future events as they happen) then the parser on the other end had better be an online (at least as to top-level array elements) parser! Sure the application could specially handle top-level arrays to "explode" them in an online manner, but this still requires the parser to identify exactly where in the input stream each array element ends. IOW, some use cases are easier to code as sequences of top-level values. > This, and many other related topics, were discussed at length earlier on the mailing list and the rough consensus was that the current wording was sufficient. Yes, though it's worth going into this a bit further. There are two ambiguities then. The values true, false, null, and numeric values are all ambiguous unless separated by whitespace or other unambiguous values (strings, arrays, or objects). The second ambiguity is between true/false/null/numeric values and EOF: a parser fed 'true' cannot produce that value (or a parse error) until one more byte is read _or_ EOF is detected. This means that top-level non-array/object/string values should be immediately _followed_ by whitespace when sequences of of such top-level values are emitted. Note: _followed_, not _preceded_ -- it's OK to also precede them with whitespace, but it is necessary to follow them with whitespace in order to avoid the EOF/error ambiguity. Nico -- From nobody Mon Mar 10 15:12:07 2014 Return-Path: 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 8C36A1A04B0 for ; Mon, 10 Mar 2014 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 9NS7pwVAyPSW for ; Mon, 10 Mar 2014 15:12:04 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id 420CD1A024B for ; Mon, 10 Mar 2014 15:12:04 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id E5DB32005D107 for ; Mon, 10 Mar 2014 15:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dAU+OrFr7LOQ3rQaaIBJ YO8f0GU=; b=mMlttTpdrhgUPR/CDVAvN/VEFVwjZbkpqsar3UW7K1Vg6wdbAHhK O9jEoLCyWbcKJrEmLcrSitsR2FlZLcJT6Sqk7E2ApXGIq8EV8ISLtPuVRAj4K39e lj6YVa8HEHOpKQKZ3SuKj5LN05kRmVV1MI/xafzx3Pw9Y3rXJANb4og= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 9804E2005D106 for ; Mon, 10 Mar 2014 15:11:58 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so93375wiw.12 for ; Mon, 10 Mar 2014 15:11:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q6US/vGMnJrnO2KE8AmLIeKcbTCVSRa5mZmFSBFHqI8=; b=NX72dQbXYvZ5UCTUypT9tpbIPht7fl9ATIbH32PIdUi8sqF0wBKjFf7evZMpcLLAn9 icf/04aS94+FiJ7Sw7vm5GySAYjmozak406O52T5QVKmdgyUJ7dkNUD/CwDIpal3oMT1 9SOgD9FZciODSe/P9u/2fpvbzmcVGqwleplxjNQV74ySSSLL5wZoa810kvCVePk9ExOf Mm3nEGvNaO6/YA7C+7NF0dIvMbt7aU8pSrxIg5kGmdy0Pc/Xqn0bqgK5NXZCJ2vlgwAv HXFFIC0lWhTG6NfcJr/iroNcsc4ck/NWapETh3ncOUPaO/2ZWB5qzxqNeTJBDDsY1Ird gnHw== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr243208wij.42.1394489516987; Mon, 10 Mar 2014 15:11:56 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 15:11:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 17:11:56 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/AxpZZKB8wpywxOj2iE3MfoUoufY Cc: "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 22:12:05 -0000 Consider jq (https://stedolan.github.io/jq) as an example. jq can and will read a sequence of JSON texts from stdin. That sequence isn't an array. jq applies its program to each input. jq produces as its output all the values -encoded as JSON texts- output by the jq program. This is exceedingly convenient, including for log files (for the reason that you give: log files are an indeterminate length, unending append-only sequence). jq handles the ambiguity by requiring top-level values to be "terminated" by any of: unambiguous top-level values, whitespace, or EOF. Thus the sequence of null, true, false, 1, and 2, requires whitespace between every value. While the sequence of true, "foo", false, "bar", 1, "foobar", and 2 doesn't. An input that looks like "truefalsenull12" elicits a parse error. Note that the jq parser does NOT in fact parse multiple top-level values; it parses at most one top-level value. Instead the program using the parser feeds input bytes to the parser until the parser finds the end of a top-level value and outputs it. Remaining unparsed bytes are buffered, of course so that when the program adds more input bytes the parser can be restarted to parse the next top-level value. This does mean that the jq parser will not output null when fed 'null' until one more byte _or_ EOF are fed to it. But if fed '[1,2]' then the parser emits the parsed array value immediately when the closing bracket is parsed, without waiting for further inputs. jq always outputs a newline (though it could be space or tab) after outputting any top-level value's JSON text encoding. It does so precisely to avoid these ambiguities. (This is also why jq must continue to output a newline or other whitespace after every output text, except, perhaps, when in raw output mode, in which case the outputs aren't JSON texts.) Nico -- From schmorp@schmorp.de Mon Mar 10 15:59:25 2014 Return-Path: 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 802291A0527 for ; Mon, 10 Mar 2014 15:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_47=0.6] autolearn=no 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 i2eCrEei4Rqt for ; Mon, 10 Mar 2014 15:59:23 -0700 (PDT) Received: from mail.nethype.de (schmorp-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:b09::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB171A0647 for ; Mon, 10 Mar 2014 15:59:20 -0700 (PDT) Received: from [10.0.0.5] (helo=doom.schmorp.de) by mail.nethype.de with esmtp (Exim 4.80) (envelope-from ) id 1WN9A0-00068k-SH; Mon, 10 Mar 2014 22:59:04 +0000 Received: from [10.0.0.1] (helo=cerebro.laendle) by doom.schmorp.de with esmtp (Exim 4.80) (envelope-from ) id 1WN99x-0000gx-Dz; Mon, 10 Mar 2014 22:59:01 +0000 Received: from root by cerebro.laendle with local (Exim 4.80) (envelope-from ) id 1WN99x-0001lw-DS; Mon, 10 Mar 2014 23:59:01 +0100 Date: Mon, 10 Mar 2014 23:59:01 +0100 From: Marc Lehmann To: Jacob Davies Message-ID: <20140310225901.GA6673@schmorp.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann Key fingerprint = 475A FE9B D1D4 039E 01AC C217 A1E8 0270 DA74 3396" Archived-At: http://mailarchive.ietf.org/arch/msg/json/xVf24w7WumEkDNrdpb8KFY_taUI X-Mailman-Approved-At: Mon, 10 Mar 2014 16:18:10 -0700 Cc: Barry Leiba , Pete Resnick , Bjoern Hoehrmann , Paul Hoffman , "json@ietf.org" , "Paul E. Jones" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" , Nico Williams , Larry Masinter , "rfc7158@schmorp.de" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 23:04:34 -0000 On Mon, Mar 10, 2014 at 11:14:29AM -0700, Jacob Davies wrote: > Does either the old or new specification say anything about multiple > values in sequence? I'm pretty darn sure the old version at least said > that application/json documents contain one and only one value, and > says nothing about serializing JSON in other formats, so encapsulation > is not addressed. Keep in mind that a) JSON existed before it was an RFC and b) that the RFC says a json document contains only one value is unrelated to this issue, as one should be able to rely on the format specification. As JSON is (or was...) self-delimited, and this is a common concept among serialisation formats, it shouldn't be surprising that some people relied on it. > I also don't see how any process that expects to read sequences of > self-delimited JSON objects and arrays is going to blithely accept > numbers and strings and whatnot. I find the idea unlikely that there > is some running code that 1. expects sequences of JSON values with > no delimiters, 2. uses a parser that precisely followed the JSON > specification and rejected anything but JSON objects and arrays prior to > this change, 3. has that parser change under it to accept all kinds of > values and 4. is so indifferent to the contents of what it is processing > that it doesn't notice that it's getting numbers and strings instead of > objects or arrays. Well, the code exists (making this unlikely idea a certainty), I have written it, and it is used, and it is in trouble now. I also don't think it is rare, because this situation arises quite naturally in non-monolithic designs: 1. you have some application that exchange json texts, using 2. a protocol that tunnels json texts, which uses 3. some generic json coder. neither of these might know about the other, e.g. because the json-tunnel (2 above) is used to connect applications (1 above) on different hosts for example. after upgrading the json coder, apps can silently exchange json texts, and the protocol that worked fine before might silently corrupt data. and since the json coder is often a generic component that comes with some "framework" (likewise 2), this situation is quite likely in practise. Even if unlikely, given the implications, the RFC should not just have ignored this issue. As an implementer (with JSON::XS, which so precisely followed the spec that it found at least one bug in the official testsuite btw.), I am now in a fairly bad situation - silently switch to the new JSON format and push the problem to the users, or force them to enable the new version manually. JSON::XS did support the "new JSON" format via a switch as an extension, but applications had to explicitly ask for it, so presumably know what they are dealing with. Both solutions (silently switching, or defaulting to "old JSON") obviously don't appeal to me, and having "new json" and "old json" is such a horrible concept in itself, especially with JSON, which really shouldn't be split into two different formats after it has been deployed to such an extent. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ From nobody Mon Mar 10 16:59:20 2014 Return-Path: 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 A2C1E1A0547 for ; Mon, 10 Mar 2014 16:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 aCdZT2n63l9v for ; Mon, 10 Mar 2014 16:59:12 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7B01A04E9 for ; Mon, 10 Mar 2014 16:59:12 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WNA63-0008Nj-NQ; Mon, 10 Mar 2014 19:59:03 -0400 Date: Mon, 10 Mar 2014 19:59:03 -0400 From: John Cowan To: Nico Williams Message-ID: <20140310235903.GJ18880@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/fX6MwZtX33pRqRSd0e7jA99H5y0 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 23:59:14 -0000 Nico Williams scripsit: > jq handles the ambiguity by requiring top-level values to be > "terminated" by any of: unambiguous top-level values, whitespace, or > EOF. Thus the sequence of null, true, false, 1, and 2, requires > whitespace between every value. Why is that? The input "nulltruefalse1 2" would be unambiguous. -- John Cowan http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein From nobody Mon Mar 10 17:15:15 2014 Return-Path: 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 9258C1A0670 for ; Mon, 10 Mar 2014 17:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 QP1zcA--3LFy for ; Mon, 10 Mar 2014 17:15:13 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0061A064C for ; Mon, 10 Mar 2014 17:15:13 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 228C6598060 for ; Mon, 10 Mar 2014 17:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=74QQt8WWiCC5EWcvLom9 UZNa9Jg=; b=ROBff57HZ7kA/exDEpgPZnZwcAYIHVOC/LZ0vButcJ7a3tj42thx 5WJQCm3R0MXKk4kYEXfUhPK9/UGdFIV0xMgzjkvl6LVCddyoypbp2+cyDcPDgfkz KSxnANJ5bjMfEORnIvF94kwGzqtU22EdmTQ5rO/d03OkJGLHet0sINo= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id C2F5C598058 for ; Mon, 10 Mar 2014 17:15:07 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so177180wiw.12 for ; Mon, 10 Mar 2014 17:15:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=41yGN56gCfAFEeffde1kOGj46y9LAEsm35ERYlKFqt4=; b=XGRG5WgmvzdgDVNHjPeqUwGvKmNWfU/4Pkm2jzIUfyA3JFMRo/SfUvYMiA9ezc9qCw pG8H24/66GoLU61apT1K2b0D1Z2SZzC0at+epPmBbOoS7sVARP593Y2EVtefiAvu7bT4 E7KWovX1tc67+sY8MC7gu/Nc4+D4AKJ7Yn+fdFY3JsWShDQ50F2vhxCGNIEmv0dI+MJF NZOxk13bvZ/YNWZgj+RK3Yyo1vecDs6zkSJdoGxeEGZ4/g4uU8t4Pfn9kgIYY1yLXMD2 Pw4rqPbj3Zj28JJ/wO4AYRR1PBerWv7QjDykeLDrYlyCSr/7HM54rdBs8xpvtw911aFu 33Lw== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr562037wij.42.1394496906459; Mon, 10 Mar 2014 17:15:06 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 17:15:06 -0700 (PDT) In-Reply-To: <20140310235903.GJ18880@mercury.ccil.org> References: <20140310235903.GJ18880@mercury.ccil.org> Date: Mon, 10 Mar 2014 19:15:06 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/3P0q6hR92uuofoXgdQtqhF6O24w Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:15:14 -0000 On Mon, Mar 10, 2014 at 6:59 PM, John Cowan wrote: > Nico Williams scripsit: > >> jq handles the ambiguity by requiring top-level values to be >> "terminated" by any of: unambiguous top-level values, whitespace, or >> EOF. Thus the sequence of null, true, false, 1, and 2, requires >> whitespace between every value. > > Why is that? The input "nulltruefalse1 2" would be unambiguous. The input "[nulltrue]" is clearly an error. The input "nulltrue" could either be: an error, or null then true. Since there's two possible interpretations of "nulltrue" it is ambiguous. But you're right that one could take the position that the "e" in "true" and "false" terminates those values, and the second "l" in "null terminates that one, and that resolves that ambiguity. But there's still an ambiguity in an online parser: is online parsing of "[nulltrue]" to produce an array element value of null followed by an error, or is it to produce just the one error? Given that we have to separate top-level numbers with whitespace anyways, I think the safe position is that "nulltrue" and so on are invalid and that when emitting top-level values other than arrays/objects/strings (and even then anyways) the encoding application should follow the encoded value with whitespace (a newline, preferably). (I say encoding application because I believe an encoder is not defined in such a way that permits it to emit a sequence of more than one top-level values in a single octet stream output.) Nico -- From nobody Mon Mar 10 17:41:50 2014 Return-Path: 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 CAB911A0670 for ; Mon, 10 Mar 2014 17:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 srcdz5pUM7Wu for ; Mon, 10 Mar 2014 17:41:45 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEEF1A04E8 for ; Mon, 10 Mar 2014 17:41:45 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 15A892005D109 for ; Mon, 10 Mar 2014 17:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=C2n8U17mlqWowOMPOE0X 9L8/wis=; b=nd+ls0RU6plR6j46On9071pHzzRpaESGq5zW1uX+Y41kULpm3FXr FgUxJgNWijSveCw5/ni3tjBKVK2RVnGCQns6aXugxGKikxUB6yidUGQwq9kpaMrB SyreAziC5sy8RfjwSPw4OTbazgnxak0glKTQXf6ptE2JVsU9ebfUSTU= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id BB5E82005D105 for ; Mon, 10 Mar 2014 17:41:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so7171795wgh.22 for ; Mon, 10 Mar 2014 17:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7OL6jWNJC1inmnbv8f4cFnDCVsfPg4Oc+5V8W2PRF3w=; b=RmZytsBtdg9FKTiKVd539/O5FY9kc10J+Ll7velRFu3wvqqKb80dJLeREwOxWmszCd iLh4Nhi8SVLTWzzy0c1W9waGnuT/8xo5l80LBBaMfn8QM1ugiejNRCas0UrS2fRob0VQ BXDxALK2Rs64+VJll6/zaidCrs5two63CAQIk3O1Pk9PSf47k7/PRob2VpE3nT9s9evY G+OeKZwF70RNLNCEDYxoydeIBkeyOIGwS0vX0sULVPzN1QCD87pWLVLJx0eCRv8+C1Kp ukVLqx+KRSGLYQiq1NAna8qL6Is2Hti4lwoYyD8Cad50pBN+21pBKvkQB9pdqbq7xBEN 3kxg== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr643994wib.5.1394498498552; Mon, 10 Mar 2014 17:41:38 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 17:41:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Mar 2014 19:41:38 -0500 Message-ID: From: Nico Williams To: Jacob Davies Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Frc5TojxOrZ0AVXOJhn56Y_61HM Cc: "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:41:48 -0000 On Mon, Mar 10, 2014 at 1:14 PM, Jacob Davies wrote: > Does either the old or new specification say anything about multiple > values in sequence? I'm pretty darn sure the old version at least said > that application/json documents contain one and only one value, and > says nothing about serializing JSON in other formats, so encapsulation > is not addressed. I also don't see how any process that expects to > read sequences of self-delimited JSON objects and arrays is going to > blithely accept numbers and strings and whatnot. I find the idea > unlikely that there is some running code that 1. expects sequences of This exists: http://stedolan.github.io/jq and existed prior to the new RFC, and it happily consumed (parsed), processed, and produced (encoded) sequences of top-level values of any JSON value type. Code exists that uses jq in that way. jq happens to always emit a newline after emitting a JSON text. > JSON values with no delimiters, 2. uses a parser that precisely > followed the JSON specification and rejected anything but JSON objects > and arrays prior to this change, 3. has that parser change under it to Every JSON parser I've ever used or read the docs for (probably half a dozen) has an option to parse things other than arrays/objects at the top-level. If the sequenced texts are separated by newlines (or, really, any whitespace) and the parser can be fed a chunk of octets at a time until a complete text is read, then it's trivial to build an application that consumes sequences of texts. There are other parser features that can be used to build such an application, but since numbers must be delimited somehow ("on the right"), the simple rule to follow is to just emit a newline after any JSON text. > accept all kinds of values and 4. is so indifferent to the contents of > what it is processing that it doesn't notice that it's getting numbers > and strings instead of objects or arrays. Your imagination fails you: jq 'if type == "number" then ... elif type == "string" then ... elif type == "array" then ... else ... end' You can do the same in Python, JavaScript, Ruby, C, and so on and on. You might argue that this is silly, but I'd say once more that your imagination fails you. Suppose I'm grepping for specific values and I want to output the paths to them in a stream of texts whose form I know little about -- being new to some project with lousy docs I might be trying to understand some data. Why not? For me the main issue here is that there's an ambiguity (see separate thread) that is best resolved by always emitting a newline after each text in a sequence. Nico -- From nobody Mon Mar 10 17:48:46 2014 Return-Path: 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 904231A0672 for ; Mon, 10 Mar 2014 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 gMMaak3HzwlJ for ; Mon, 10 Mar 2014 17:48:42 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (agjbgdcfdbgj.dreamhost.com [69.163.253.169]) by ietfa.amsl.com (Postfix) with ESMTP id 919291A0670 for ; Mon, 10 Mar 2014 17:48:42 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 39F9A1604 for ; Mon, 10 Mar 2014 17:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iEfmGvc0sb1a5enzSZCp uuQo4bY=; b=REv8qTwhAiA69h9ogVz2Viplx7PDvjs4xLc0fWoMxdllirkRWZ1v u9iaocuJwctbi99dwJxMZzgD5YhF8BJcOPgMXHD66X/STTpA9h+T7XHKS1n4blgh Jh+rDgmlO6aesf1GuuXjdzjsCeSOe/40i0NayXkvCFGRnMUZFtx18uQ= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id D90271600 for ; Mon, 10 Mar 2014 17:48:36 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so9251701wes.7 for ; Mon, 10 Mar 2014 17:48:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=45Hq82RQUcCg2YzFRIr0zuis6C3NOLcjhDqwwLvhyvw=; b=gcm7EIcZJsZI5JZ6BY+gxAhtUWNkvPJGq27OY51bsXJqCacgWrmMvjHIw5apzpdlKs hOqe5sJUKWrOuhCgkCsLHTdh+yOnTV97Vl8c25URxG2hHDNKsxZ1RA/mtiZuHa+EbZH+ w8UaxYsn3UreYLfJO3E/7vALEHTmBWm1RWevqneKJNTVW/OHX3a3oPxwqsqtidEhQMey x/33l/d/riU8qKUq6S43SlBDRO56gniQQYQcxSS062XYDuE2dkYNxloWdIC734p3DNyE OMG+RENo1L8yOEkn9VSfRDyHo0ZqPDe7ZdPBe+IRHUst0FSEYfGB8H+HJ8G9kkaNBUKm LcHQ== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr645555wib.5.1394498915589; Mon, 10 Mar 2014 17:48:35 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 10 Mar 2014 17:48:35 -0700 (PDT) In-Reply-To: <20140310225901.GA6673@schmorp.de> References: <20140310225901.GA6673@schmorp.de> Date: Mon, 10 Mar 2014 19:48:35 -0500 Message-ID: From: Nico Williams To: Marc Lehmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/7L5hTa2oRsW93sxRwbsw3sc83Qk Cc: "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 00:48:43 -0000 On Mon, Mar 10, 2014 at 5:59 PM, Marc Lehmann wrote: > As an implementer (with JSON::XS, which so precisely followed the spec > that it found at least one bug in the official testsuite btw.), I am now > in a fairly bad situation - silently switch to the new JSON format and > push the problem to the users, or force them to enable the new version > manually. JSON::XS did support the "new JSON" format via a switch as an > extension, but applications had to explicitly ask for it, so presumably > know what they are dealing with. Hmm, no. No one is forcing any parser or any JSON-using app to handle non-array/object JSON text sequences if it didn't before. The only problem I see is the need to disambiguate some cases (see separate thread), which IMO is best done by always emitting a newline after every JSON text. Every parser I've worked with has an option to parse things other than arrays/objects at the top-level, and every encoder I've ever seen has an option for compact output (i.e., no newlines). Given just that and a convention of emitting a newline after every text then it's trivially easy to build an application that unambiguously handles sequences of JSON texts encoding any value type at the top-level. (It's a bit trickier if the encoder has no option to emit "compact" texts, since then one might need a parser that can consume inputs incrementally.) Nico -- From nobody Mon Mar 10 20:07:08 2014 Return-Path: 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 3FA0A1A03A7 for ; Mon, 10 Mar 2014 20:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 13pcP8yOcQcH for ; Mon, 10 Mar 2014 20:07:04 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE161A03A5 for ; Mon, 10 Mar 2014 20:07:04 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WND1l-0001u9-Qi; Mon, 10 Mar 2014 23:06:52 -0400 Date: Mon, 10 Mar 2014 23:06:49 -0400 From: John Cowan To: Nico Williams Message-ID: <20140311030648.GS18880@mercury.ccil.org> References: <20140310235903.GJ18880@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/46LpN3t0o1_STJB6UPDAmtTqSN8 Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 03:07:06 -0000 Nico Williams scripsit: > But there's > still an ambiguity in an online parser: is online parsing of > "[nulltrue]" to produce an array element value of null followed by an > error, or is it to produce just the one error? If it's an error, I don't care what junk it has already produced, so I'm quite indifferent to that. -- I Hope, Sir, that we are not John Cowan mutually Un-friended by this cowan@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) From nobody Mon Mar 10 20:12:29 2014 Return-Path: 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 236F11A0395 for ; Mon, 10 Mar 2014 20:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 f5uUaeFsWagj for ; Mon, 10 Mar 2014 20:12:26 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A37B1A0398 for ; Mon, 10 Mar 2014 20:12:26 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so277574wib.1 for ; Mon, 10 Mar 2014 20:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNSvp31ljR/IW1IA2aUzxc5veoRetZ3Qg3Tnj3b+WEE=; b=odoCz0zmOcawSsu3FNdrhnC+5kvzHgEuNtxZDP9s2l89q+hzq1FjwXgaLdEMexOx4x 52ZNsbBjRa515jPR8rE0JksQKLswhUhS4rDY7LXpOZwAbb0PjHDSdAWV8hL2738uGDTr ppKwgVUZpdVLuqd5G6bh4iVzkZyJ+53v7R6jn3cBr+oL7eTLkhnnsrurLdJNw1uLM40f E5lrEqA6W0jJVv4dgY5yazqG9EmhqKGQAtf8qcadRJkir4AvT43fcaPBlFSb51YFt3hn fBsjcRjTOfLDWofXoS/ULyPqJ4JD7S8qElTAUBDUWVAQ/rXqAUe5QTkqvYTzkkhir4T3 gdVg== MIME-Version: 1.0 X-Received: by 10.180.126.38 with SMTP id mv6mr1054760wib.46.1394507540149; Mon, 10 Mar 2014 20:12:20 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Mon, 10 Mar 2014 20:12:20 -0700 (PDT) In-Reply-To: <20140311030648.GS18880@mercury.ccil.org> References: <20140310235903.GJ18880@mercury.ccil.org> <20140311030648.GS18880@mercury.ccil.org> Date: Tue, 11 Mar 2014 03:12:20 +0000 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=e89a8f839ccb913c7604f44c166e Archived-At: http://mailarchive.ietf.org/arch/msg/json/16pjwroQEi32cUTlS-J86KOyjw0 Cc: Nico Williams , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 03:12:28 -0000 --e89a8f839ccb913c7604f44c166e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 3:06 AM, John Cowan wrote: > Nico Williams scripsit: > > > But there's > > still an ambiguity in an online parser: is online parsing of > > "[nulltrue]" to produce an array element value of null followed by an > > error, or is it to produce just the one error? > > If it's an error, I don't care what junk it has already produced, > so I'm quite indifferent to that. > Based on feature requests I received for handling this specific case (for Jackson), I would suggest producing error as soon as practical; in this case once "nullt" has been decoded from input. At least this was the behavior that was considered appropriate by users; and specifically NOT to allow intermediate production of valid token for 'null' (doing which was reported as a bug). -+ Tatu +- --e89a8f839ccb913c7604f44c166e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 11, 2014 at 3:06 AM, John Cowan <cowan@m= ercury.ccil.org> wrote:
Nico Williams scripsit:

> But there's
> still an ambiguity in an online parser: is online parsing of
> "[nulltrue]" to produce an array element value of null follo= wed by an
> error, or is it to produce just the one error?

If it's an error, I don't care what junk it has already produ= ced,
so I'm quite indifferent to that.


Based on fe= ature requests I received for handling this specific case (for Jackson), I = would suggest producing error as soon as practical; in this case once "= ;nullt" has been decoded from input.
At least this was the behavior that was considered appropriate b= y users; and specifically NOT to allow intermediate production of valid tok= en for 'null' (doing which was reported as a bug).

-+ Tatu +-

--e89a8f839ccb913c7604f44c166e-- From nobody Tue Mar 11 08:31:15 2014 Return-Path: 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 BFEFD1A074E for ; Tue, 11 Mar 2014 08:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 8nNjtR1rv5Rg for ; Tue, 11 Mar 2014 08:31:11 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id C311A1A03F7 for ; Tue, 11 Mar 2014 08:31:10 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so5632793lbg.7 for ; Tue, 11 Mar 2014 08:31:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DcdlyPdgMjmua3hW7fH2DdXDxtIyN1lcz98q4oCOAcA=; b=dbKnZHFeKNmZC93ki8L2noVvuOySkXDZjdBWTBGg7Yp2ojWJ4o+CxsVbsvNSA0qAnj ssZLOAkXwVA1uZaHr7ub5EhfUlNzAVHq8h11puIRVDgLEYkuhbHZvHxHy7CcQ2sumuKz z9AO/Gc9VK1/e8ESTX3wBhPSgZlC0glRuWEPENb7U9AaMZqVZzUJ301YDYpz98ncP5Q8 LFmuswewpTdetPxItsb1XPXa0LtnYW/7iYF31mlZUS9uxO+JsaNrdtJ+K/LTem5pbkdq JQAC5Xd0+GnZPGvFYDsWY7BeatWImqnTAbsG5O7lchvwVAbPGPr1d1hSKt3AH/Ha16HB VUAQ== X-Gm-Message-State: ALoCoQlZrT24PXxsxgn2a2USZzfuVmIBy1Ap3aKiy0/R1UzdMFo4M4UwxyLHcTFyy9Jedj/J/yhl MIME-Version: 1.0 X-Received: by 10.112.172.198 with SMTP id be6mr26642936lbc.5.1394551864159; Tue, 11 Mar 2014 08:31:04 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.82.170 with HTTP; Tue, 11 Mar 2014 08:31:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 11:31:04 -0400 X-Google-Sender-Auth: qlrGfjytj3BB3VYquUMqaX3Nvc8 Message-ID: From: Matthew Morley To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c266487c074404f45668c6 Archived-At: http://mailarchive.ietf.org/arch/msg/json/6SqvntmuT2XN4qQnmOkC2RIq7Ko Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:31:14 -0000 --001a11c266487c074404f45668c6 Content-Type: text/plain; charset=ISO-8859-1 This issue came up with json-rpc structures and streaming json, which while not directly related in that we expect to encounter only objects at the top level... having guidance on handling top-level streaming is important for json. https://groups.google.com/forum/#!msg/json-rpc/fd1_anYEnDs/nnvnU51bfCoJ *https://groups.google.com/d/msg/json-rpc/cXlc8bD-a_M/cwfLYWSly54J * http://www.simple-is-better.org/json-rpc/transport_sockets.html On Mon, Mar 10, 2014 at 6:11 PM, Nico Williams wrote: > Consider jq (https://stedolan.github.io/jq) as an example. > > jq can and will read a sequence of JSON texts from stdin. That > sequence isn't an array. jq applies its program to each input. jq > produces as its output all the values -encoded as JSON texts- output > by the jq program. This is exceedingly convenient, including for log > files (for the reason that you give: log files are an indeterminate > length, unending append-only sequence). > > jq handles the ambiguity by requiring top-level values to be > "terminated" by any of: unambiguous top-level values, whitespace, or > EOF. Thus the sequence of null, true, false, 1, and 2, requires > whitespace between every value. While the sequence of true, "foo", > false, "bar", 1, "foobar", and 2 doesn't. An input that looks like > "truefalsenull12" elicits a parse error. > > Note that the jq parser does NOT in fact parse multiple top-level > values; it parses at most one top-level value. Instead the program > using the parser feeds input bytes to the parser until the parser > finds the end of a top-level value and outputs it. Remaining unparsed > bytes are buffered, of course so that when the program adds more input > bytes the parser can be restarted to parse the next top-level value. > > This does mean that the jq parser will not output null when fed 'null' > until one more byte _or_ EOF are fed to it. But if fed '[1,2]' then > the parser emits the parsed array value immediately when the closing > bracket is parsed, without waiting for further inputs. > > jq always outputs a newline (though it could be space or tab) after > outputting any top-level value's JSON text encoding. It does so > precisely to avoid these ambiguities. > > (This is also why jq must continue to output a newline or other > whitespace after every output text, except, perhaps, when in raw > output mode, in which case the outputs aren't JSON texts.) > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Matthew P. C. Morley --001a11c266487c074404f45668c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This issue came up with jso= n-rpc structures and streaming json, which while not directly related in th= at we expect to encounter only objects at the top level... having guidance = on handling top-level streaming is important for json.

https://groups.google.com/forum/#!msg/json-r= pc/fd1_anYEnDs/nnvnU51bfCoJ
https://groups.google.com/d= /msg/json-rpc/cXlc8bD-a_M/cwfLYWSly54J
http://www.simple-is-better.org/json-rpc/transport_sockets.html


On Mon, Mar 1= 0, 2014 at 6:11 PM, Nico Williams <nico@cryptonector.com> wrote:
Consider jq (https://stedolan.github.io/jq) as an example.

jq can and will read a sequence of JSON texts from stdin. =A0That
sequence isn't an array. =A0jq applies its program to each input. =A0jq=
produces as its output all the values -encoded as JSON texts- output
by the jq program. =A0This is exceedingly convenient, including for log
files (for the reason that you give: log files are an indeterminate
length, unending append-only sequence).

jq handles the ambiguity by requiring top-level values to be
"terminated" by any of: unambiguous top-level values, whitespace,= or
EOF. =A0Thus the sequence of null, true, false, 1, and 2, requires
whitespace between every value. =A0While the sequence of true, "foo&qu= ot;,
false, "bar", 1, "foobar", and 2 doesn't. =A0An inp= ut that looks like
"truefalsenull12" elicits a parse error.

Note that the jq parser does NOT in fact parse multiple top-level
values; it parses at most one top-level value. =A0Instead the program
using the parser feeds input bytes to the parser until the parser
finds the end of a top-level value and outputs it. =A0Remaining unparsed bytes are buffered, of course so that when the program adds more input
bytes the parser can be restarted to parse the next top-level value.

This does mean that the jq parser will not output null when fed 'null&#= 39;
until one more byte _or_ EOF are fed to it. =A0But if fed '[1,2]' t= hen
the parser emits the parsed array value immediately when the closing
bracket is parsed, without waiting for further inputs.

jq always outputs a newline (though it could be space or tab) after
outputting any top-level value's JSON text encoding. =A0It does so
precisely to avoid these ambiguities.

(This is also why jq must continue to output a newline or other
whitespace after every output text, except, perhaps, when in raw
output mode, in which case the outputs aren't JSON texts.)

Nico
--

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
= Matthew P. C. Morley
--001a11c266487c074404f45668c6-- From nobody Tue Mar 11 09:45:22 2014 Return-Path: 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 97E971A0763 for ; Tue, 11 Mar 2014 09:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 3hGT43k6hqZ8 for ; Tue, 11 Mar 2014 09:45:19 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (agjbgdcfdbfd.dreamhost.com [69.163.253.153]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6D1A0747 for ; Tue, 11 Mar 2014 09:45:19 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 011DF50808F for ; Tue, 11 Mar 2014 09:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6CJlYqFl7cwez0kewv+m q0V02Rg=; b=Nj8ozPbbNeWe5a1Fnd+yj0pj4Sfe/CmnU/0A8TwLIQ8c0clH7uTM NI9N2b6m95R0qydHk2g+ZvbFLq9m/EYk1pPEIaYuezp1VFtvvzZGIl9OLaL1y7Qo yivexU7ZOHskKHqXUhtJ5jPW6jV5mhGGe6iF3AdyicWIw7MC6fWZWzc= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id A4C7D50805F for ; Tue, 11 Mar 2014 09:45:13 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so10362344wgg.33 for ; Tue, 11 Mar 2014 09:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S/yOZZS+hdNDCze8a59tW/rX51un7SZ4Jbi+aKgQetY=; b=S8Nbzgj/eVGWygkd8L5H5MlV+DJHo7Bek0bw4dpXMvvjG2T2u7q5frHU2KjSnAY3TH uHjfQwbNoP1DadHs4hsJLOPxXnTs5z/w5dfUjPK4koU+/MyqEIYRgvHuhZGCl+/dUf4b lPLV7oFZftsU/cKUg+RhVCnjVX1YRdp+WDVv0sNEElPwK6k6GxndAYbXond7cSSFPYUM 82Fpk6aAPjLj0DbQd6eOBkYz3/2aeBKWajGQQU0oJrbU2l/fl2NzFxkJ1UhzkhpvuweP EHFmugn3CgNCP8YFYLO8TnmR6QZxEOVJ1JL602Tu55UTx53f/jDyDm5mPO+pY/eEXmAp 558Q== MIME-Version: 1.0 X-Received: by 10.194.57.140 with SMTP id i12mr37192865wjq.20.1394556312551; Tue, 11 Mar 2014 09:45:12 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 09:45:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 11:45:12 -0500 Message-ID: From: Nico Williams To: Matthew Morley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/gi8zfFszJ3pBg_wv15C8JkCELUs Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:45:20 -0000 On Tue, Mar 11, 2014 at 10:31 AM, Matthew Morley wrote: > This issue came up with json-rpc structures and streaming json, which while > not directly related in that we expect to encounter only objects at the top > level... having guidance on handling top-level streaming is important for > json. Arguably JSON text sequences are a new format, deserving of its own MIME type and so on. The change in JSON top-level value syntax didn't really break JSON text sequencing as a) there were plenty of encoders and parsers that handled non-array/object top-level values anyways, so b) the ambiguity already existed. Maybe we should publish an RFC on JSON text sequences? Nico -- From nobody Tue Mar 11 09:49:06 2014 Return-Path: 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 196D11A0794 for ; Tue, 11 Mar 2014 09:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 mjDaaB_TKQys for ; Tue, 11 Mar 2014 09:49:00 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id B12831A078B for ; Tue, 11 Mar 2014 09:49:00 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so8825380veb.17 for ; Tue, 11 Mar 2014 09:48:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DwU0nwHfx58qvzygFPeLhCHtoH6kATZO7Tt4Avdc2rA=; b=F/0uyKnhScPTMJsSjCwUO4zRqxRvxGIKVvvQ5/Zy8Bk4TcGyMCwISSec+dXihAxGAg c8NjXMJL0J3VzCIp3K3yrNITyMMW4kRzFPqNTVV4uccPOhy3hFy+D2iQJymYESa4qOAZ I/IXLI0Ywa/izoo2mqTgWjAHw43YbvPM74FClxAsgL+jZw6/R767OrqZB/sW4ZYJ7sZR XnT1JRqih310IF2ULgKqbqcK3nfBLc66TsinwXjQlDSPGY/wGh0Vasi+7CbMjLGcyMnc xg94mdvh4Qw7G+fEnUnLZB3W/plQcBLiQsQvITNAw7bfiGI984IAVJsmCafuZ3DtVIon iEKQ== X-Gm-Message-State: ALoCoQk5EBYkTheF+ef0/W2niXilekpCijyrvYDWia3d19o7MbAG0ThA7owZzEd54fIQuld1NDuu MIME-Version: 1.0 X-Received: by 10.58.190.99 with SMTP id gp3mr935025vec.32.1394556534839; Tue, 11 Mar 2014 09:48:54 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Tue, 11 Mar 2014 09:48:54 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Tue, 11 Mar 2014 09:48:54 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b675bf0e0ef4304f4577ee7 Archived-At: http://mailarchive.ietf.org/arch/msg/json/OcYcoFEB2fsT3wdLfrtxjLklm2w Cc: "json@ietf.org" , Matthew Morley , Paul Hoffman Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:49:04 -0000 --047d7b675bf0e0ef4304f4577ee7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Heh, I wonder if there=E2=80=99d be any chance of getting consensus. I can= =E2=80=99t imagine ever using anything but Object Object Object with optional whitespace separator; unless we all agree on that going in I=E2=80=99d pess= imistic about anyone convincing anyone else... On Tue, Mar 11, 2014 at 9:45 AM, Nico Williams wrote= : > On Tue, Mar 11, 2014 at 10:31 AM, Matthew Morley wrote: > > This issue came up with json-rpc structures and streaming json, which > while > > not directly related in that we expect to encounter only objects at the > top > > level... having guidance on handling top-level streaming is important f= or > > json. > > Arguably JSON text sequences are a new format, deserving of its own > MIME type and so on. The change in JSON top-level value syntax didn't > really break JSON text sequencing as a) there were plenty of encoders > and parsers that handled non-array/object top-level values anyways, so > b) the ambiguity already existed. > > Maybe we should publish an RFC on JSON text sequences? > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b675bf0e0ef4304f4577ee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Heh= , I wonder if there=E2=80=99d be any chance of getting consensus. =C2=A0I c= an=E2=80=99t imagine ever using anything but Object Object Object with opti= onal whitespace separator; unless we all agree on that going in I=E2=80=99d= pessimistic about anyone convincing anyone else...



On Tue, Mar 11, 2= 014 at 9:45 AM, Nico Williams <nico@cryptonector.com> wr= ote:
On Tue, Mar 11, 2014 at 10:3= 1 AM, Matthew Morley <matt@mpcm.com= > wrote:
> This issue came up with json-rpc structures and streaming json, which = while
> not directly related in that we expect to encounter only objects at th= e top
> level... having guidance on handling top-level streaming is important = for
> json.

Arguably JSON text sequences are a new format, deserving of its own MIME type and so on. =C2=A0The change in JSON top-level value syntax didn&#= 39;t
really break JSON text sequencing as a) there were plenty of encoders
and parsers that handled non-array/object top-level values anyways, so
b) the ambiguity already existed.

Maybe we should publish an RFC on JSON text sequences?

Nico
--

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b675bf0e0ef4304f4577ee7-- From nobody Tue Mar 11 10:09:26 2014 Return-Path: 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 429C31A074F for ; Tue, 11 Mar 2014 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 eKFku7iv7I54 for ; Tue, 11 Mar 2014 10:09:21 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C36AD1A0756 for ; Tue, 11 Mar 2014 10:09:20 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so5956799lbd.29 for ; Tue, 11 Mar 2014 10:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rWQ+rqwfTHetizI8I62R+/WS5lQ4JO7oQRmRHZtqaE=; b=BxULV9m1Es/kDRPXetDVY8j9j5du1IFjnWJwH7QCGS0wY2HjjEQvKszm4/v2L7B3b3 K4LcmmiGQUi+5M0W7mLP46P2ZLmuE+IbVrhfA26DnWQOPAgXwzhWwl2SyWQFNbXwUJXB 7bI9B6mKr8GUIOulGxc2u5ft+XWW4jIWtOIlghxN0QJ44PXikDhtfHeL4pRhMhcuTUCl Mo8v0iF0uc4+uQpjL+maGyMFBvzlcjqSJiX3la1dbVz37C7hNmhMVWg40g6IBR05X2ux tBkiDI7hpngkO2JkvCnPb/dABmkK3riXvmvQXIVG5o7mwcFKbHRzJx9sKmIf8tbjjQ4b W2vQ== MIME-Version: 1.0 X-Received: by 10.112.151.146 with SMTP id uq18mr6281381lbb.38.1394557754371; Tue, 11 Mar 2014 10:09:14 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Tue, 11 Mar 2014 10:09:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 13:09:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=047d7beb97d891734604f457c7d9 Archived-At: http://mailarchive.ietf.org/arch/msg/json/QPfUHfzB59QhuV1Yt0oDZ8zAcyE Cc: Nico Williams , Paul Hoffman , Matthew Morley , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:09:24 -0000 --047d7beb97d891734604f457c7d9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray wrote: > Heh, I wonder if there'd be any chance of getting consensus. I can't > imagine ever using anything but Object Object Object with optional > whitespace separator; unless we all agree on that going in I'd pessimistic > about anyone convincing anyone else... > But JSON has comma separators, so {..}, {..}, {..} makes far more sense. The array production in the grammar already specifies this syntax so JSON parsers already recognize it. Your proposal is something new. -- Website: http://hallambaker.com/ --047d7beb97d891734604f457c7d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.co= m> wrote:
Heh, I wonder if there’d be any chance of getting consensus. &nbs= p;I can’t imagine ever using anything but Object Object Object with o= ptional whitespace separator; unless we all agree on that going in I’= d pessimistic about anyone convincing anyone else...

But JSON has comma separators, so {.= .}, {..}, {..} makes far more sense.

The array pro= duction in the grammar already specifies this syntax so JSON parsers alread= y recognize it. Your proposal is something new.

 

--
Website: http://hallambaker.com/
--047d7beb97d891734604f457c7d9-- From nobody Tue Mar 11 10:10:29 2014 Return-Path: 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 AC8001A0640 for ; Tue, 11 Mar 2014 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 TycqlfRNQWOw for ; Tue, 11 Mar 2014 10:10:26 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFD91A0481 for ; Tue, 11 Mar 2014 10:10:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 150E628420 for ; Tue, 11 Mar 2014 10:10:21 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id C25FD21DE6A for ; Tue, 11 Mar 2014 10:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=X3UJsO4jaNknF2jduwfVUh+quEg=; b=XlJ4bmnUDUd MMck8ln+Thp+k2o63pc8MVUj4kBTbxxyfzkPDOv/TjXwwwQ06mKxnhTSAkwn/rNW pn9KId2vpqbPyU1heaPFJrPLsZdZIzNIaCyKj3jDvGgZRUgcwjX43wXbeQ6/4pXS Vfo2R+uHkcvjJ2UH6ZPK1wNdDIMi5FXo= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 6506521DE58 for ; Tue, 11 Mar 2014 10:10:20 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so10442006wes.1 for ; Tue, 11 Mar 2014 10:10:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v1QjCEcX0WDKE8S93MQiw6ZcqXNymom+qPQ01xNBsoM=; b=cQ67esC8jze3p43Ji6QJEOmazc7/7ZrVHiUL6ITyjvox6gI0Dd0T3zqzjAmz+GhWXV E1YMJPfhxW8ehbfAHW7WqCVIT+DgwK8acuagwvF43gkq5D8IitiHKkLb9kMBseNmXmgm BLLiEXAiLRW8o+HQkVPQb9esJIElUpdlGSFJm7GOP9gGJe5HHrYr8p7t8lXDSVOP2t2b ePRCJFghv4GOcfyo8fle/nfFeLLNMfyUt1mD5BIjDs/hKNzmqAsv9aiH4iI1JQ3tDRXZ p1yxJW2TKegU1/7CK798l38v+Km+JdpMUlyFexe956JdQmMtLH+nnuoofi0pR5H8tOqr o1pw== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr14982510wjq.40.1394557819345; Tue, 11 Mar 2014 10:10:19 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 10:10:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 12:10:19 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Z50Zea0FcLn8_4KWZ0DHjAz9rhQ Cc: "json@ietf.org" , Matthew Morley , Paul Hoffman Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:10:27 -0000 On Tue, Mar 11, 2014 at 11:48 AM, Tim Bray wrote: > Heh, I wonder if there=E2=80=99d be any chance of getting consensus. I c= an=E2=80=99t > imagine ever using anything but Object Object Object with optional > whitespace separator; unless we all agree on that going in I=E2=80=99d pe= ssimistic > about anyone convincing anyone else... As I recall you opposed as strenuously the top-level value type change in the RFC you edited. And yet look where we are... Alright, let's talk examples. Suppose I have a JSON text sequence, all of them objects. And I want to extract a number from each, to be output in a sequence, natch. Why would I? Because I'm processing data in a sequence of filters, and one stage will be applying some statistical analysis to just those numbers. What's wrong with that? It's perfectly natural to do that with -you see it coming, I know- jq. Anyone who is adept/experienced with the Unix shell pipeline concept will tend to like this approach. (It's one reason I like jq.) But more importantly, what do you care?! Why should your lack of a use for anything other than a sequence of objects constrain me to the same? On what principle? Once you agree to the optional whitespace and make it required when following an otherwise ambiguous value (true, false, null, numeric), we're there, we have agreement. You can stick to object sequences, and I can use sequences of numbers if it be convenient for me. Perhaps you might say that the separator whitespace ought to be optional always, and that fundamentally limits sequences to arrays, objects, and strings. That'd be a principle we could argue about (whether to adopt it or not), but even that wouldn't justify limiting sequences to objects. I'm struggling to think of a principle that would justify your favorite constraint, and I can't think of one. What am I missing? Nico -- From nobody Tue Mar 11 11:08:24 2014 Return-Path: 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 3AEF81A0744 for ; Tue, 11 Mar 2014 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no 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 ckmvUagAmrIx for ; Tue, 11 Mar 2014 11:08:19 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (unknown [69.163.253.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72F1A0473 for ; Tue, 11 Mar 2014 11:08:19 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id A33D52005D90A for ; Tue, 11 Mar 2014 11:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FgEYCwsrluphBrwGrzNVHNrL4aI=; b=V6IblPoKE+X Nw2yIgvp/P98fMdtYCT0gWPMtxiyrxox4yvhM/LogF/HlH77kkTZZQqKcwasM65g dE3FF03G1Kus4hmPNGl3secjzJy6QOHpdQSTI5ipseBOmdFW+cgIr24edRZ6fIAZ pDN48sHID4hL0RtNRtGqjuLMDRJe9XCc= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id 4E9B32005D909 for ; Tue, 11 Mar 2014 11:08:13 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so1296280wib.13 for ; Tue, 11 Mar 2014 11:08:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6NqCHOH+ptOoypGvhp7sGrx/FqCWW9n5J3A9xvHqCkU=; b=eLSh4Sh9TrDO1eDpZWnL5lOOHvilrYh/b7/E0k5SEp9wYCOEvBcta44u+ei07vO2B+ +x5eeWKG/yoId3C05kCaXVYmr4wpeZfmLCSP32UhYdF7aiX0+JxWBkTj0QhmBKsk8JE9 JPNCYYUd/1QzE0IxDSt11Q+SOvkYcWdJ2CiPPKA6wbh9mftMCt+iPWM/Bzye950ehDu9 pZwUk8C9GNWCIOB/35z3GvHpTJ6MeSTzlCP+3nbTkaSS/5ORbt1ayk3LQ4o2OIcW18q8 ODYP15Gw9tPDBhNALjA96QdmFGPD1IEBv+EjerCnCOxnNG6WSksJHWSHmfeknxsY0XMQ zI/A== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr4268864wib.42.1394561291995; Tue, 11 Mar 2014 11:08:11 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 11:08:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 13:08:11 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Vdnm9M0JBJsjzenLikuP_2f-yu4 Cc: Paul Hoffman , Tim Bray , Matthew Morley , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:08:20 -0000 On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker w= rote: > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray wrote: >> >> Heh, I wonder if there=E2=80=99d be any chance of getting consensus. I = can=E2=80=99t >> imagine ever using anything but Object Object Object with optional >> whitespace separator; unless we all agree on that going in I=E2=80=99d p= essimistic >> about anyone convincing anyone else... > > But JSON has comma separators, so {..}, {..}, {..} makes far more sense. JSON text sequences would be a new Proposed Standard (if we go there) but like JSON, there exist uses of this "new" thing already -- that is, before we get to writing the RFC. The uses of JSON text sequences that I know of use newlines, not commas nor comma-and-newline. The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing JSON texts -- usually compact texts, i.e., with no newlines in the text, and never more than one text per-line. For me other uses of JSON text sequences generally result from my use of jq, which also effectively separates texts with a newline. Note that jq doesn't need texts to be written compactly when parsing JSON text sequences. It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with all existing JSON parsers. Switching to using a comma-and-newline would require significant retooling. Therefore I don't see it happening. Whereas just separating JSON texts with newlines is in use because it's always been the obvious thing to do. Nico -- From nobody Tue Mar 11 11:20:37 2014 Return-Path: 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 401771A07A2 for ; Tue, 11 Mar 2014 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no 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 H14Bhkau1y1O for ; Tue, 11 Mar 2014 11:20:33 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (agjbgdcfdbfd.dreamhost.com [69.163.253.153]) by ietfa.amsl.com (Postfix) with ESMTP id 95C7F1A078F for ; Tue, 11 Mar 2014 11:20:27 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 00AE2508084 for ; Tue, 11 Mar 2014 11:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=zkgJ4QijSBAdu8oxmpZPUpVvs78=; b=SbQShz3kUmc GXtJ+BksS0IRiuToc+aLg5jg12zz9XEZ8Z/Iz0mlI5Bwt7EPc7GRo36R7KXFzvAb fDW5ASfAEaayAwkfzFXOyZA+0X52lIM8bVK1WpoKalR47NYUfpi3hSuZlbSiAcsb QrkKMweZQ4efstlyvVodkdB1P32WRiH4= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id A44CE50805F for ; Tue, 11 Mar 2014 11:20:21 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi5so1320698wib.11 for ; Tue, 11 Mar 2014 11:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=fEkJX3GmqeMVe4zWOaRikwyr0t/53xN8NnvsJUsPz3Y=; b=iH7dNJGMtbrtIAHh3S53yruKX+yhwy/QY2gLzOj0y9nXPFbScfh8hfR5JdO+C8WCUP Kmjjqr/Raifnx1hz/3zB96IuCuKd3ozLv/IX40T7N2ee+NApL4ip/+F4LwFMrFyD+4y9 FNLaMb4wphe2JY+FW7ydpbRmSWP9JVsF35g78Fz21jAi5I1s2rn8i7s3USCoKYYmkDmE TAypzM3LVg9pn0H/tfAizwEE8aJasm/AlWkoxZ1OcyTEDoe68XrIUuA27KZIqlebvH+4 2UV7FeK7xQcrfgSaV1u63eOAYrH5osdhTzGwU57jJ4VcJY/s0TgtBb8TiAeek/FyVjFb uk7A== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr2470321wjw.64.1394562020434; Tue, 11 Mar 2014 11:20:20 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 11:20:20 -0700 (PDT) Date: Tue, 11 Mar 2014 13:20:20 -0500 Message-ID: From: Nico Williams To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/PpPBNgANxKsmg0nT7qRtF1hBVnI Subject: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:20:34 -0000 I propose a new Proposed Standard and MIME type describing a "JSON text sequence" as: a sequence of JSON texts separated by newlines. Details: - the newline is REQUIRED when following any of "true", "false", "null", or any numeric value, otherwise it is RECOMMENDED (but optional) - it will be RECOMMENDED that JSON texts written to JSON text sequences be encoded with no newlines in the encoding. The need for a newline (or other, but here newline) separator will be explained (namely: it's needed to disambiguate some cases). Perhaps (if folks demand it) an option for specifying an alternate separator in the MIME type will be provided. That's it. Given existing use of this, I propose that the WG take this as a work item, updating the charter to permit it if need be. I'd volunteer to edit the I-D. Nico -- From nobody Tue Mar 11 11:27:15 2014 Return-Path: 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 65A5C1A0646 for ; Tue, 11 Mar 2014 11:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 6sJL7F3Y1Vwv for ; Tue, 11 Mar 2014 11:27:09 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 36C661A0473 for ; Tue, 11 Mar 2014 11:27:08 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id w7so5863295lbi.2 for ; Tue, 11 Mar 2014 11:27:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FTIT/MAgxfyZ7Fjw059ZWKNPerQOTD4Vy9mDW+zImuU=; b=ZqG+jFKu1ISMDqRi9MjJ+BXlQAbGZTx+TtBRAs5cggGfvchEbfAxy73tF6Y599qoy2 09cZJgFCy0smVITg+ApblvbCqRq69+hn/piDUXnCcItuCeOX3WitFP2Pu0+FJId0RYNA bsKn7uqvrnkOAq+Ph0vaLn3HikYhwRwr6xIw0mXIbLpP2AbnrJOklE9NW38YYfLvoCb7 plIbWvhPLZe3OsUUjq22ZR1XZUsXF6fuKy0jO6sCtgaqLN6yakL4He/B5dIfkjDlbUgG X/6KNKGM5jwkH46FFr7wajsbFWBJWH4nSu/eMJqNWBKh3yMoBTBZ0gMCD7r71CkHhvA9 Qdfg== X-Gm-Message-State: ALoCoQmcdXIJpl4SmCPj4/sA81s0n8FzbACBvFYy90jmFrFGVJuqLK0qKaB3vhyAy8iSSauS+828 MIME-Version: 1.0 X-Received: by 10.152.2.131 with SMTP id 3mr28484540lau.20.1394562422665; Tue, 11 Mar 2014 11:27:02 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.82.170 with HTTP; Tue, 11 Mar 2014 11:27:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 14:27:02 -0400 X-Google-Sender-Auth: GovlGPpwToMA_Isw6QLyjVdjDys Message-ID: From: Matthew Morley To: Nico Williams Content-Type: multipart/alternative; boundary=089e013c674cd2030504f458ddfb Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y3QeDHOj_LClVBzKwkHdrAp49qg Cc: Tim Bray , Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:27:12 -0000 --089e013c674cd2030504f458ddfb Content-Type: text/plain; charset=ISO-8859-1 I'm not advocating for comma separators... But having multiple top level JSON elements separated by a coma is equivalent to processing an array structure. The initial [ and the closing ] are implicitly mapped to the connection/stream/etc. start and end events. It is just a minor token replacement at the top level between elements, which could be layered into some existing tooling. From this point of view, I would imagine the retooling is minor for either use case. It does mean tools need to be depth aware. On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams wrote: > On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker > wrote: > > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray wrote: > >> > >> Heh, I wonder if there'd be any chance of getting consensus. I can't > >> imagine ever using anything but Object Object Object with optional > >> whitespace separator; unless we all agree on that going in I'd > pessimistic > >> about anyone convincing anyone else... > > > > But JSON has comma separators, so {..}, {..}, {..} makes far more sense. > > JSON text sequences would be a new Proposed Standard (if we go there) > but like JSON, there exist uses of this "new" thing already -- that > is, before we get to writing the RFC. > > The uses of JSON text sequences that I know of use newlines, not > commas nor comma-and-newline. The reason for this is that these use > cases are text logfile-like: the entries are lines, lines containing > JSON texts -- usually compact texts, i.e., with no newlines in the > text, and never more than one text per-line. > > For me other uses of JSON text sequences generally result from my use > of jq, which also effectively separates texts with a newline. Note > that jq doesn't need texts to be written compactly when parsing JSON > text sequences. It happens though that if you write texts compactly > followed by a newline then you can implement JSON text sequences with > all existing JSON parsers. > > Switching to using a comma-and-newline would require significant > retooling. Therefore I don't see it happening. Whereas just > separating JSON texts with newlines is in use because it's always been > the obvious thing to do. > > Nico > -- > -- Matthew P. C. Morley --089e013c674cd2030504f458ddfb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not advocating for comma separators...

But = having multiple top level JSON elements separated by a coma is equivalent t= o processing an array structure. The initial [ and the closing ] are implic= itly mapped to the connection/stream/etc. start and end events.

It is just a minor token replacement at the top level between elements,= which could be layered into some existing tooling. From this point of view= , I would imagine the retooling is minor for either use case. It does mean = tools need to be depth aware.


On Tue, Mar 1= 1, 2014 at 2:08 PM, Nico Williams <nico@cryptonector.com> wrote:
On Tue, Mar 11, 2014 at 12:0= 9 PM, Phillip Hallam-Baker <hallam@g= mail.com> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> Heh, I wonder if there’d be any chance of getting consensus.=  I can’t
>> imagine ever using anything but Object Object Object with optional=
>> whitespace separator; unless we all agree on that going in I&rsquo= ;d pessimistic
>> about anyone convincing anyone else...
>
> But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e.

JSON text sequences would be a new Proposed Standard (if we go there)=
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline.  The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline.  Note that jq doesn't need texts to be written compactly when parsing JSON text sequences.  It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling.  Therefore I don't see it happening.  Whereas just=
separating JSON texts with newlines is in use because it's always been<= br> the obvious thing to do.

Nico
--



--
Matthew P. C= . Morley
--089e013c674cd2030504f458ddfb-- From nobody Tue Mar 11 11:35:54 2014 Return-Path: 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 3632C1A0788 for ; Tue, 11 Mar 2014 11:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tXEtVEL9vNXP for ; Tue, 11 Mar 2014 11:35:44 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 12BE31A0743 for ; Tue, 11 Mar 2014 11:35:43 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so9278990veb.0 for ; Tue, 11 Mar 2014 11:35:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7YgnbLhVjgsnlvkA4zrfx7z9CF8LT9kzJtq7V2zpSwQ=; b=VKOVKc0EmvQBRGzibZudQo7iVG/upvS6cjvsu2c3yCXbYB/GdgP6h18Oc3ItQ2Xfbc 0o0vFFhbrvIrf5bJmbqZjpH+ppWANidWlR/Zy0BEPXEO3y7f/7iQZqverXOlJ5RCIwr2 wy6IMInzqaNsDWySY1H5AgjjP8ymFKmJnHNuFjmpcxrow+lGHwUoUrjOPEOgb+QSyVW1 GWeRrcXpyYsimnz97uh8dWOmlR4vr9yW7um/5DPrj8zm80Hb8xVlcrTrTVjD3bmVRwtG CoViKLYcimstq9AfoPvq9upoiyLOP12R0+lLXg/fBNVHcoUekwv2Gx05fJq12RBYFFYL zkiQ== X-Gm-Message-State: ALoCoQm+in/JuczhKReClIRT9snhzWr4N/MPAp5u4AE/4Nch7Vh9nFGAkInb6i8hRet4bG6dVBwP MIME-Version: 1.0 X-Received: by 10.58.212.200 with SMTP id nm8mr20654990vec.11.1394562938068; Tue, 11 Mar 2014 11:35:38 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Tue, 11 Mar 2014 11:35:37 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Tue, 11 Mar 2014 11:35:37 -0700 Message-ID: From: Tim Bray To: Matthew Morley Content-Type: multipart/alternative; boundary=047d7bd6aab28a742704f458fc7f Archived-At: http://mailarchive.ietf.org/arch/msg/json/oX6ak33OYZjH2fu8JlZ-4AYMCQg Cc: Nico Williams , Phillip Hallam-Baker , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:35:52 -0000 --047d7bd6aab28a742704f458fc7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My assumption is that many (most? all?) JSON parsers can be altered to, when they encounter a JSON text containing an object, just stop reading when they hit the trailing =E2=80=9C}=E2=80=9D. So my notion is that using= such a parser you have a loop like while !eof obj =3D parser.ReadObjectAndStop() // parse error handling left as an exercise for the reader doWhateverWith(obj) eatZeroOrMoreWhiteSpaceCharacters() // assumes some sort of peekChar() end So yeah, requiring a SINGLE NEWLINE AND NOTHING ELSE would be simpler. But if you=E2=80=99re going to allow any other non-significant white space char= acters, then why bother requiring that one of them be a newline? On Tue, Mar 11, 2014 at 11:27 AM, Matthew Morley wrote: > I'm not advocating for comma separators... > > But having multiple top level JSON elements separated by a coma is > equivalent to processing an array structure. The initial [ and the closin= g > ] are implicitly mapped to the connection/stream/etc. start and end event= s. > > It is just a minor token replacement at the top level between elements, > which could be layered into some existing tooling. From this point of vie= w, > I would imagine the retooling is minor for either use case. It does mean > tools need to be depth aware. > > > On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams wro= te: > >> On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker >> wrote: >> > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray >> wrote: >> >> >> >> Heh, I wonder if there=E2=80=99d be any chance of getting consensus. = I can=E2=80=99t >> >> imagine ever using anything but Object Object Object with optional >> >> whitespace separator; unless we all agree on that going in I=E2=80=99= d >> pessimistic >> >> about anyone convincing anyone else... >> > >> > But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e. >> >> JSON text sequences would be a new Proposed Standard (if we go there) >> but like JSON, there exist uses of this "new" thing already -- that >> is, before we get to writing the RFC. >> >> The uses of JSON text sequences that I know of use newlines, not >> commas nor comma-and-newline. The reason for this is that these use >> cases are text logfile-like: the entries are lines, lines containing >> JSON texts -- usually compact texts, i.e., with no newlines in the >> text, and never more than one text per-line. >> >> For me other uses of JSON text sequences generally result from my use >> of jq, which also effectively separates texts with a newline. Note >> that jq doesn't need texts to be written compactly when parsing JSON >> text sequences. It happens though that if you write texts compactly >> followed by a newline then you can implement JSON text sequences with >> all existing JSON parsers. >> >> Switching to using a comma-and-newline would require significant >> retooling. Therefore I don't see it happening. Whereas just >> separating JSON texts with newlines is in use because it's always been >> the obvious thing to do. >> >> Nico >> -- >> > > > > -- > Matthew P. C. Morley > --047d7bd6aab28a742704f458fc7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My = assumption is that many (most? all?) JSON parsers can be altered to, when t= hey encounter a JSON text containing an object, just stop reading when they= hit the trailing =E2=80=9C}=E2=80=9D. =C2=A0So my notion is that using suc= h a parser you have a loop like=C2=A0

while !eof
=C2=A0 =C2=A0obj =3D parser.ReadOb= jectAndStop() // parse error handling left as an exercise for the reader
=C2=A0 =C2=A0doWhate= verWith(obj)
= =C2=A0 =C2=A0eatZeroOrMoreWhiteSpaceCharacters() =C2=A0// assumes some sort= of peekChar()
end

So yeah, requirin= g a SINGLE NEWLINE AND NOTHING ELSE would be simpler. =C2=A0But if you=E2= =80=99re going to allow any other non-significant white space characters, = =C2=A0then why bother requiring that one of them be a newline?


O= n Tue, Mar 11, 2014 at 11:27 AM, Matthew Morley <matt@mpcm.com> = wrote:
I'm not advocating for = comma separators...

But having multiple top level JSON elements sepa= rated by a coma is equivalent to processing an array structure. The initial= [ and the closing ] are implicitly mapped to the connection/stream/etc. st= art and end events.

It is just a minor token replacement at the top level between elements,= which could be layered into some existing tooling. From this point of view= , I would imagine the retooling is minor for either use case. It does mean = tools need to be depth aware.


On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams = <nico@crypton= ector.com> wrote:
On Tue, Mar 11, 2014 at 12:09 PM, Phill= ip Hallam-Baker <h= allam@gmail.com> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> Heh, I wonder if there=E2=80=99d be any chance of getting consensu= s. =C2=A0I can=E2=80=99t
>> imagine ever using anything but Object Object Object with optional=
>> whitespace separator; unless we all agree on that going in I=E2=80= =99d pessimistic
>> about anyone convincing anyone else...
>
> But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e.

JSON text sequences would be a new Proposed Standard (if we go there)=
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline. =C2=A0The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline. =C2=A0Note that jq doesn't need texts to be written compactly when parsing JSON text sequences. =C2=A0It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling. =C2=A0Therefore I don't see it happening. =C2=A0Whereas just=
separating JSON texts with newlines is in use because it's always been<= br> the obvious thing to do.

Nico
--



--
Matthew P. C. Morley

--047d7bd6aab28a742704f458fc7f-- From nobody Tue Mar 11 11:59:32 2014 Return-Path: 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 8E0471A07B7 for ; Tue, 11 Mar 2014 11:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 PtSsGRor0Eef for ; Tue, 11 Mar 2014 11:59:29 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (agjbgdcfdbea.dreamhost.com [69.163.253.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA861A077D for ; Tue, 11 Mar 2014 11:59:29 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id C38E12005D108 for ; Tue, 11 Mar 2014 11:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=tR1gTfJw9+mb97AREI4wT9dB+X8=; b=pJ6Om+jAbK0 wPiiwVPrpY/BvomYNOn/lOOX9zha2heKlCY9VuEYCX0ZrDZKtSshfIR1qnxD4SSs 2diZMlKvPeT1FC7k0VHQdgjbuRXiX7BhgB2cEwVCgHb/iP+vFNVCekuWliiGkV15 cbsieC0u77yd12u3AyaIFA//GQUHEgaU= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 776992005D106 for ; Tue, 11 Mar 2014 11:59:23 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so10217135wes.24 for ; Tue, 11 Mar 2014 11:59:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5tLPOvQaOlQqZn1+WjkkYxohj41M+XZTpEWKt9yAk7g=; b=Y0YGw5f0SZqGxN/V4WnaSPfr+lWtsqDGj4ir/vtsq1XcL1N/u38P5V0L71/kWKkjEi myn67ecbWzk4A4td+ojP0CtiWRkKfA8qwu89RHKZ2nUWTu+7Gqo5p77QN/KP139gYBI8 c9goGlK/K1+v2MJ4Xtb+XkaBkwwyDvAjBm7Y9PcaMXSUYxpyu1MJydR95E01kJdQWBPV a4J8BxNljam67pEOTZ7nnuZv/1/fYCTZf+jdAmKCooospzOjZoqOE4SmAml2WZWqaXlI U3RsCFW1YVySlXK+qloTsmR0It9MnTUGLgO59nsfcfoQNRB9NCAzGuptwO0N1IHI9cNy cZ3A== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr4438961wib.42.1394564362214; Tue, 11 Mar 2014 11:59:22 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 11:59:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 13:59:22 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Vm9Eg9-uHdrirOqth3Bj8xSvOO0 Cc: Paul Hoffman , Phillip Hallam-Baker , Matthew Morley , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 18:59:30 -0000 On Tue, Mar 11, 2014 at 1:35 PM, Tim Bray wrote: > My assumption is that many (most? all?) JSON parsers can be altered to, w= hen > they encounter a JSON text containing an object, just stop reading when t= hey > hit the trailing =E2=80=9C}=E2=80=9D. So my notion is that using such a = parser you have a > loop like That's true of arrays as well. It's also true of strings for any parser that permits them at the top-level= . It's only true, false, null, and numeric top-level values that require a disambiguation separator. Using a newline (or any other separator character or string) permits the parsing of any JSON text sequences with unmodified parsers. This is especially true when the JSON texts are encoded with no newlines and the separator is or has a newline. > while !eof > obj =3D parser.ReadObjectAndStop() // parse error handling left as an > exercise for the reader The key is being able to parse one text, then the next. If the texts self-delimit (e.g., they contain no embedded newlines and are terminated by a newline) then any JSON parser can be used to build a JSON text sequence parser. Even if a text contains a new line (e.g., after every element of an array or after every name or value in an object), one could parse a JSON text sequence even with the simplest JSON parsers (ones that have no incremental parsing capability). Thus I'd RECOMMEND that JSON text sequences consist of sequences of JSON texts encoded with no embedded newlines, and I'd REQUIRE that each text followed by a newline. Then the general case (any parser, incremental or not) is as simple as: while read line; do parse "$line" ... ... done > So yeah, requiring a SINGLE NEWLINE AND NOTHING ELSE would be simpler. B= ut Indeed, it's the simplest: because every language/runtime has a "read a line at a time" primitive. If your texts have embedded newlines and you have an incremental parser, you're still OK. Heck, even if you don't have an incremental parser, you'd be OK, though the result would be inefficient: buffer=3D while read line; do last_is_partial=3Dtrue if [[ -z $buffer ]] && ! parse "$line"...; then buffer=3D$line continue elif [[ -n $buffer ]]; then buffer+=3D$line if ! parse "$buffer"...; then continue fi fi last_is_partial=3Dfalse ... done if $last_is_partial; then # Report error ... fi > if you=E2=80=99re going to allow any other non-significant white space ch= aracters, > then why bother requiring that one of them be a newline? Because reading lines is a common (universal?) primitive. Sure, if you have an evented app and an incremental JSON parser then you'll be reading bytes till you get a complete entry, newline or not. Nico -- From nobody Tue Mar 11 12:20:08 2014 Return-Path: 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 ED0A41A07C6 for ; Tue, 11 Mar 2014 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 mPdZKldlBZgQ for ; Tue, 11 Mar 2014 12:20:04 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBD31A07B7 for ; Tue, 11 Mar 2014 12:20:03 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ec20so5980536lab.15 for ; Tue, 11 Mar 2014 12:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZtPwUqig87ry5tf9grwvdjmVyTaG89+lMoEIHkpgFOA=; b=HMQOvK6OWKkRqDeXzIBEjPJl9iWKzpFyKzkZWFw+L1QHkxNQ+hYoMqxy1OFzuXnl8M xVDSP0ohJB38pQbkKgBWHA4c1VbrODVO7FQlFso7BtbBdBCeybXr7k0qAtg/OV+dC2yV U+OVRrBt1BpkWyWCXJsbFXBNUnHUndb1raFPg4leKXuUFZ804SVDR/yMMzbhbZ2Ne4Qh jMZU7PZTXmSHWGLSHdX9+WlsTxGJjmyLjWgoIGrsNQqBatdvoutYcE6ysmU2SFMmezG9 DbMta5vtL29OWR1yDVcVWmw/RsBsLjXLia27zUfwe2hL6krJCSoXTe7DU9osRqgtalFC vHyA== MIME-Version: 1.0 X-Received: by 10.152.5.136 with SMTP id s8mr105524las.55.1394565597471; Tue, 11 Mar 2014 12:19:57 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Tue, 11 Mar 2014 12:19:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 15:19:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b8743a40da92904f4599bc7 Archived-At: http://mailarchive.ietf.org/arch/msg/json/5eUEMBtJJewKqUJxIyX_SzRinQU Cc: Paul Hoffman , Tim Bray , Matthew Morley , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:20:08 -0000 --047d7b8743a40da92904f4599bc7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams wrote: > On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker > wrote: > > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray wrote: > >> > >> Heh, I wonder if there'd be any chance of getting consensus. I can't > >> imagine ever using anything but Object Object Object with optional > >> whitespace separator; unless we all agree on that going in I'd > pessimistic > >> about anyone convincing anyone else... > > > > But JSON has comma separators, so {..}, {..}, {..} makes far more sense. > > JSON text sequences would be a new Proposed Standard (if we go there) > but like JSON, there exist uses of this "new" thing already -- that > is, before we get to writing the RFC. > > The uses of JSON text sequences that I know of use newlines, not > commas nor comma-and-newline. The reason for this is that these use > cases are text logfile-like: the entries are lines, lines containing > JSON texts -- usually compact texts, i.e., with no newlines in the > text, and never more than one text per-line. > > For me other uses of JSON text sequences generally result from my use > of jq, which also effectively separates texts with a newline. Note > that jq doesn't need texts to be written compactly when parsing JSON > text sequences. It happens though that if you write texts compactly > followed by a newline then you can implement JSON text sequences with > all existing JSON parsers. > > Switching to using a comma-and-newline would require significant > retooling. Therefore I don't see it happening. Whereas just > separating JSON texts with newlines is in use because it's always been > the obvious thing to do. > The constraint that the objects can't have newlines inside the object will require rather more retooling than a requirement that objects be separated by commas which is the existing JSON approach. I think finding a standard JSON way to meet this requirement is appropriate. Blessing a particular approach that isn't in the existing grammar is not AFIK. -- Website: http://hallambaker.com/ --047d7b8743a40da92904f4599bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams &l= t;nico@cryptonec= tor.com> wrote:
On Tue, Mar 11, 2014 at 12:0= 9 PM, Phillip Hallam-Baker <hallam@g= mail.com> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> Heh, I wonder if there’d be any chance of getting consensus.=  I can’t
>> imagine ever using anything but Object Object Object with optional=
>> whitespace separator; unless we all agree on that going in I&rsquo= ;d pessimistic
>> about anyone convincing anyone else...
>
> But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e.

JSON text sequences would be a new Proposed Standard (if we go there)=
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline.  The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline.  Note that jq doesn't need texts to be written compactly when parsing JSON text sequences.  It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling.  Therefore I don't see it happening.  Whereas just=
separating JSON texts with newlines is in use because it's always been<= br> the obvious thing to do.

The constraint= that the objects can't have newlines inside the object will require ra= ther more retooling than a requirement that objects be separated by commas = which is the existing JSON approach.

I think finding a standard JSON way to meet this requir= ement is appropriate. Blessing a particular approach that isn't in the = existing grammar is not AFIK. 

--
Websit= e: http://hallambaker.com/
--047d7b8743a40da92904f4599bc7-- From nobody Tue Mar 11 12:42:31 2014 Return-Path: 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 2A0FD1A07D7 for ; Tue, 11 Mar 2014 12:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 nTGe2b3mT-Iq for ; Tue, 11 Mar 2014 12:42:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (agjbgdcfdbhd.dreamhost.com [69.163.253.173]) by ietfa.amsl.com (Postfix) with ESMTP id 699041A07D4 for ; Tue, 11 Mar 2014 12:42:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id C188927BC07B for ; Tue, 11 Mar 2014 12:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ROr/U99ZgcUup1UZmlqW 1nHlhdo=; b=G8prDJYH/yaodzI8hQVHtkss5BEyglwECmI1Tzh2YC648AhQyd2a Dd39cTlCits1PSKTAtqTHYsUeoxcZ2VCHAhGXk5qmrH8Qd5A3gwgIPxCOI9s4f28 DB6iO2tyGB/9ooVJXxAlubsLdtdzGRqHx5vlw/MtEaW5r72NFeUaGPM= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 724C827BC06F for ; Tue, 11 Mar 2014 12:42:22 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so10668553wgh.12 for ; Tue, 11 Mar 2014 12:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FVErEmZVqOKEhlQZXtri1MNpnHm5WzYHC0lcBgMgEjw=; b=V5bV8e+dUoVzX3BSL2BBwL59bNYdAnxClDarzdOV2htZuxheKKk29VQ1NkNteCy2+C HEx7RA+z9tr1p1kalINScEqgG5YTBZH0WRjAs3MFRyPLIsBPuYfCDBJx5c24cccN7ny1 RCYa5D0aoLCitbZAb2mzeEagJr+G0qTt5aylRNRvM8iJwRZxZKUHE2zjec0wIh+HtcXR 2BiCNdXRKfSTqv2A3zLWfjExAJH+XfatcLIg0jWnXy5E2aGwY1UHe1ljHCy5+68S1dwa Pg5+JBT2DXQ2aX3Y20B71kXp4T1OeLAgR6iVEv7xwcMJimHei4Uh1BYv0hydcWIlnEbX VpZQ== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr702wjz.95.1394566941256; Tue, 11 Mar 2014 12:42:21 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 12:42:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 14:42:21 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/os6PmsK7u_IAwpX3iw-bim5oYbE Cc: Paul Hoffman , Tim Bray , Matthew Morley , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 19:42:29 -0000 On Tue, Mar 11, 2014 at 2:19 PM, Phillip Hallam-Baker wrote: > On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams > wrote: > The constraint that the objects can't have newlines inside the object will > require rather more retooling than a requirement that objects be separated > by commas which is the existing JSON approach. Actually, that isn't a constraint. It does help when you have parsers that don't work incrementally, but you can make do even if the objects/arrays have embedded newlines. See my reply to Tim about that. Nico -- From nobody Tue Mar 11 13:52:28 2014 Return-Path: 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 0365A1A07FA for ; Tue, 11 Mar 2014 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 eyav-4p4cOUu for ; Tue, 11 Mar 2014 13:52:25 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (agjbgdcfdbgc.dreamhost.com [69.163.253.162]) by ietfa.amsl.com (Postfix) with ESMTP id 664D71A07DB for ; Tue, 11 Mar 2014 13:52:25 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 83A1B584057 for ; Tue, 11 Mar 2014 13:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=OfvS/cQYij7w231Fb/fsqF3 6pTg=; b=AmT+R4RppqGHe6NEjwi8o0rodcssc2v7/elczvZ+3ZNNTRu9MIpx2mE TO9Ct7GlDAj4FA5MdEeeTjAy8OGv357ts+OvtgIRHoX32VbFw0+mO7TybZvdE+no wlpRSsJz7kjfc0pAYU2c/g+YjXkYntDKoYE0Ie3bHKs63TpR6jOo= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 365F7584055 for ; Tue, 11 Mar 2014 13:52:18 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so8298428wgh.22 for ; Tue, 11 Mar 2014 13:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=advCMMj08BZR4jfeC20V3TXTnW7AKHqY+N0EPVwSlJc=; b=Rdp0bjdNMek/jPbMyLixscdgLGHevDK+fMRmEOEdG+wvG2SUjZOoY++XGcK5lYTtXT 6tkTOEikFgS7HkaiHHsgL1Vl3awo+edR9f9Dur9TAJi4CEL6Mr7/gtlOmhmB64W2T5Ei 6kM+hEAovzGpy4b2+ngeBvbMPCcfq9OuGabbUG+VFCwcM9ECRZO3WN18Z1q37glQlrHt 2F38LJ00MZVAFiIvdr15ZBnkNoZmsOrc67tZuiVyPGGwX31x15i0BbVmcHh6jqNdPLem F1jM+LLGVANiF63sihLki533usFJcAcAKV9m3rUERXUqSQffmlYnH92buAz7QqgNlLRt gQYA== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr38851427wjb.12.1394571137074; Tue, 11 Mar 2014 13:52:17 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 13:52:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Mar 2014 15:52:17 -0500 Message-ID: From: Nico Williams To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/sYOQLoOivUAjeVFuDD5BfJ8DI3k Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 20:52:26 -0000 On Tue, Mar 11, 2014 at 1:20 PM, Nico Williams wrote: > Details: > > - the newline is REQUIRED when following any of "true", "false", > "null", or any numeric value, otherwise it is RECOMMENDED (but > optional) Just to clarify: it should be possible to build a JSON text sequence parser given the above and any existing JSON parser, even when the JSON texts do have embedded newlines (e.g., between array elements, ...). The rationale for using a newline is twofold: - it's roughly how text-based log files tend to work; - there's always a "readline" primitive about that can be used to build a JSON text sequence parser (in conjunction with a JSON parser, of course). And, of course, these are _texts_, so newlines help readability. And this: > - it will be RECOMMENDED that JSON texts written to JSON text > sequences be encoded with no newlines in the encoding. would only help implementors who lack an incremental JSON parser, but it would only help them if this were a requirement, which it shouldn't be, thus there's no point to this recommendation, so I'll just remove it. Nico -- From nobody Tue Mar 11 16:01:22 2014 Return-Path: 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 265041A0888 for ; Tue, 11 Mar 2014 16:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 IwhBOQQpMTJw for ; Tue, 11 Mar 2014 16:01:19 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 62B491A088D for ; Tue, 11 Mar 2014 16:01:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,634,1389704400"; d="scan'208";a="191106882" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Mar 2014 10:01:11 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7374"; a="157239432" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcani.tcif.telstra.com.au with ESMTP; 12 Mar 2014 10:01:11 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 12 Mar 2014 10:01:11 +1100 From: "Manger, James" To: Nico Williams Date: Wed, 12 Mar 2014 10:01:11 +1100 Thread-Topic: [Json] Proposal: JSON text sequence MIME type and Proposed Standard Thread-Index: Ac89a8+Am9XXEQ08Sgmfh22qtrI9KAAEfvWO Message-ID: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/YBvvPevAxNubKbpv--26aX5fRYw Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:01:21 -0000 A short spec on JSON sequences is a good idea, Nico. I agree that a newline is the best separator for creators to include, and a= lways including it is best. Some (most?) receivers will be more lenient and accept values separated by = any whitespace, or with no separator (for objects, arrays, and/or strings).= Perhaps it is best for interop to say receivers MUST be this lenient. -- James Manger On 12 Mar 2014 07:52, Nico Williams wrote: On Tue, Mar 11, 2014 at 1:20 PM, Nico Williams wrot= e: > Details: > > - the newline is REQUIRED when following any of "true", "false", > "null", or any numeric value, otherwise it is RECOMMENDED (but > optional) Just to clarify: it should be possible to build a JSON text sequence parser given the above and any existing JSON parser, even when the JSON texts do have embedded newlines (e.g., between array elements, ...). The rationale for using a newline is twofold: - it's roughly how text-based log files tend to work; - there's always a "readline" primitive about that can be used to build a JSON text sequence parser (in conjunction with a JSON parser, of course). And, of course, these are _texts_, so newlines help readability. And this: > - it will be RECOMMENDED that JSON texts written to JSON text > sequences be encoded with no newlines in the encoding. would only help implementors who lack an incremental JSON parser, but it would only help them if this were a requirement, which it shouldn't be, thus there's no point to this recommendation, so I'll just remove it. Nico -- _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From nobody Tue Mar 11 16:05:04 2014 Return-Path: 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 A82871A088E for ; Tue, 11 Mar 2014 16:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 Kb5IAgRI3Xys for ; Tue, 11 Mar 2014 16:05:01 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (unknown [69.163.253.179]) by ietfa.amsl.com (Postfix) with ESMTP id B891C1A087F for ; Tue, 11 Mar 2014 16:05:01 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id DD0C61DE060 for ; Tue, 11 Mar 2014 16:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XZYVNGjs0V4A3+nP+x8/ XJyZF9U=; b=N33YGVIHIXdtTGpMHAS/w4ztUS3lHUZdj6FjsEOZNGq7fQa/L2Es 6b5hWyBBYj+8K/8rQu12rgNFD7y/sE3rneZOsmqITBNEP0E00vz64hbVEemo8jYe hoUA71nU+wWANKeOs2kTldH9aKaZ/7nSkCiQr2K9NEwNHJ7f0+1Xfhk= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 90E491DE005 for ; Tue, 11 Mar 2014 16:04:55 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so6447737wgh.7 for ; Tue, 11 Mar 2014 16:04:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OBNIna1ljwFTcX2HkpljxpIARdoifipQY3gjTa59umg=; b=WitZPndLaGnbhJb81kcXwfB0yH/KhW1/7bm7MsSNsooBTZ3XP2uq3fdRBpO4vR9NGr ebHpTawgxVuDwlKkv+Nut2i2ci4ztgtt3MVkeUAl7639ZedxIZJsg+V83EPqNMZvDdRt srRO0omJ+z2YElkc9oy1A298jGI7tCsE6ogkihHBOfgVgQAQkxhNQpQovDklTN7teL2j 5fSxD48Eh9XVRQGn8fGEaOFxeh87Fk0qN9u9UfIDvPj4g/HQ8pEHwNzesyJSc6q6+Pfx sfb60lAcfF+xYxzxm7RaZ9WsjbdoeRWKuIzEeOw6y6F6/S1VwbvOQ8L1u2atf+Xxnugi ob3A== MIME-Version: 1.0 X-Received: by 10.194.85.75 with SMTP id f11mr9793502wjz.47.1394579094386; Tue, 11 Mar 2014 16:04:54 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 16:04:54 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Mar 2014 18:04:54 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Mw2OGkp4DD2OaEgEnmVx8blPMEA Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:05:03 -0000 On Tue, Mar 11, 2014 at 6:01 PM, Manger, James wrote: > A short spec on JSON sequences is a good idea, Nico. I'll submit an I-D soon. > I agree that a newline is the best separator for creators to include, and always including it is best. > > Some (most?) receivers will be more lenient and accept values separated by any whitespace, or with no separator (for objects, arrays, and/or strings). Perhaps it is best for interop to say receivers MUST be this lenient. Good point. Sequence parsers MUST be able to handle newline text separators and SHOULD be able to handle other whitespace, as well as no separator in the unambiguous cases. Sequence encoders SHOULD use a newline separator and MAY use other whitespace (with some guidance as to why newline is best); no need to mention when the separator may be omitted. Nico -- From nobody Tue Mar 11 16:08:49 2014 Return-Path: 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 E36311A088C for ; Tue, 11 Mar 2014 16:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 aLbJHzhOHPxN for ; Tue, 11 Mar 2014 16:08:45 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DAA581A087E for ; Tue, 11 Mar 2014 16:08:44 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WNVmo-00031G-Hw; Tue, 11 Mar 2014 19:08:38 -0400 Date: Tue, 11 Mar 2014 19:08:38 -0400 From: John Cowan To: Nico Williams Message-ID: <20140311230838.GA6812@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/OIxGDtYs1jE_cra_R-qLIyynCQc Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:08:47 -0000 Nico Williams scripsit: > I propose a new Proposed Standard and MIME type describing a "JSON > text sequence" as: a sequence of JSON texts separated by newlines. Since a JSON text is bracketed by optional whitespace, it makes sense to me that a JSON text sequence should be also bracketed by optional whitespace, with the values separated by mandatory whitespace. This is very simple. -- Some people open all the Windows; John Cowan wise wives welcome the spring cowan@ccil.org by moving the Unix. http://www.ccil.org/~cowan --ad for Unix Book Units (U.K.) (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif) From nobody Tue Mar 11 16:49:04 2014 Return-Path: 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 59CB11A0886 for ; Tue, 11 Mar 2014 16:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 Z316iay6LdBb for ; Tue, 11 Mar 2014 16:49:00 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (agjbgdcfdbfa.dreamhost.com [69.163.253.150]) by ietfa.amsl.com (Postfix) with ESMTP id A43211A0857 for ; Tue, 11 Mar 2014 16:49:00 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id E6EA52005D906 for ; Tue, 11 Mar 2014 16:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=V+FaKa32BwzvExWeTaTJ V7gyBdk=; b=Hh/vHJXkNLlkAR/E4PMszrIYFZfBSGcyroNnLrgcY8vGqGYL//hp qCnee9yvXd03SRXMGuu7o8JSjC1z+A74p4CxZYQ6ZiaV6ChhYT66kx7PHo97RxmH Xqt41S7g3/1ZsLEgzpZ5mrmXW8oPcvi9w1gHVJNlE/RCsLSA42G69dI= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id 8E7AB2005D901 for ; Tue, 11 Mar 2014 16:48:53 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so1642729wib.7 for ; Tue, 11 Mar 2014 16:48:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vHMlzWZsp7dGgTZZVrVIpfbk5AsZ1tAHNz0BKfez71w=; b=Hw1MwJ/O04P0yGAz0exYM9LsjHnoV70OyU8VWVdGhUw0F7qn9T/gLTv5YoPkeUjfS7 S9TlhaSWeTBr0KXOdsg4AYy9D8YW598Fsg0MLAWKl4JadSbwIuCSf1UhJBZfGkJzyKWa 22RaQ9ZJWVhgi9vRNrXMDeHN/dzd2I6ozGJ/f7ZisqC/v5G/laiA6+2zKrm4ql6wwX3D cH98VEGoDG7eJey18ZFrElZViUXAxXrj9xueafFB5sU2LktYxCQZMJyyCsRXrH56NMbP iWdyTX6k9i/cog0RKApm6AsBxQ+8DEppMtMpTHSso5FU+Zxj8SGFseuXESnoBabPeE1y D/EA== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr5178640wib.5.1394581732237; Tue, 11 Mar 2014 16:48:52 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 16:48:52 -0700 (PDT) In-Reply-To: <20140311230838.GA6812@mercury.ccil.org> References: <20140311230838.GA6812@mercury.ccil.org> Date: Tue, 11 Mar 2014 18:48:52 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/TalPbjc44StSwcL85Whvb6DeB_s Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 23:49:02 -0000 On Tue, Mar 11, 2014 at 6:08 PM, John Cowan wrote: > Nico Williams scripsit: > >> I propose a new Proposed Standard and MIME type describing a "JSON >> text sequence" as: a sequence of JSON texts separated by newlines. > > Since a JSON text is bracketed by optional whitespace, it makes sense > to me that a JSON text sequence should be also bracketed by optional > whitespace, with the values separated by mandatory whitespace. > This is very simple. Yes, it is. It has the benefit of ending the perennial debate over ambiguities created by allowing any value type at the top-level. In fact, no ambiguity was created except when JSON texts are expected to be followed by anything other than EOF (which was never contemplated by the original, IIUC). But since "JSON text sequence" is a useful and _used_ concept, the ambiguity issue does come up, and this is the best resolution (IMO). Nico -- From nobody Tue Mar 11 20:13:37 2014 Return-Path: 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 4AC441A08D3 for ; Tue, 11 Mar 2014 20:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 9hh8bG3G_rEG for ; Tue, 11 Mar 2014 20:13:33 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id BF5E01A08B4 for ; Tue, 11 Mar 2014 20:13:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,635,1389704400"; d="scan'208";a="191201256" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Mar 2014 14:13:26 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7374"; a="206152884" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 12 Mar 2014 14:12:21 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 12 Mar 2014 14:12:21 +1100 From: "Manger, James" To: Nico Williams Date: Wed, 12 Mar 2014 14:12:19 +1100 Thread-Topic: [Json] Proposal: JSON text sequence MIME type and Proposed Standard Thread-Index: Ac89flTq+71GEe1BRWeMeWxnieJKRgAIUFhA Message-ID: <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/fYUoW58i5JQe63vwoeTto7N2oRQ Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:13:35 -0000 PiA+IEkgYWdyZWUgdGhhdCBhIG5ld2xpbmUgaXMgdGhlIGJlc3Qgc2VwYXJhdG9yIGZvciBjcmVh dG9ycyB0byBpbmNsdWRlLA0KPiBhbmQgYWx3YXlzIGluY2x1ZGluZyBpdCBpcyBiZXN0Lg0KPiA+ DQo+ID4gU29tZSAobW9zdD8pIHJlY2VpdmVycyB3aWxsIGJlIG1vcmUgbGVuaWVudCBhbmQgYWNj ZXB0IHZhbHVlcw0KPiBzZXBhcmF0ZWQgYnkgYW55IHdoaXRlc3BhY2UsIG9yIHdpdGggbm8gc2Vw YXJhdG9yIChmb3Igb2JqZWN0cywgYXJyYXlzLA0KPiBhbmQvb3Igc3RyaW5ncykuIFBlcmhhcHMg aXQgaXMgYmVzdCBmb3IgaW50ZXJvcCB0byBzYXkgcmVjZWl2ZXJzIE1VU1QNCj4gYmUgdGhpcyBs ZW5pZW50Lg0KDQo+IEdvb2QgcG9pbnQuICBTZXF1ZW5jZSBwYXJzZXJzIE1VU1QgYmUgYWJsZSB0 byBoYW5kbGUgbmV3bGluZSB0ZXh0DQo+IHNlcGFyYXRvcnMgYW5kIFNIT1VMRCBiZSBhYmxlIHRv IGhhbmRsZSBvdGhlciB3aGl0ZXNwYWNlLCBhcyB3ZWxsIGFzDQo+IG5vIHNlcGFyYXRvciBpbiB0 aGUgdW5hbWJpZ3VvdXMgY2FzZXMuICBTZXF1ZW5jZSBlbmNvZGVycyBTSE9VTEQgdXNlIGENCj4g bmV3bGluZSBzZXBhcmF0b3IgYW5kIE1BWSB1c2Ugb3RoZXIgd2hpdGVzcGFjZSAod2l0aCBzb21l IGd1aWRhbmNlIGFzDQo+IHRvIHdoeSBuZXdsaW5lIGlzIGJlc3QpOyBubyBuZWVkIHRvIG1lbnRp b24gd2hlbiB0aGUgc2VwYXJhdG9yIG1heSBiZQ0KPiBvbWl0dGVkLg0KDQpZb3UgZG9uJ3QgcXVp dGUgZ3VhcmFudGVlIGludGVyb3Agd2l0aCAiZW5jb2RlcnMgTUFZIHVzZSBvdGhlciB3aGl0ZXNw YWNlIiBhbmQgInBhcnNlcnMgU0hPVUxEIGJlIGFibGUgdG8gaGFuZGxlIG90aGVyIHdoaXRlc3Bh Y2UiLg0KDQpUaGUgc3BlYyBuZWVkcyB0byBzYXk6IGVpdGhlciAiZW5jb2RlcnMgTVVTVCB1c2Ug YSBuZXdsaW5lIHNlcGFyYXRvciI7IG9yICJkZWNvZGVycyBNVVNUIGJlIGFibGUgdG8gaGFuZGxl IGFueSB3aGl0ZXNwYWNlIChpbmNsdWRpbmcgbm9uZSBpbiB0aGUgdW5hbWJpZ3VvdXMgY2FzZXMp Ii4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Tue Mar 11 20:49:03 2014 Return-Path: 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 84F071A039A for ; Tue, 11 Mar 2014 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 64xWb4zGWZR1 for ; Tue, 11 Mar 2014 20:49:00 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AA1A0398 for ; Tue, 11 Mar 2014 20:49:00 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WNa9v-00050B-NE; Tue, 11 Mar 2014 23:48:47 -0400 Date: Tue, 11 Mar 2014 23:48:47 -0400 From: John Cowan To: "Manger, James" Message-ID: <20140312034847.GA18511@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/vSMCs2dujvwDKPp3Nn65rXjyUMQ Cc: Nico Williams , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:49:02 -0000 Manger, James scripsit: > The spec needs to say: either "encoders MUST use a newline separator"; > or "decoders MUST be able to handle any whitespace (including none in > the unambiguous cases)". Or, as I suggest, "encoders MUST use whitespace". -- They do not preach John Cowan that their God will rouse them cowan@ccil.org A little before the nuts work loose. http://www.ccil.org/~cowan They do not teach that His Pity allows them --Rudyard Kipling, to drop their job when they damn-well choose. "The Sons of Martha" From nobody Tue Mar 11 20:49:14 2014 Return-Path: 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 22DCD1A03A7 for ; Tue, 11 Mar 2014 20:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9DNbRJrGJ2d9 for ; Tue, 11 Mar 2014 20:49:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 060D81A07C8 for ; Tue, 11 Mar 2014 20:49:10 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id la4so6207625vcb.3 for ; Tue, 11 Mar 2014 20:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jj8A1MIvdNLXDI+RD/u5FX3O0DhjD1mN/s/xUnt5ljw=; b=D4mHwXVwpL6MVXWucW4jBYw10Z3JRKWWL9jfShLlvlrZwWeVOI1q9jJv70rvsfWUD9 tGl6qrl4SR0eh5qrjGPjl56//LgWV5jhgrYNpFAuId/tAHxoNrg8uEJQWq89FGD1Tzh5 Ot4M7NYGSBUxSDo1H4hQ1Nsv1w/2O84uHhzJIX6X8t/3qRr/26Ls2R+UJfzKxhmyzAaj dkp9Xo8ff1k9WSO3lzn9juSXStweR0MH2yh/sBoeuHd42zA0oytwwJfosiFgIWcBmnrw p7b6YD2bWbniWQ6uAK/z/hz1Sb9kx1Rp/v+Ief0CiJPMO0tnlqeI69RTyoxwNA0HtmN1 sBlQ== X-Gm-Message-State: ALoCoQlC4WctnlIpk7gKmLByo3TFfjCG362zW9doABQt88kfUV3hVFNp2//pg1K3loYEITwP0/4u MIME-Version: 1.0 X-Received: by 10.52.34.137 with SMTP id z9mr8513084vdi.12.1394596144910; Tue, 11 Mar 2014 20:49:04 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Tue, 11 Mar 2014 20:49:04 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Mar 2014 20:49:04 -0700 Message-ID: From: Tim Bray To: "Manger, James" Content-Type: multipart/alternative; boundary=20cf30780f62d2d82604f460b769 Archived-At: http://mailarchive.ietf.org/arch/msg/json/P3DuV8tYk8D-3FpHOfd5e9UbWdk Cc: Nico Williams , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 03:49:13 -0000 --20cf30780f62d2d82604f460b769 Content-Type: text/plain; charset=UTF-8 Yeah, the options are: 1. zero or more whitespace characters 2. 1 or more whitespace characters 3. A specific required set of whitespace characters, for example \s*\n\s* or just \n On Tue, Mar 11, 2014 at 8:12 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > > > I agree that a newline is the best separator for creators to include, > > and always including it is best. > > > > > > Some (most?) receivers will be more lenient and accept values > > separated by any whitespace, or with no separator (for objects, arrays, > > and/or strings). Perhaps it is best for interop to say receivers MUST > > be this lenient. > > > Good point. Sequence parsers MUST be able to handle newline text > > separators and SHOULD be able to handle other whitespace, as well as > > no separator in the unambiguous cases. Sequence encoders SHOULD use a > > newline separator and MAY use other whitespace (with some guidance as > > to why newline is best); no need to mention when the separator may be > > omitted. > > You don't quite guarantee interop with "encoders MAY use other whitespace" > and "parsers SHOULD be able to handle other whitespace". > > The spec needs to say: either "encoders MUST use a newline separator"; or > "decoders MUST be able to handle any whitespace (including none in the > unambiguous cases)". > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf30780f62d2d82604f460b769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yea= h, the options are:

1. ze= ro or more whitespace characters
2. 1 or more whitesp= ace characters
= 3. A specific required set of whitespace characters, for example \s*\n\s* o= r just \n


On Tue,= Mar 11, 2014 at 8:12 PM, Manger, James <James.H.Manger@team= .telstra.com> wrote:
> > I agree that a new= line is the best separator for creators to include,
> and always including it is best.
> >
> > Some (most?) receivers will be more lenient and accept values
> separated by any whitespace, or with no separator (for objects, arrays= ,
> and/or strings). Perhaps it is best for interop to say receivers MUST<= br> > be this lenient.

> Good point. =C2=A0Sequence parsers MUST be able to handle newline text=
> separators and SHOULD be able to handle other whitespace, as well as > no separator in the unambiguous cases. =C2=A0Sequence encoders SHOULD = use a
> newline separator and MAY use other whitespace (with some guidance as<= br> > to why newline is best); no need to mention when the separator may be<= br> > omitted.

You don't quite guarantee interop with "encoders MAY use oth= er whitespace" and "parsers SHOULD be able to handle other whites= pace".

The spec needs to say: either "encoders MUST use a newline separator&q= uot;; or "decoders MUST be able to handle any whitespace (including no= ne in the unambiguous cases)".

--
James Manger
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf30780f62d2d82604f460b769-- From nobody Tue Mar 11 21:02:20 2014 Return-Path: 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 263031A03A5 for ; Tue, 11 Mar 2014 21:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 5ZaKB0NUkaVz for ; Tue, 11 Mar 2014 21:02:19 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (unknown [69.163.253.179]) by ietfa.amsl.com (Postfix) with ESMTP id 078BE1A039A for ; Tue, 11 Mar 2014 21:02:18 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 115A71DE059 for ; Tue, 11 Mar 2014 21:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0ByGTvEHI0yb9LlXpdqu fj9V48Q=; b=ViU2EotjxO3ey3d0ra8LeTCDytOssMRaF7uQJxUJHjtOiWXNCn9r YaGWcxtV6d8FnrNozMTgA0mVJn6w6ZZXNb/COmIifAzOiLR+jTzmoTLUri7kHxby Qiis9d1tBUqXDLOCwW0xshuXFheTSqeVgPfSSkl+WV0vvKBVMH27Tjs= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id BADC21DE005 for ; Tue, 11 Mar 2014 21:02:10 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so10934275wes.14 for ; Tue, 11 Mar 2014 21:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ixV8HZ9tLpsFB80Jx/XoGbKlKeXmRJKlH6STv+Qp0S8=; b=B6sjBCNsgAO+dADJActQ59s10IFtPUza3q2NHJQ64meYBMdw92ClddbNI6lg4eLLjI EAiCaIGneVYUsUyPdrIjm0BjeBuJfro/nKL4XgvsUlKzM6B9Q3hUzyCIwHDQyHr9ojdv VG6DiE3rhedESTJUafsl+3UfHcuZszRAxypERsxDKaS55ib+N0h2KWtbjhq1MoNpk49A yL8406gRX0lM/dSpt2cftpbn2ptafTUi8FdIr5ZIDPUnNd08mbir7fZAwEvVOnvpi8MC osNpDBemw1jZGgNGrTMYerWx6CLLQLb7eWLoWZbwhVfKfzwNa2vQLaPebd4qGqWdNlrg J50g== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr5787153wib.5.1394596929749; Tue, 11 Mar 2014 21:02:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 21:02:09 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Mar 2014 23:02:09 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/sVZ1KSQ7KeOZEPduMmdbTmD3SYQ Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 04:02:20 -0000 On Tue, Mar 11, 2014 at 10:49 PM, Tim Bray wrote: > Yeah, the options are: > > 1. zero or more whitespace characters Not an option for values where that would result in ambiguity. (E.g., two top-level numeric values in a row.) > 2. 1 or more whitespace characters > 3. A specific required set of whitespace characters, for example \s*\n\s* or > just \n Given that there's no such thing as an empty JSON text, clearly any number of JSON text separators is logically the same as one. That makes (2) and (3) OK. jq allows any whitespace to separate JSON texts in input sequences, but it always uses \n to separate texts when outputting JSON text sequences. So I'm inclined to go for (2). Nico -- From nobody Tue Mar 11 21:02:52 2014 Return-Path: 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 2CCBE1A08A2 for ; Tue, 11 Mar 2014 21:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 Awg7e4Sb9mkQ for ; Tue, 11 Mar 2014 21:02:50 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (agjbgdcfdbfc.dreamhost.com [69.163.253.152]) by ietfa.amsl.com (Postfix) with ESMTP id 301981A0398 for ; Tue, 11 Mar 2014 21:02:50 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 2CB272005D107 for ; Tue, 11 Mar 2014 21:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=aB4BNZmS6IgIbxoszEqx Otk++ak=; b=MZU6XaJx0MPeLtEtu3pwdplsGGR18fiJ2qKz/QcQlFMfzHMWCDDA 8JFrNxJMooS4wESNoCo+W8xYz3Nlx/DzEITnwDefjAfLjPyHb31RsGCg5e7ByjxA A8zzuswVGsmhKU5g9R0quHKOBwireqOMtZTfNbvr986HsPTpKVLe66Q= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id D2FA32005D102 for ; Tue, 11 Mar 2014 21:02:43 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so1808590wib.15 for ; Tue, 11 Mar 2014 21:02:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M2VMIZHdQRE6QXO+Gt1kj3sI/7oghaEK2EB1ZYRS7oM=; b=VM9qLNPq4kFmwmyGCb1uk8HeVkuSm3sPkvrX4itfanwxTx+LaIDeSjY/8d7DAT1c5O 4VEFU56Dd8vjMPz2Xsrjlr6JVPlIS8VyBO1gkEte6egMR9EpaUOf1cOd5Yt7pCvSa8nY b6zkbU9Ep8qQ0WwjkoKgHD5gH+43b3Z/lCJumNHmWn38/Ya5MgWWGw6E2acb/qmoIbwG AtLUc8jMGz6lHj4y3RiO3MMYeNdGGu61hulWiMcFdjZ/7kbWcq681coWVlpviKehiaPT b3yaQj0ZLeg7HDYRKQMYcKNlknIAsDBALyzmq31yxuyyQNYx0POMDD5fNuzk3kcaqnMp iCOw== MIME-Version: 1.0 X-Received: by 10.181.13.40 with SMTP id ev8mr5788279wid.0.1394596962640; Tue, 11 Mar 2014 21:02:42 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 21:02:42 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Mar 2014 23:02:42 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/DdJWCv-5fz9w0KGostcW1MWzPtk Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 04:02:51 -0000 On Tue, Mar 11, 2014 at 10:12 PM, Manger, James wrote: > You don't quite guarantee interop with "encoders MAY use other whitespace" and "parsers SHOULD be able to handle other whitespace". > > The spec needs to say: either "encoders MUST use a newline separator"; or "decoders MUST be able to handle any whitespace (including none in the unambiguous cases)". Right you are. I'll go with the latter. Nico -- From nobody Tue Mar 11 21:26:02 2014 Return-Path: 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 7DE511A08D3 for ; Tue, 11 Mar 2014 21:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 S2qMOVHCxd3F for ; Tue, 11 Mar 2014 21:25:52 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 892F21A03AC for ; Tue, 11 Mar 2014 21:25:52 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so9427166veb.23 for ; Tue, 11 Mar 2014 21:25:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W+Sq20jJ0J53GSv8nIEAbaO093zspop5YfFzpYRdNe0=; b=Iy+ZM3etYxgUHToXZhmyRNyAY0GiGRs7KYNWRqB4KaWCGFAF3u3G2Nbt0P7ye0z3tz FUegKhMPEXcCtmRx6IDE/xhXb8tPmLUJkGo//SDwo3vg/uA82z67oUleeydpyL4fvj8Z 00ZipJFGrCuHd4qGbink61KuyA/ebWCW4Eyg6NkaFDdyli2D8wkDO/RKNW2p/h0CjqTO SRh2GQUZB/6Kl5Xid1gOpEjhtSDljFqiRml6eSazzAsKx/jj5G3hyciV0i+bUSERn1oW ufplmV+g5we0S7FfLqtGZD1v4h2PaxAHv4w8SwaQTwCGoGEdz/8Nb0lDVw71Bd6RHPXW FKOQ== X-Gm-Message-State: ALoCoQl0rnmNuNG6nGfIDCV3eaCFwEtNswrsnyjx3HQeWisDGTsHO9B7KSmB3/rvNnd/C5HQhfyc MIME-Version: 1.0 X-Received: by 10.52.34.137 with SMTP id z9mr8608709vdi.12.1394598346472; Tue, 11 Mar 2014 21:25:46 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Tue, 11 Mar 2014 21:25:46 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 11 Mar 2014 21:25:46 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=20cf30780f620bd40504f4613b51 Archived-At: http://mailarchive.ietf.org/arch/msg/json/33ki88Mu6dL1aFKXjdVr881DvIQ Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 04:25:57 -0000 --20cf30780f620bd40504f4613b51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Except for, in this kind of application, I think it=E2=80=99s really foolis= h to write out anything but objects. In which case you could theoretically have no separators. I lean to \s+ because as soon as you see the first char, you=E2=80=99re at = the start of the next legal JSON text. On Tue, Mar 11, 2014 at 9:02 PM, Nico Williams wrote= : > On Tue, Mar 11, 2014 at 10:49 PM, Tim Bray wrote: > > Yeah, the options are: > > > > 1. zero or more whitespace characters > > Not an option for values where that would result in ambiguity. (E.g., > two top-level numeric values in a row.) > > > 2. 1 or more whitespace characters > > 3. A specific required set of whitespace characters, for example > \s*\n\s* or > > just \n > > Given that there's no such thing as an empty JSON text, clearly any > number of JSON text separators is logically the same as one. That > makes (2) and (3) OK. > > jq allows any whitespace to separate JSON texts in input sequences, > but it always uses \n to separate texts when outputting JSON text > sequences. So I'm inclined to go for (2). > > Nico > -- > --20cf30780f620bd40504f4613b51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exc= ept for, in this kind of application, I think it=E2=80=99s really foolish t= o write out anything but objects. In which case you could theoretically hav= e no separators.=C2=A0

I lean to \s+ because as soon = as you see the first char, you=E2=80=99re at the start of the next legal JS= ON text.=C2=A0


On Tue,= Mar 11, 2014 at 9:02 PM, Nico Williams <nico@cryptonector.com>= wrote:
On Tue, Mar 11, 2014 at 10:4= 9 PM, Tim Bray <tbray@textuality= .com> wrote:
> Yeah, the options are:
>
> 1. zero or more whitespace characters

Not an option for values where that would result in ambiguity. =C2=A0= (E.g.,
two top-level numeric values in a row.)

> 2. 1 or more whitespace characters
> 3. A specific required set of whitespace characters, for example \s*\n= \s* or
> just \n

Given that there's no such thing as an empty JSON text, clearly a= ny
number of JSON text separators is logically the same as one. =C2=A0That
makes (2) and (3) OK.

jq allows any whitespace to separate JSON texts in input sequences,
but it always uses \n to separate texts when outputting JSON text
sequences. =C2=A0So I'm inclined to go for (2).

Nico
--

--20cf30780f620bd40504f4613b51-- From nobody Tue Mar 11 22:03:21 2014 Return-Path: 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 C6DDB1A07D5 for ; Tue, 11 Mar 2014 22:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no 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 QvB6m9y95Nod for ; Tue, 11 Mar 2014 22:03:19 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (unknown [69.163.253.144]) by ietfa.amsl.com (Postfix) with ESMTP id E879D1A055D for ; Tue, 11 Mar 2014 22:03:18 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id A6BA12005D10A for ; Tue, 11 Mar 2014 22:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZGJ6xXE7eGGhNkM4Tv80 xYv2Fgs=; b=qkHRO0WQGGVHPBWiUul9GEgzjI/nrrF32Vz83fyxJO9Ayn4FhEyP sNmD7jnwcgIHYJuPRGfhjMdC16I+CkHA1aZvnIuu+Zj7HIPLDB9IjpglgAhraNFt Ufe7WlGWZYFLHAafC9Hgu26Hg7PR4k7gztXxr96MPnPepoy+sEYrDQc= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 5AD962005D109 for ; Tue, 11 Mar 2014 22:03:11 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so11056482wgg.14 for ; Tue, 11 Mar 2014 22:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gfeZHvVmrzaMU4B068z51tyRdyE9NfIaJ+tD4V+wQqw=; b=YXisZ0wQYwz783EKuJijkbtyUtjNlMCNdMQTBfWJvuEkUpn7doCabWO6UeCCx+RTkP 4JoUGRFVq4uA2BA+jkXzVNt220HDxjq4SSjWQmOjWlUapsulg3lGOjtpPotVzQW/MLrf 1RsX1av3ldWQOqaAS93uHlb+S7lkSzb9C9tYg3BUDYxmNJll1AqbucRTL/+C1PRuA/r3 gqCG5DTUYSOjixvblRWCEONgbMfndLLqqxfuak0dLd6gu/fuyqWLca6fJVvuvZ9Nr+JI NbkVkNwvxSRF+mMq5S32EZQJYxd5Gmg5AfwC7joPdX2+L8ww87/7ZQAGL53btIyQDMxq b5qw== MIME-Version: 1.0 X-Received: by 10.194.60.37 with SMTP id e5mr39109454wjr.32.1394600590101; Tue, 11 Mar 2014 22:03:10 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 11 Mar 2014 22:03:10 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 12 Mar 2014 00:03:10 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: multipart/alternative; boundary=047d7ba979dac6d60304f461c055 Archived-At: http://mailarchive.ietf.org/arch/msg/json/t1cSBklv4ax2zD8K-TH0ZhwZrd8 Cc: Nico Williams , "Manger, James" , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 05:03:21 -0000 --047d7ba979dac6d60304f461c055 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 11, 2014, Tim Bray wrote: > Except for, in this kind of application, I think it=E2=80=99s really fool= ish to > write out anything but objects. In which case you could theoretically hav= e > no separators. > I don't think that's going to change running code. Indeed, this is about writing down what's actually been implemented and deployed that doesn't suffer from ambiguities. You also seem to want all JSON texts to be objects, but wanting ain't getting :) > I lean to \s+ because as soon as you see the first char, you=E2=80=99re a= t the > start of the next legal JSON text. > The separator can be whitespace. It can be any whitespace recognized as such in the JSON ABNF. It could be a subset of that. It also could be any character or string of them that can't start a JSON value's encoding. Since in practice existing apps use whitespace, we should use whitespace. If other apps can be found using ", " or "," or whatever, we might be able to require parser support for all of them or else define multiple MIME types. Since any contiguous sequence of separators cannot yoeld an empty JSON text (since we've not defined the meaning of such a thing), And given what apps like jq apps do, I think any number of contiguous separators must be equivalent to just one. Also, it's much better to follow a text with a separator than to only precede them with a separator. This is so parsers needn't wait for the next text or EOF before yielding a true/false/null/numeric top-level value. Finally, I think we should require that sequence parsers be able to handle missing separators where they aren't necessary to disambiguate texts. Nico -- --047d7ba979dac6d60304f461c055 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 11, 2014, Tim Bray <tbray@textuality.com> wrote:
Except for, in this = kind of application, I think it=E2=80=99s really foolish to write out anyth= ing but objects. In which case you could theoretically have no separators.= =C2=A0

I don't think that's going to chan= ge running code. =C2=A0Indeed, this is about writing down what's actual= ly been implemented and deployed that doesn't suffer from ambiguities. = =C2=A0You also seem to=C2=A0want all JSON texts to be objects, but wanting = ain't getting :)
=C2=A0
I lean to \s+ because as soon = as you see the first char, you=E2=80=99re at the start of the next legal JS= ON text.=C2=A0

The separator can=C2=A0be whitespace. =C2= =A0It can be any whitespace recognized as such in the JSON ABNF. =C2=A0It c= ould be a subset of that. =C2=A0It also could be any character or string of= them=C2=A0that can't start a JSON value's encoding. =C2=A0Since in= practice existing apps use whitespace, we should use whitespace. =C2=A0If = other apps can be found using ", " or "," or whatever, = we might be able to require parser support for all of them or else define m= ultiple MIME types.

Since any contiguous=C2=A0sequence of separators cannot yoel= d an empty JSON text (since we've not defined the meaning of such a thi= ng), And given what apps like jq apps do, I think any number of contiguous = separators must be equivalent to just one.

Also, it's much better to follow a text with a sepa= rator than to only precede them with a separator. =C2=A0This is=C2=A0so par= sers needn't wait for the next text or EOF before yielding a true/false= /null/numeric top-level value.

Finally, I think we should require that sequence=C2=A0p= arsers be able to handle missing separators where they aren't necessary= to disambiguate texts.

Nico
--=C2=A0 --047d7ba979dac6d60304f461c055-- From nobody Tue Mar 11 22:19:16 2014 Return-Path: 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 389671A055D for ; Tue, 11 Mar 2014 22:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 fYXn8akhXhGi for ; Tue, 11 Mar 2014 22:19:13 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id BD6B21A04A3 for ; Tue, 11 Mar 2014 22:19:12 -0700 (PDT) Received: from newyork.local.box ([80.187.100.104]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0Mb8xf-1Wc6HR07LP-00Ki4W for ; Wed, 12 Mar 2014 06:19:06 +0100 Message-ID: <531FEE49.3060807@drees.name> Date: Wed, 12 Mar 2014 06:19:05 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: json@ietf.org References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> <20140312034847.GA18511@mercury.ccil.org> In-Reply-To: <20140312034847.GA18511@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4RAYcY5t5inf5c++KpO0LDOOtYhHEiLkCgtYYD8d9ShwOZSQofP 4joj57CIMh8l4lvWgNm9A0KxAeVJ/WTBOepw9IjOAfGV7uiF83inQQgz+fAUqrfCsThRyZB Qoaj1hoQVH1OUr3073ugzXyTKH5lT1svglT9rqYeY9Or2P4uJLWwjA3v8RZgJiJ2bcR7yBC ZZipgubF+zYnQv6ok4wmw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/bljEsYPvcn2JLMvkQbEzSQVzreI Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 05:19:14 -0000 On 2014-03-12 04:48 +01:00, John Cowan wrote: > Manger, James scripsit: > >> The spec needs to say: either "encoders MUST use a newline separator"; >> or "decoders MUST be able to handle any whitespace (including none in >> the unambiguous cases)". > > Or, as I suggest, "encoders MUST use whitespace". + 1 {"Greeting":"All the best"} {"Stefan":true} From nobody Wed Mar 12 01:36:36 2014 Return-Path: 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 C08CC1A0915 for ; Wed, 12 Mar 2014 01:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=no 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 jgig2EZmEpUX for ; Wed, 12 Mar 2014 01:36:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 876A91A091F for ; Wed, 12 Mar 2014 01:36:31 -0700 (PDT) Received: from Vostro3500 ([2.34.218.166]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAyVY-1WFz8F28Ci-009zT1; Wed, 12 Mar 2014 09:36:15 +0100 From: "Markus Lanthaler" To: "'Nico Williams'" , "'Tim Bray'" References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Date: Wed, 12 Mar 2014 09:36:11 +0100 Message-ID: <00c201cf3dce$210c3840$6324a8c0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac89sGJQlLbupa6qSXK5sE5tkky3AgAHWVJw Content-Language: de X-Provags-ID: V03:K0:gyuZP+l+R+Xoysp76WmCFsVlMN5s+RlWxvZXK1pwbeHwB4m3D+1 xBO9P/R85htLJP87UME+ANP2lQIaiSqek0RUUuHcMC7UnE54W/dyFgPCnIo5qjIe5tfufbM K2BWgh5D4EusRipij8vK0RvoWFkdD3ltVTWRkxNC/WtDCQwd6I6S44aq8h/VbAZ+hAZMh2f s1BGumAnEGtxaAzJkSc3A== Archived-At: http://mailarchive.ietf.org/arch/msg/json/tGa6lZ0ddOeFo6vpyym0-VssmDQ Cc: "'Manger, James'" , json@ietf.org Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 08:36:33 -0000 On Wednesday, March 12, 2014 6:03 AM, Nico Williams wrote: On Tuesday, March 11, 2014, Tim Bray wrote: > > I lean to \s+ because as soon as you see the first char, = you=E2=80=99re > > at the start of the next legal JSON text.=20 > > The separator can be whitespace. It can be any whitespace recognized > as such in the JSON ABNF. It could be a subset of that. It also > could be any character or string of them that can't start a JSON = value's > encoding. Since in practice existing apps use whitespace, we should = use > whitespace. If other apps can be found using ", " or "," or whatever, > we might be able to require parser support for all of them or else = define > multiple MIME types. Given that "," is already used as separator in objects and arrays, I = think it would make sense to at least include that as additional = separator (and not just whitespace). Please let's not create multiple = media types. -- Markus Lanthaler @markuslanthaler From nobody Wed Mar 12 02:45:03 2014 Return-Path: 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 64C2F1A093B for ; Wed, 12 Mar 2014 02:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 EgnuvgLZAJDu for ; Wed, 12 Mar 2014 02:44:57 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE91A093F for ; Wed, 12 Mar 2014 02:44:57 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2C9igKx013828; Wed, 12 Mar 2014 18:44:42 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2812_70b7_efdb21fa_a9ca_11e3_85a3_001e6722eec2; Wed, 12 Mar 2014 18:44:41 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 93183C048C; Wed, 12 Mar 2014 18:44:41 +0900 (JST) Message-ID: <53202C80.1070204@it.aoyama.ac.jp> Date: Wed, 12 Mar 2014 18:44:32 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/t3uvvqUZKNeIuGDqY9SudljwYDM Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 09:45:01 -0000 On 2014/03/12 04:19, Phillip Hallam-Baker wrote: > On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams wrote: >> JSON text sequences would be a new Proposed Standard (if we go there) >> but like JSON, there exist uses of this "new" thing already -- that >> is, before we get to writing the RFC. > I think finding a standard JSON way to meet this requirement is > appropriate. Blessing a particular approach that isn't in the existing > grammar is not AFIK. For the record, I strongly agree. Seeing claims that we need a separate spec just because an initial '[', interleaving ','s, and a potential(1) final ']' is too much to deal with really surprises me. At the utmost, this might become an Informational RFC if some people really, really want it, but it should NOT become a working item of this group, nor should it go to standards track. Why? JSON is great, but the more variation we get, the more we end up with a *big mess*, even if every step may be small and look good. As far as I have heard (no first hand experience, fortunately), CORBA ended up that way. Many people, in particular in the JSON community, see XML that way. Similar things have been said about ASN-1, although that may have been complicated from the start (again, fortunately no first hand experience). Maybe JSON is just next in line. Regards, Martin. (1) When you write out a log, there's no need to actually write the final ']' and then replace it by a ','. XMPP did something very similar for XML streaming, please see http://tools.ietf.org/html/rfc6120#section-4. In JSON, it's slightly trickier because you need an explicit separating comma, and a 'dummy' element before the closing ']', but that's not rocket science and well worth the effort to avoid format splits. From nobody Wed Mar 12 04:27:04 2014 Return-Path: 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 957DC1A095B for ; Wed, 12 Mar 2014 04:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 57a3uDIhBDQA for ; Wed, 12 Mar 2014 04:27:01 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 98F5A1A0959 for ; Wed, 12 Mar 2014 04:27:00 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so6427583lbi.41 for ; Wed, 12 Mar 2014 04:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yG7jVtQJyrGxkMpR0R717AmFzIh5pJp+U/latJ8LZj4=; b=XI+gIwnpARox0OYLVeQyFp03qakoBHQ62SEScOBkYflC3Q2SYSoc8/KluOknkd3ni2 kk6K/U330lSnjF32lMLercxvZ3dFZLoRn4tngp1jsRzBQuNq1odn8YYIf7gQCkanNCFV QPIlXd9OHOKfgrZJJAfgjQNsV+dCayVLBaMT4SMyD4WyrcvrrhrhGFMeAdAPwNKkbmMb OlbYurnSNG4xF6cWyRdmTSlmhhzTF7g5lK3twnhEWZiyK+smT+ZLbh8VH6r+Xf6slsFy 3jkfJ9ateqc35zeU08C2ORkr1d3eJXcIQ/lfpVeRdGcAqWLv5o4xQgFLVTKq4YkyXIg2 0y7Q== MIME-Version: 1.0 X-Received: by 10.152.5.136 with SMTP id s8mr180240las.55.1394623613885; Wed, 12 Mar 2014 04:26:53 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Wed, 12 Mar 2014 04:26:53 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 12 Mar 2014 07:26:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b8743a419e39004f4671dcd Archived-At: http://mailarchive.ietf.org/arch/msg/json/N4VZVOnJWIzsg90tz6cDH0X8g28 Cc: Nico Williams , "Manger, James" , "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 11:27:02 -0000 --047d7b8743a419e39004f4671dcd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 11:49 PM, Tim Bray wrote: > Yeah, the options are: > > 1. zero or more whitespace characters > 2. 1 or more whitespace characters > 3. A specific required set of whitespace characters, for example \s*\n\s* > or just \n > or 4. use the JSON separator character, the comma -- Website: http://hallambaker.com/ --047d7b8743a419e39004f4671dcd Content-Type: text/html; charset=ISO-8859-1



On Tue, Mar 11, 2014 at 11:49 PM, Tim Bray <tbray@textuality.com> wrote:
Yeah, the options are:

1. zero or more whitespace characters
2. 1 or more whitespace characters
3. A specific required set of whitespace characters, for example \s*\n\s* or just \n

or

4. use the JSON separator character, the comma





--
Website: http://hallambaker.com/
--047d7b8743a419e39004f4671dcd-- From nobody Wed Mar 12 04:35:19 2014 Return-Path: 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 EA4F11A0960 for ; Wed, 12 Mar 2014 04:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 7Qi3LtPXATWb for ; Wed, 12 Mar 2014 04:35:12 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E8B261A0968 for ; Wed, 12 Mar 2014 04:35:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so6567542lbj.31 for ; Wed, 12 Mar 2014 04:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qle/FSQYuiEimO1GI1IkXM+WmYoyAEjsrOJTGJwMEyk=; b=DaQa0IrKy8qJ1Qs1Bbnlh22ED8QfPsL6z3pgMvmHRLmIAQ4TjuklChl72FUOkQX/LY dTtu8MFi3TU6peI/wcau55Srt7rFXMqKFeFefYytMwauNRBQ86Sp5CKs4GPby4VOeSaY U/ujR/8M4Sl0UWb1UEW7ZgFSYzkodXiWXhtXoaaE9ilLeHZe/f4eLuhHzrrXsgoHEzkR U+h3VIdpavmzyOxwaWlctoZf5J/BjJpOo22SS8zP2NQiIfuaaWYqsXHGFBN4OID+bxdZ Gi/zuo9Ki4+ja/gYHmSOh6jFHsT3qrUQMEpknAp2r69kDQj+JJ1gjSHCcUW+xtYyg85o f9EQ== MIME-Version: 1.0 X-Received: by 10.153.11.163 with SMTP id ej3mr31561723lad.17.1394624105263; Wed, 12 Mar 2014 04:35:05 -0700 (PDT) Received: by 10.112.37.168 with HTTP; Wed, 12 Mar 2014 04:35:05 -0700 (PDT) In-Reply-To: <53202C80.1070204@it.aoyama.ac.jp> References: <53202C80.1070204@it.aoyama.ac.jp> Date: Wed, 12 Mar 2014 07:35:05 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=001a1134635a63b79504f4673af3 Archived-At: http://mailarchive.ietf.org/arch/msg/json/TAB5YaLB7Nq5AvCcnyK1vpq8YdY Cc: Nico Williams , Tim Bray , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 11:35:14 -0000 --001a1134635a63b79504f4673af3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 12, 2014 at 5:44 AM, "Martin J. D=FCrst" wrote: > On 2014/03/12 04:19, Phillip Hallam-Baker wrote: > >> On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams > >wrote: >> > > JSON text sequences would be a new Proposed Standard (if we go there) >>> but like JSON, there exist uses of this "new" thing already -- that >>> is, before we get to writing the RFC. >>> >> > I think finding a standard JSON way to meet this requirement is >> appropriate. Blessing a particular approach that isn't in the existing >> grammar is not AFIK. >> > > For the record, I strongly agree. > > Seeing claims that we need a separate spec just because an initial '[', > interleaving ','s, and a potential(1) final ']' is too much to deal with > really surprises me. > The final ']' completely kills the use of append only logs. Which means that you can't rely on the O/S append operation to give atomicity. So there is a performance and a security issue here. > At the utmost, this might become an Informational RFC if some people > really, really want it, but it should NOT become a working item of this > group, nor should it go to standards track. > > Why? JSON is great, but the more variation we get, the more we end up wit= h > a *big mess*, even if every step may be small and look good. > I don't think that is what happened to XML or CORBA. The CORBA people had no idea of how to communicate what they were attempting to do. Plus they were trying to exchange C++ objects that weren't C++ objects at a time when C++ was not functional or stable. XML is the way it is because it is trying to be a document markup not a data markup. > As far as I have heard (no first hand experience, fortunately), CORBA > ended up that way. Many people, in particular in the JSON community, see > XML that way. Similar things have been said about ASN-1, although that ma= y > have been complicated from the start (again, fortunately no first hand > experience). > If we stick to commas then the production already exists in the spec: json-text =3D ws-value json-texts =3D ws-value (',' ws-value) --=20 Website: http://hallambaker.com/ --001a1134635a63b79504f4673af3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 12, 2014 at 5:44 AM, "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2014/03/12 04:19, Phillip= Hallam-Baker wrote:
On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams <nico@cryptonector.com>wrote:

JSON text sequences would be a new Proposed Standard (if we go there)
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

I think finding a standard JSON way to meet this requirement is
appropriate. Blessing a particular approach that isn't in the existing<= br> grammar is not AFIK.

For the record, I strongly agree.

Seeing claims that we need a separate spec just because an initial '[&#= 39;, interleaving ','s, and a potential(1) final ']' is too= much to deal with really surprises me.

The final ']' completely kills the use of append only logs. Wh= ich means that you can't rely on the O/S append operation to give atomi= city.

So there is a performance and a security iss= ue here.

=A0
At the utmost, this might become an Informational RFC if some people really= , really want it, but it should NOT become a working item of this group, no= r should it go to standards track.

Why? JSON is great, but the more variation we get, the more we end up with = a *big mess*, even if every step may be small and look good.

I don't think that is what happened to XML or COR= BA.

The CORBA people had no idea of how to communicate what= they were attempting to do. Plus they were trying to exchange C++ objects = that weren't C++ objects at a time when C++ was not functional or stabl= e.

XML is the way it is because it is trying to be a docum= ent markup not a data markup.=A0


= =A0
As far as I have heard (no first hand experience, fortunately), CORBA ended= up that way. Many people, in particular in the JSON community, see XML tha= t way. Similar things have been said about ASN-1, although that may have be= en complicated from the start (again, fortunately no first hand experience)= .

If we stick to commas then the production = already exists in the spec:

json-text =3D ws-value=

json-texts =3D ws-value (',' ws-value)



--
Website: http://hallambaker.com/
--001a1134635a63b79504f4673af3-- From nobody Wed Mar 12 08:28:59 2014 Return-Path: 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 3E4801A074B for ; Wed, 12 Mar 2014 08:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 JO4hGsw7uX8A for ; Wed, 12 Mar 2014 08:28:54 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EE1E31A044B for ; Wed, 12 Mar 2014 08:28:53 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id bj1so1246462pad.16 for ; Wed, 12 Mar 2014 08:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hw4ZVXrhQzf8NNcczMCs0Ir39t2ZL9N83WPh3tAQSJo=; b=wK+vi4z8r8ZlK6W3tKJnNKs1kBf0Pv0nGzs73PRL851cxpCUUSSEk1Mza7JFILYnIl D+l2TucDkGHbIp4Gx1Aj/+C9A1n13PK/Y2finyPSf8v3HJnL0KEJgnPflSHrf9pVFURW ssuvLtlLE0XWIfWwS3aIdp6hJHico71V9hJkiaLMmxobRNJDQu8bqwLKAfa4cwshfPgu ib+bH58eWAJpX8y1mXcSvFLGYzvD6xGsUurN3MvilAQKAtu+4OVUpW7njPCAykMiW2Si 9N2Y4DF3fMZj/6EGB0Cm/4qHGbTD2gNFWoSaqSKmKFPHyH/Xq5J/GQPoXOiZJ079Dpo7 3+aQ== MIME-Version: 1.0 X-Received: by 10.66.9.41 with SMTP id w9mr5706261paa.39.1394638127932; Wed, 12 Mar 2014 08:28:47 -0700 (PDT) Received: by 10.68.170.97 with HTTP; Wed, 12 Mar 2014 08:28:47 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 12 Mar 2014 09:28:47 -0600 Message-ID: From: Sean Gillies To: "json@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5215f6334a9cd04f46a7ed2 Archived-At: http://mailarchive.ietf.org/arch/msg/json/CORl3-xglrGcL-8DTSFFmwb9MrU Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:28:58 -0000 --bcaec5215f6334a9cd04f46a7ed2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 12, 2014 at 5:26 AM, Phillip Hallam-Baker wrote: > > On Tue, Mar 11, 2014 at 11:49 PM, Tim Bray wrote: > >> Yeah, the options are: >> >> 1. zero or more whitespace characters >> 2. 1 or more whitespace characters >> 3. A specific required set of whitespace characters, for example \s*\n\s* >> or just \n >> > > or > > 4. use the JSON separator character, the comma > I've thought about multi-text documents in the past and RFC 1521 Multipart immediately came to mind. http://tools.ietf.org/html/rfc1521#page-29 Couldn't a pair of hyphens be a fifth option? -- Sean Gillies --bcaec5215f6334a9cd04f46a7ed2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 12, 2014 at 5:26 AM, Phillip Hallam-Baker <hal= lam@gmail.com> wrote:

On Tue, M= ar 11, 2014 at 11:49 PM, Tim Bray <tbray@textuality.com> = wrote:
Yeah, the options are:

1. zero or more whitespace characters
2. 1 or more whitespace characters
3. A specific required set of whitespace charact= ers, for example \s*\n\s* or just \n

or

4. use the JSON separator character,= the comma

I've thought ab= out multi-text documents in the past and RFC 1521 Multipart immediately cam= e to mind.

=A0 http://tools= .ietf.org/html/rfc1521#page-29

Couldn't a pair of= hyphens be a fifth option?

--
Sean Gillies
--bcaec5215f6334a9cd04f46a7ed2-- From nobody Wed Mar 12 08:44:10 2014 Return-Path: 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 663FA1A09C0 for ; Wed, 12 Mar 2014 08:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no 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 EjnVrcb2rNM4 for ; Wed, 12 Mar 2014 08:44:02 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (agjbgdcfdbec.dreamhost.com [69.163.253.142]) by ietfa.amsl.com (Postfix) with ESMTP id 41B581A09B9 for ; Wed, 12 Mar 2014 08:44:02 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 4D3E02005D90A for ; Wed, 12 Mar 2014 08:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JfYjo3Hzi2oPlpM1DQVd VBobr8k=; b=bcKHK/PYrcUo6KlhHWJF99qD/m7jhWV1PcKPujXBDIPhCF9EuoIM pRpieLQV5QZ0fnYl0BkwSjgTN4IQpiUUr/S6KbLt3a01Rq0y9P169pNccDuysCD7 h95pA6yGs29UTZqvtJ0ylcy3njWd4eEIyz8zPmJHFjpGSuEV1gH9h0s= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id F34962005D909 for ; Wed, 12 Mar 2014 08:43:55 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so11447000wgg.1 for ; Wed, 12 Mar 2014 08:43:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UdEakFLOf1uFlq8yaPnv5ZYL7FZQKxyD2fKjvxOJUDw=; b=XrE73w6/bl1yAvKTIjhJ8yCrote5iTSV/nsRK0WS+84byJaCQH35tVDk21spPB/TnM f2HuYrlbLy8FgLLc+wWn0vYoXkRbi1YJI4QczNIeTcz3lapx1YXeY4EMbtz7q97oyMu9 g4cISosnGSY8SLLIxkc32FL+T2EHqMj9TEtz6CmvauzM0TRzZppDT7aq2KsYywyNOXby fT+CiHuVKtABOeptCWyl4WYPE2sx3xCtV8hkTZeLu3pvI2KLzgadeVQOOWyw2F7XCb/9 LtQ76F6XU0vmobRSl9UYmWdiaEoquvpgSalmhaX/RBSebPHVq7vRq3Bjz2weUGEvpp62 RLww== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr8261787wib.5.1394639027499; Wed, 12 Mar 2014 08:43:47 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 12 Mar 2014 08:43:47 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153F8CA38B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115401A0B02@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 12 Mar 2014 10:43:47 -0500 Message-ID: From: Nico Williams To: Sean Gillies Content-Type: multipart/alternative; boundary=00248c0d7938d34c6604f46ab3aa Archived-At: http://mailarchive.ietf.org/arch/msg/json/2SWOJZbDCaoRIlpZlnQ6BfMYjVA Cc: "json@ietf.org" Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:44:06 -0000 --00248c0d7938d34c6604f46ab3aa Content-Type: text/plain; charset=UTF-8 On Wednesday, March 12, 2014, Sean Gillies wrote: > On Wed, Mar 12, 2014 at 5:26 AM, Phillip Hallam-Baker > > wrote: > >> >> On Tue, Mar 11, 2014 at 11:49 PM, Tim Bray >> > wrote: >> >>> Yeah, the options are: >>> >>> 1. zero or more whitespace characters >>> 2. 1 or more whitespace characters >>> 3. A specific required set of whitespace characters, for example >>> \s*\n\s* or just \n >>> >> >> or >> >> 4. use the JSON separator character, the comma >> > > I've thought about multi-text documents in the past and RFC 1521 Multipart > immediately came to mind. > > http://tools.ietf.org/html/rfc1521#page-29 > Anything that isn't ambiguous as to the preceding or following text will do. The string "foobar" will do, for example. Running code is using whitespace though. So at the very least the set of separators must include whitespace. Adding more than whitespace will mean modifying existing sequence parsers. How many separators do we really need, and what is the benefit adding more? Nico -- --00248c0d7938d34c6604f46ab3aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, March 12, 2014, Sean Gillies <sean.gillies@gmail.com> wrote:
On Wed, Mar 12, 2014 at 5:26 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote= :

On Tue, Mar 11, 2014= at 11:49 PM, Tim Bray <tbray@= textuality.com> wrote:
Yeah, the options are:

1. zero or more whitespace characters
2. 1 or more whitespace characters
3. A specific required set of whitespace charact= ers, for example \s*\n\s* or just \n

or

4. use the JSON separator character,= the comma

I've thought ab= out multi-text documents in the past and RFC 1521 Multipart immediately cam= e to mind.

=C2=A0 http://tools.ietf.org/html/rfc1521#page-29

Anything that isn't ambiguous = as to the preceding or following text will do. =C2=A0The string=C2=A0"= foobar"=C2=A0will do, for example. =C2=A0Running code=C2=A0is using wh= itespace though. =C2=A0So at the very least the set of separators must incl= ude whitespace. =C2=A0Adding more than whitespace will mean modifying exist= ing sequence parsers. =C2=A0How many separators do we really need, and what= is the benefit adding more?

Nico
--=C2=A0
--00248c0d7938d34c6604f46ab3aa-- From nobody Thu Mar 13 08:25:39 2014 Return-Path: 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 DBA871A09EC for ; Thu, 13 Mar 2014 08:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 wMF-7eVJ4zgk for ; Thu, 13 Mar 2014 08:25:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 86D3B1A08ED for ; Thu, 13 Mar 2014 08:25:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2DFPPJF082771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Mar 2014 08:25:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140307171244.B1B8D7FC392@rfc-editor.org> Date: Thu, 13 Mar 2014 08:25:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> References: <20140307171244.B1B8D7FC392@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/RT5VcMV5NOK7eIJ5ncYvd69NRvw Cc: Pete Resnick , json@ietf.org, vfaronov@gmail.com, Tim Bray , mamille2@cisco.com, Barry Leiba Subject: Re: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 15:25:37 -0000 On Mar 7, 2014, at 9:12 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC7159, > "The JavaScript Object Notation (JSON) Data Interchange Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 >=20 > -------------------------------------- > Type: Technical > Reported by: Vasiliy Faronov >=20 > Section: 12 >=20 > Original Text > ------------- > Since JSON's syntax is borrowed from JavaScript, it is possible to > use that language's "eval()" function to parse JSON texts. >=20 > Corrected Text > -------------- > Since JSON's syntax is borrowed from JavaScript, it is possible to > use that language's "eval()" function to parse most (but not all) > JSON texts. >=20 > Notes > ----- > This wording may be construed as meaning that every compliant JSON = text is parseable as JavaScript, which is not the case: = . (Actually I = would prefer this to be stated clearly elsewhere in the document, e.g. = where it says =93JSON's design goals were for it to be [...] a subset of = JavaScript=94.) >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis) > -------------------------------------- > Title : The JavaScript Object Notation (JSON) Data = Interchange Format > Publication Date : March 2014 > Author(s) : T. Bray, Ed. > Category : PROPOSED STANDARD > Source : JavaScript Object Notation > Area : Applications > Stream : IETF > Verifying Party : IESG The WG chairs request that you approve this errata. --Matt Miller and Paul Hoffman= From nobody Thu Mar 13 14:23:59 2014 Return-Path: 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 2673D1A07C8 for ; Thu, 13 Mar 2014 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 h7ZFEEyQogMc for ; Thu, 13 Mar 2014 14:23:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6361A0778 for ; Thu, 13 Mar 2014 14:23:54 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 21:23:46 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Thu, 13 Mar 2014 21:23:46 +0000 From: Larry Masinter To: Paul Hoffman , "json@ietf.org" Thread-Topic: [Json] serializing sequences of JSON values Thread-Index: Ac87TsixeUQAkrJATR2RmgrqNDBDCAAmU0IAACkfhYAAASkhgAABq9AAAAGHwYAALdgHoA== Date: Thu, 13 Mar 2014 21:23:46 +0000 Message-ID: <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> In-Reply-To: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.210] x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(51704005)(94316002)(31966008)(74662001)(97186001)(79102001)(2656002)(94946001)(97336001)(95666003)(92566001)(74502001)(85306002)(63696002)(87936001)(95416001)(74876001)(87266001)(90146001)(74316001)(56816005)(47976001)(81542001)(47446002)(83072002)(46102001)(85852003)(66066001)(59766001)(93136001)(65816001)(93516002)(77982001)(80022001)(76482001)(86362001)(51856001)(81686001)(53806001)(69226001)(54356001)(83322001)(76786001)(76576001)(81816001)(4396001)(47736001)(74706001)(74366001)(80976001)(33646001)(76796001)(50986001)(81342001)(56776001)(49866001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:192.150.10.210; FPR:ACEEF8B6.9F26CF1D.8EF8B167.46EBAC68.20188; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/DNEB0qe9g7PWtqcVNFybW-k1hCM Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:23:57 -0000 I wonder if there is any lesson from XMPP-- which wanted sequence-of-XML-v= alues in an indefinite length stream -- that would apply to JSON. What would XMPP look like if it were redone in JSON instead of XML? If there a tendency to standardize on JSON as a replacement to XML in proto= cols, then would providing guidelines for how to do so be in scope? >=20 > > Why would sequences of objects not be preferred for logging. >=20 > Because the log is always open for appending, so the sequence never > terminates. >=20 > This, and many other related topics, were discussed at length earlier on = the > mailing list and the rough consensus was that the current wording was > sufficient. >=20 From nobody Thu Mar 13 14:31:40 2014 Return-Path: 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 8541B1A075E for ; Thu, 13 Mar 2014 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 tdosTabvs2FH for ; Thu, 13 Mar 2014 14:31:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1681A1A0A42 for ; Thu, 13 Mar 2014 14:31:35 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 21:31:27 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Thu, 13 Mar 2014 21:31:27 +0000 From: Larry Masinter To: Paul Hoffman Thread-Topic: [Json] [Technical Errata Reported] RFC7159 (3915) Thread-Index: AQHPOiiItNTjmrVgS0ysHhAyYbRW/JrfLJaAgABk1aA= Date: Thu, 13 Mar 2014 21:31:27 +0000 Message-ID: References: <20140307171244.B1B8D7FC392@rfc-editor.org> <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> In-Reply-To: <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.210] x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(87266001)(93516002)(59766001)(77982001)(15975445006)(86362001)(74316001)(69226001)(94946001)(54356001)(81542001)(56776001)(15395725003)(47976001)(51856001)(50986001)(4396001)(92566001)(49866001)(76482001)(53806001)(47736001)(46102001)(94316002)(81342001)(76786001)(79102001)(87936001)(83322001)(19580395003)(93136001)(76576001)(97336001)(76796001)(80022001)(65816001)(56816005)(81686001)(85852003)(63696002)(80976001)(15202345003)(2656002)(33646001)(85306002)(95416001)(81816001)(97186001)(66066001)(74662001)(83072002)(74366001)(74502001)(74706001)(90146001)(74876001)(47446002)(31966008)(95666003)(24736002)(15302535010); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:192.150.10.210; FPR:AC3DC975.2DD6430A.70D0A396.8466306A.200E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/YHicg3kE_LK0qKRONooWfspUCkk Cc: Pete Resnick , "json@ietf.org" , "vfaronov@gmail.com" , Tim Bray , "mamille2@cisco.com" , Barry Leiba Subject: Re: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:31:38 -0000 > The WG chairs request that you approve this errata. I think the errata would be more useful if it actually explained the \u2028= , \u2029 exception, rather than leaving it in a potentially unstable refere= nce http://timelessrepo.com/json-isnt-a-javascript-subset Should \u2028 \u2029 characters be disallowed from an "i-json" profile? Sin= ce the purpose is a "safe subset"? From nobody Thu Mar 13 14:33:53 2014 Return-Path: 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 1402A1A076C for ; Thu, 13 Mar 2014 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 n_kr2J_yFCZw for ; Thu, 13 Mar 2014 14:33:49 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 802721A075E for ; Thu, 13 Mar 2014 14:33:49 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so1794541vcb.21 for ; Thu, 13 Mar 2014 14:33:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WTAKyP+sKQ2I7Jb5Lts2qwYnQu9KWWoQ18p3Ix8MGxc=; b=CtH/yLNRk5pLY2pN4IwRsWadG/HofZqyVZLbJiwkx02B3Yq6wQZ7F7+1EpOwdnUH2Z lNuXdnsflAZfum8fqo33IOkewW604FP3t9Aq87gSniKj3DHJvfik1JhQ7IbzBUYHir45 pN2CNpLRR3l4ONoFwiFS4xh/WGeAvRCNbFlPPZu3zDSSlLAGmlNejOWAQIKaCznlEj5F IazYkL4m3l1RGRAghio70jGWTWORmJAkpVV1RclXH/2M3MLFBbDaH0q53JztpPvPT2xG YR4hyh8gCNk9mfDRqc2UK9wlGBrsXU7K+c2avnZs3reeD19PHc6PXpbAEBTtI8p/ycdS p4tg== X-Gm-Message-State: ALoCoQk/3GLPDSKnazUnJMWbbgWHp6v0qmxjoB7K1kVESu5cxUmguVWDPzq3gMKZk+YSfNi1Gjgp MIME-Version: 1.0 X-Received: by 10.52.34.137 with SMTP id z9mr2708810vdi.12.1394746422699; Thu, 13 Mar 2014 14:33:42 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Thu, 13 Mar 2014 14:33:42 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20140307171244.B1B8D7FC392@rfc-editor.org> <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> Date: Thu, 13 Mar 2014 14:33:42 -0700 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=20cf30780f6213c35504f483b528 Archived-At: http://mailarchive.ietf.org/arch/msg/json/cPc0qSErU11gbnamvFSUSEcVnYQ Cc: Pete Resnick , Paul Hoffman , "json@ietf.org" , "vfaronov@gmail.com" , "mamille2@cisco.com" , Barry Leiba Subject: Re: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:33:51 -0000 --20cf30780f6213c35504f483b528 Content-Type: text/plain; charset=UTF-8 That idea is at least plausible. And I bet a walk through the unicode separator and white-space definitions might turn up a few more candidates. On Thu, Mar 13, 2014 at 2:31 PM, Larry Masinter wrote: > > The WG chairs request that you approve this errata. > > > I think the errata would be more useful if it actually explained the > \u2028, \u2029 exception, rather than leaving it in a potentially unstable > reference > http://timelessrepo.com/json-isnt-a-javascript-subset > > Should \u2028 \u2029 characters be disallowed from an "i-json" profile? > Since the purpose is a "safe subset"? > > > --20cf30780f6213c35504f483b528 Content-Type: text/html; charset=UTF-8
That idea is at least plausible. And I bet a walk through the unicode separator and white-space definitions might turn up a few more candidates.


On Thu, Mar 13, 2014 at 2:31 PM, Larry Masinter <masinter@adobe.com> wrote:
> The WG chairs request that you approve this errata.


I think the errata would be more useful if it actually explained the \u2028, \u2029 exception, rather than leaving it in a potentially unstable reference
http://timelessrepo.com/json-isnt-a-javascript-subset

Should \u2028 \u2029 characters be disallowed from an "i-json" profile? Since the purpose is a "safe subset"?



--20cf30780f6213c35504f483b528-- From nobody Thu Mar 13 14:39:55 2014 Return-Path: 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 742EC1A075E for ; Thu, 13 Mar 2014 14:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 LLuxny-bEFia for ; Thu, 13 Mar 2014 14:39:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 733A61A0754 for ; Thu, 13 Mar 2014 14:39:51 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 21:39:43 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Thu, 13 Mar 2014 21:39:43 +0000 From: Larry Masinter To: Nico Williams , Matthew Morley Thread-Topic: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) Thread-Index: AQHPPK1+m0ZN/rvGs0aL4VgGaA1MH5ra4iQAgAEiVACAABS3AIADdeeg Date: Thu, 13 Mar 2014 21:39:43 +0000 Message-ID: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.210] x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(199002)(189002)(81686001)(53806001)(76482001)(69226001)(83322001)(86362001)(54356001)(51856001)(46102001)(65816001)(93516002)(83072002)(66066001)(74706001)(59766001)(80022001)(77982001)(93136001)(85852003)(50986001)(76796001)(76786001)(76576001)(80976001)(33646001)(56776001)(49866001)(4396001)(81342001)(81816001)(74366001)(47736001)(2656002)(92566001)(95666003)(87266001)(74662001)(31966008)(97186001)(94316002)(97336001)(74502001)(47976001)(79102001)(74876001)(74316001)(56816005)(95416001)(94946001)(81542001)(47446002)(90146001)(87936001)(85306002)(63696002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:192.150.10.210; FPR:D326E60C.94121E61.C0EB304B.88E52ED8.20146; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/ObiDTwFvVoFhwoSEhXV_BwAVU0c Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:39:53 -0000 > Arguably JSON text sequences are a new format, yes > deserving of its own MIME type and so on. no, not all formats need MIME types. There are infinitely many formats.=20 MIME is one way of noting a file format and distinguishing it from others, = but most applications don't NEED to name the types they accept and in gener= al, they can't. I think to justify a new MIME type, you need to provide a concrete use case= that would actually use it and need it. In most of the content-negotiatio= n scenarios, MIME types are far too course-grained to express content-featu= res.=20 From nobody Thu Mar 13 14:43:35 2014 Return-Path: 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 CD5D01A0A4A for ; Thu, 13 Mar 2014 14:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 U_DvwvOmcpZx for ; Thu, 13 Mar 2014 14:43:32 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0631A0778 for ; Thu, 13 Mar 2014 14:43:32 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so1768435veb.21 for ; Thu, 13 Mar 2014 14:43:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JWcBET01PMCGVoTllNhr4E8S4JGAJmsr1G+tXICMM00=; b=BLDRBbrVbY4HpQveu7Ube9mllBY61J4B2WjbBmUPLU2xODpI0QQDPdU5deoOdNR4M2 9PymZ/7DRy2R/x/e+GCFGag27bLCF7oDSKD/mxABGOYaTTyOKn15gNM11WYKqQD5D2Q+ MJIu2ToSTO96AJdPVX5u3UBXLTq6Sjjn6+RN0eegTO425uIwk2LZXP1JoY2O6sGjQieb 0ls+c2UwJMDpQNK/+DNh1Sn6cI+Rn2u0UnCKOgF1TZdp5nAeArmkEGBqWEAmcVFwcniw lPu7KNo4hucwQ6JTgHHz2D5xEbRQ3e3pDf+F498/Shte8auQcf70zsW2l55ZjqS3TjD0 QSYw== X-Gm-Message-State: ALoCoQkxAA23HhR3oVyxNUSwHwPQjPKPbwk3yNpRDeTgIXa/kuScCjpt3UzpRiebY3Pc7KNCmVXG MIME-Version: 1.0 X-Received: by 10.58.188.78 with SMTP id fy14mr3306145vec.23.1394747005488; Thu, 13 Mar 2014 14:43:25 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Thu, 13 Mar 2014 14:43:25 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 13 Mar 2014 14:43:25 -0700 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=089e013a12f0d0647104f483d77c Archived-At: http://mailarchive.ietf.org/arch/msg/json/wvlkPm_GA1WAs19sNSO3_-Ytj6s Cc: Nico Williams , "json@ietf.org" , Matthew Morley , Paul Hoffman Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:43:34 -0000 --089e013a12f0d0647104f483d77c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m halfway convinced that it might be useful to say that if you ar= e persisting something as chunks of JSON, use X as a separator. I wouldn=E2= =80=99t be surprised to see the advent of standardized log-as-JSON libraries. I=E2= =80=99d go further and say that if you are doing this, use objects too. Having said that, it=E2=80=99s not obvious that this is the kind of format that yo= u=E2=80=99d interchange much, so the case for a media type is weak. On Thu, Mar 13, 2014 at 2:39 PM, Larry Masinter wrote: > > Arguably JSON text sequences are a new format, > > yes > > > deserving of its own MIME type and so on. > > no, not all formats need MIME types. There are infinitely many formats. > MIME is one way of noting a file format and distinguishing it from others= , > but most applications don't NEED to name the types they accept and in > general, they can't. > > I think to justify a new MIME type, you need to provide a concrete use > case that would actually use it and need it. In most of the > content-negotiation scenarios, MIME types are far too course-grained to > express content-features. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013a12f0d0647104f483d77c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= =E2=80=99m halfway convinced that it might be useful to say that if you are= persisting something as chunks of JSON, use X as a separator. =C2=A0I woul= dn=E2=80=99t be surprised to see the advent of standardized log-as-JSON lib= raries. I=E2=80=99d go further and say that if you are doing this, use obje= cts too. =C2=A0Having said that, it=E2=80=99s not obvious that this is the = kind of format that you=E2=80=99d interchange much, so the case for a media= type is weak.


On Thu,= Mar 13, 2014 at 2:39 PM, Larry Masinter <masinter@adobe.com> wrote:
> Arguably JSON text sequ= ences are a new format,

yes

> deserving of its own MIME type and so on.

no, not all formats need MIME types. There are infinitely many format= s.
MIME is one way of noting a file format and distinguishing it from others, = but most applications don't NEED to name the types they accept and in g= eneral, they can't.

I think to justify a new MIME type, you need to provide a concrete use case= that would actually use it and need it. =C2=A0In most of the content-negot= iation scenarios, MIME types are far too course-grained to express content-= features.

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e013a12f0d0647104f483d77c-- From nobody Thu Mar 13 14:44:55 2014 Return-Path: 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 2AAC61A0A47 for ; Thu, 13 Mar 2014 14:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 Wn8CurqDgSah for ; Thu, 13 Mar 2014 14:44:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id E5A171A0778 for ; Thu, 13 Mar 2014 14:44:48 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 13 Mar 2014 21:44:39 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Thu, 13 Mar 2014 21:44:39 +0000 From: Larry Masinter To: Matthew Morley , Nico Williams Thread-Topic: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) Thread-Index: AQHPPK1+m0ZN/rvGs0aL4VgGaA1MH5ra4iQAgAEiVACAABS3AIAAAQkAgAAFrgCAABB4gIAABUUAgANa6GA= Date: Thu, 13 Mar 2014 21:44:38 +0000 Message-ID: <664149bc6d3941afad86684fac806a17@BL2PR02MB307.namprd02.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.210] x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(199002)(189002)(377454003)(24454002)(51704005)(74876001)(74502001)(46102001)(47446002)(4396001)(87266001)(74316001)(65816001)(54356001)(85306002)(56776001)(53806001)(80022001)(51856001)(69226001)(66066001)(74706001)(19300405004)(74366001)(76796001)(76786001)(47736001)(2656002)(50986001)(80976001)(85852003)(19580405001)(83072002)(19580395003)(76576001)(97336001)(79102001)(94946001)(59766001)(77982001)(97186001)(83322001)(92566001)(93136001)(33646001)(81342001)(56816005)(63696002)(95416001)(90146001)(15202345003)(31966008)(15975445006)(16236675002)(76482001)(49866001)(47976001)(86362001)(81686001)(95666003)(93516002)(81542001)(81816001)(74662001)(87936001)(94316002)(24736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:192.150.10.210; FPR:C867F454.A6E1F409.71DF7177.40A5F1F1.20431; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_664149bc6d3941afad86684fac806a17BL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/VxLYWXgm1H_jbjXUy-oU6MM5Cxk Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:44:54 -0000 --_000_664149bc6d3941afad86684fac806a17BL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think most of i-json and also this discussion on JSON sequences would fit= into a "guidelines" document. "Guidelines for use of JSON in Internet prot= ocols". Then it could be BCP, could cover \u2028 \u2029, string length limits, floa= ting point, separators in sequences, and other advice. much more straightforward. It could even cover "JSON vs alternatives" and p= ros and cons comparison to XML, CBOR, ASN.1 and whatever. From: json [mailto:json-bounces@ietf.org] On Behalf Of Matthew Morley Sent: Tuesday, March 11, 2014 11:27 AM To: Nico Williams Cc: Tim Bray; Phillip Hallam-Baker; Paul Hoffman; json@ietf.org Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializi= ng sequences of JSON values) I'm not advocating for comma separators... But having multiple top level JSON elements separated by a coma is equivale= nt to processing an array structure. The initial [ and the closing ] are im= plicitly mapped to the connection/stream/etc. start and end events. It is just a minor token replacement at the top level between elements, whi= ch could be layered into some existing tooling. From this point of view, I = would imagine the retooling is minor for either use case. It does mean tool= s need to be depth aware. On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams > wrote: On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker > wrote: > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray > wrote: >> >> Heh, I wonder if there'd be any chance of getting consensus. I can't >> imagine ever using anything but Object Object Object with optional >> whitespace separator; unless we all agree on that going in I'd pessimist= ic >> about anyone convincing anyone else... > > But JSON has comma separators, so {..}, {..}, {..} makes far more sense. JSON text sequences would be a new Proposed Standard (if we go there) but like JSON, there exist uses of this "new" thing already -- that is, before we get to writing the RFC. The uses of JSON text sequences that I know of use newlines, not commas nor comma-and-newline. The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing JSON texts -- usually compact texts, i.e., with no newlines in the text, and never more than one text per-line. For me other uses of JSON text sequences generally result from my use of jq, which also effectively separates texts with a newline. Note that jq doesn't need texts to be written compactly when parsing JSON text sequences. It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with all existing JSON parsers. Switching to using a comma-and-newline would require significant retooling. Therefore I don't see it happening. Whereas just separating JSON texts with newlines is in use because it's always been the obvious thing to do. Nico -- -- Matthew P. C. Morley --_000_664149bc6d3941afad86684fac806a17BL2PR02MB307namprd02pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I think most of i-json and also this discussion on JSON seque= nces would fit into a “guidelines” document. “Guidelines = for use of JSON in Internet protocols”.

= Then it could be BCP, could cover \u2028 \u2029, string length limits, floating point, separators in sequences, and other advice.

=  

= much more straightforward. It could even cover “JSON vs alternatives= ” and pros and cons comparison to XML, CBOR, ASN.1 and whatever.

=  

=  

=  

=  

=  

From: json [mailto:json-bounces@ietf.org] On= Behalf Of Matthew Morley
Sent: Tuesday, March 11, 201= 4 11:27 AM
To: Nico Williams
Cc: Tim Bray; Phillip Hallam= -Baker; Paul Hoffman; json@ietf.org
Subject: Re: [Json] Regardin= g JSON text sequence ambiguities (Re: serializing sequences of JSON values)=

 

I'm not advocating for comma separators...

But having multiple top level JSON elements separated by a coma is equivale= nt to processing an array structure. The initial [ and the closing ] are im= plicitly mapped to the connection/stream/etc. start and end events.

It is just a minor token replacement at the top level between elements, whi= ch could be layered into some existing tooling. From this point of view, I = would imagine the retooling is minor for either use case. It does mean tool= s need to be depth aware.

 

On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:

On Tue, Mar 11, 2014 = at 12:09 PM, Phillip Hallam-Baker <h= allam@gmail.com> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> Heh, I wonder if there’d be any chance of getting consensus.=  I can’t
>> imagine ever using anything but Object Object Object with optional=
>> whitespace separator; unless we all agree on that going in I’= ;d pessimistic
>> about anyone convincing anyone else...
>
> But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e.

JSON text sequences would be a new Proposed Standard= (if we go there)
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline.  The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline.  Note that jq doesn't need texts to be written compactly when parsing JSON
text sequences.  It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling.  Therefore I don't see it happening.  Whereas just
separating JSON texts with newlines is in use because it's always been
the obvious thing to do.

Nico
--



 

--
Matthew P. C. Morley

--_000_664149bc6d3941afad86684fac806a17BL2PR02MB307namprd02pro_-- From nobody Thu Mar 13 14:52:19 2014 Return-Path: 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 046C11A0766 for ; Thu, 13 Mar 2014 14:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no 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 qnmeAjD7TxLD for ; Thu, 13 Mar 2014 14:52:16 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E31A0664 for ; Thu, 13 Mar 2014 14:52:16 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so1848610veb.0 for ; Thu, 13 Mar 2014 14:52:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VQKjGBnuWsUyLyzBUpzFnsTiP943vbPmSOG3jCg7R4U=; b=kvpFg0XdoZ8uePpCY1gNRpC9JebnJ8AsFQUQYDzSFargf8POyH0Itj3nhWfs2ARmdc IVMStv5Vso+bw+VU55cbJ3lyR4zQ3jwYpfXEo9VEpQ58Jq7SnOAFOoLWQeqPKadfkIyH qbQp3ALp7WJcsNiqW82ZXF5qsEkjkE38IiepBAdkwoyaM9dQJFZJvilc5EZjN56GS7GL bRBLA40ei3bzPKHMWAlsbl9e2ogGP+RjKnlhJij+gkPe+/exv6Onat0S/f7FoOCW/gEq oEuRuXxixZtkN8g2P62ioXqnPAfqTu1yecjqGzy9ICoZXeCHc95sb90MnWPhPtMbZytg i57A== X-Gm-Message-State: ALoCoQnPeWNp3Mk2LV1xl5Hkct0rxtYsIXjySBeVXJTMhhhiiD2ICm97ZB1Ci4nbBOvHoiql2jg5 MIME-Version: 1.0 X-Received: by 10.52.139.237 with SMTP id rb13mr2730537vdb.33.1394747529375; Thu, 13 Mar 2014 14:52:09 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Thu, 13 Mar 2014 14:52:09 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <664149bc6d3941afad86684fac806a17@BL2PR02MB307.namprd02.prod.outlook.com> References: <664149bc6d3941afad86684fac806a17@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 13 Mar 2014 14:52:09 -0700 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=bcaec52c5ccd0a4c6304f483f73d Archived-At: http://mailarchive.ietf.org/arch/msg/json/s2KsL2C0qsGwzjc85vpaNtlrGjo Cc: Nico Williams , "json@ietf.org" , Phillip Hallam-Baker , Matthew Morley , Paul Hoffman Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:52:18 -0000 --bcaec52c5ccd0a4c6304f483f73d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Except for, a spec that just rules out the interoperability gotchas in 7159 is such a low-hanging fruit, and avoids so many slippery slopes. Damn, I wish that stupid 2028/2029 thing had come across the radar before we finished 7159. On Thu, Mar 13, 2014 at 2:44 PM, Larry Masinter wrote: > I think most of i-json and also this discussion on JSON sequences would > fit into a =E2=80=9Cguidelines=E2=80=9D document. =E2=80=9CGuidelines for= use of JSON in Internet > protocols=E2=80=9D. > > Then it could be BCP, could cover \u2028 \u2029, string length limits, > floating point, separators in sequences, and other advice. > > > > much more straightforward. It could even cover =E2=80=9CJSON vs alternati= ves=E2=80=9D and > pros and cons comparison to XML, CBOR, ASN.1 and whatever. > > > > > > > > > > > > *From:* json [mailto:json-bounces@ietf.org] *On Behalf Of *Matthew Morley > *Sent:* Tuesday, March 11, 2014 11:27 AM > *To:* Nico Williams > *Cc:* Tim Bray; Phillip Hallam-Baker; Paul Hoffman; json@ietf.org > *Subject:* Re: [Json] Regarding JSON text sequence ambiguities (Re: > serializing sequences of JSON values) > > > > I'm not advocating for comma separators... > > But having multiple top level JSON elements separated by a coma is > equivalent to processing an array structure. The initial [ and the closin= g > ] are implicitly mapped to the connection/stream/etc. start and end event= s. > > It is just a minor token replacement at the top level between elements, > which could be layered into some existing tooling. From this point of vie= w, > I would imagine the retooling is minor for either use case. It does mean > tools need to be depth aware. > > > > On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams > wrote: > > On Tue, Mar 11, 2014 at 12:09 PM, Phillip Hallam-Baker > wrote: > > On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray wrote= : > >> > >> Heh, I wonder if there=E2=80=99d be any chance of getting consensus. = I can=E2=80=99t > >> imagine ever using anything but Object Object Object with optional > >> whitespace separator; unless we all agree on that going in I=E2=80=99d > pessimistic > >> about anyone convincing anyone else... > > > > But JSON has comma separators, so {..}, {..}, {..} makes far more sense= . > > JSON text sequences would be a new Proposed Standard (if we go there) > but like JSON, there exist uses of this "new" thing already -- that > is, before we get to writing the RFC. > > The uses of JSON text sequences that I know of use newlines, not > commas nor comma-and-newline. The reason for this is that these use > cases are text logfile-like: the entries are lines, lines containing > JSON texts -- usually compact texts, i.e., with no newlines in the > text, and never more than one text per-line. > > For me other uses of JSON text sequences generally result from my use > of jq, which also effectively separates texts with a newline. Note > that jq doesn't need texts to be written compactly when parsing JSON > text sequences. It happens though that if you write texts compactly > followed by a newline then you can implement JSON text sequences with > all existing JSON parsers. > > Switching to using a comma-and-newline would require significant > retooling. Therefore I don't see it happening. Whereas just > separating JSON texts with newlines is in use because it's always been > the obvious thing to do. > > Nico > -- > > > > > > -- > Matthew P. C. Morley > --bcaec52c5ccd0a4c6304f483f73d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exc= ept for, a spec that just rules out the interoperability gotchas in 7159 is= such a low-hanging fruit, and avoids so many slippery slopes. =C2=A0Damn, = I wish that stupid 2028/2029 thing had come across the radar before we fini= shed 7159.


On Thu,= Mar 13, 2014 at 2:44 PM, Larry Masinter <masinter@adobe.com> wrote:

I think most of i-json and also this discussion on JSON sequences would fit in= to a =E2=80=9Cguidelines=E2=80=9D document. =E2=80=9CGuidelines for use of = JSON in Internet protocols=E2=80=9D.

Then it could be BCP, could cover \u2028 \u2029, string len= gth limits, floating point, separators in sequences, and other advice.

=C2=A0

much more straightforward. It could even cover =E2=80=9CJSO= N vs alternatives=E2=80=9D and pros and cons comparison to XML, CBOR, ASN.1 and whatever.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: json [mailto:js= on-bounces@ietf.org] On Behalf Of Matthew Morley
Sent: Tuesday, March 11, 201= 4 11:27 AM
To: Nico Williams
Cc: Tim Bray; Phillip Hallam= -Baker; Paul Hoffman; js= on@ietf.org
Subject: Re: [Json] Regardin= g JSON text sequence ambiguities (Re: serializing sequences of JSON values)=

=C2=A0

I'm not advocating for comma separators...

But having multiple top level JSON elements separated by a coma is equivale= nt to processing an array structure. The initial [ and the closing ] are im= plicitly mapped to the connection/stream/etc. start and end events.

It is just a minor token replacement at the top level between elements, whi= ch could be layered into some existing tooling. From this point of view, I = would imagine the retooling is minor for either use case. It does mean tool= s need to be depth aware.

=C2=A0<= /span>

On Tue, Mar 11, 2014 at 2:08 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:

On Tue, Mar 11, 2014 = at 12:09 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Tue, Mar 11, 2014 at 12:48 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>> Heh, I wonder if there=E2=80=99d be any chance of getting consensu= s. =C2=A0I can=E2=80=99t
>> imagine ever using anything but Object Object Object with optional=
>> whitespace separator; unless we all agree on that going in I=E2=80= =99d pessimistic
>> about anyone convincing anyone else...
>
> But JSON has comma separators, so {..}, {..}, {..} makes far more sens= e.

JSON text sequences would be a new Proposed Standard= (if we go there)
but like JSON, there exist uses of this "new" thing already -- th= at
is, before we get to writing the RFC.

The uses of JSON text sequences that I know of use newlines, not
commas nor comma-and-newline. =C2=A0The reason for this is that these use cases are text logfile-like: the entries are lines, lines containing
JSON texts -- usually compact texts, i.e., with no newlines in the
text, and never more than one text per-line.

For me other uses of JSON text sequences generally result from my use
of jq, which also effectively separates texts with a newline. =C2=A0Note that jq doesn't need texts to be written compactly when parsing JSON text sequences. =C2=A0It happens though that if you write texts compactly followed by a newline then you can implement JSON text sequences with
all existing JSON parsers.

Switching to using a comma-and-newline would require significant
retooling. =C2=A0Therefore I don't see it happening. =C2=A0Whereas just=
separating JSON texts with newlines is in use because it's always been<= br> the obvious thing to do.

Nico
--



=C2=A0

--
Matthew P. C. Morley


--bcaec52c5ccd0a4c6304f483f73d-- From nobody Thu Mar 13 15:24:09 2014 Return-Path: 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 88DC71A0768 for ; Thu, 13 Mar 2014 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JIUJNUiBghg9 for ; Thu, 13 Mar 2014 15:24:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF11A0747 for ; Thu, 13 Mar 2014 15:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2781; q=dns/txt; s=iport; t=1394749439; x=1395959039; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=tWwtpxM0GN7w2JJDfF7H516GRtdyb92wsvejZf8sdYw=; b=MZdIB7ryWDR4sraQiCmTW+87nFHj+4hiUjs84Hx7BlnX4ZGmIEfqhFd8 taOWrmhPOD+qiyJyo8cpq2LKNbJyS+2taldKoNo10M64xrz840af1KJhf gJdqM7ym5Js06VFTCfISde8goUEnMwjX8M9/ZmHWp6jEEvgIYuMsglYwR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoKAOEuIlOtJXG9/2dsb2JhbABZgwY7V6hyBAeYaQqBHhZ0giUBAQEDAXgGCwsYCRYPCQMCAQIBRQYBDAYCAQEQh10IDdQRF4xvgTs6hDgBA4kZOI50gTKQe4NMggw X-IronPort-AV: E=Sophos;i="4.97,649,1389744000"; d="scan'208";a="307154133" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 13 Mar 2014 22:23:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2DMNwii012699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 22:23:58 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.33) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Mar 2014 17:23:58 -0500 Message-ID: <53222FFC.8070204@cisco.com> Date: Thu, 13 Mar 2014 16:23:56 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Larry Masinter , Paul Hoffman , "json@ietf.org" References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.33] Archived-At: http://mailarchive.ietf.org/arch/msg/json/CeWq0Bw1WnmElN102JMuqR6Ov48 Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:24:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/13/14, 3:23 PM, Larry Masinter wrote: > I wonder if there is any lesson from XMPP-- which wanted > sequence-of-XML-values in an indefinite length stream -- that would > apply to JSON. What would XMPP look like if it were redone in JSON > instead of XML? > /me exchanges JSON chair hat for XMPP enthusiast hat ... If XMPP didn't exist and we instead did JMPP, it might be a series of discrete objects. However, the direction of the later "XMPP over " adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use an existing transport that provides block-oriented framing around complete structures. Dealing with partial XML-like structures in XMPP has ranged from inconvenient to impractical because the vast majority of existing XML software has assumed a whole XML document when parsing starts. There are few libraries that truly allow one to feed XML in fits and starts and get timely output without some amount of modification or preprocessing. When the XMPP community took efforts to apply XMPP over other transports, the direction has so far leaned toward the whole documents that most implementations expect; even though the preprocessing required is rather small, the ability to re-use existing implementations without first considering oft-unpublished details was a very powerful motivator. > If there a tendency to standardize on JSON as a replacement to XML > in protocols, then would providing guidelines for how to do so be > in scope? > > >> /me continues with no hat whatsoever I think there is value in a guidelines document similar to BCP 79 -- particularly a "don't use JSON for " part. I'm somewhat unconcerned on how that is done -- whether that means I-JSON morphs into that or it is its own separate thing. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [BOSH] "XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)" < http://xmpp.org/extensions/xep-0124.html > [XMPP-WS] "An XMPP Sub-protocol for WebSocket" < https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIi/8AAoJEDWi+S0W7cO1VHYIAITNDfwKhROU4cafb1y/2FqG ZBCopL+hhZQ6PtFExRrnMji7bkwjhLRoDBwC1Md+JLq4mRlPMUFtyNO3Ew6x8ZvH YjiZXQ753+jea9VHnNS1kz3+MXNhz2U2kpVUOn1Cn97BYW3GEdixks7YM7nxc2kA GKGKomxQwMF67ghfFZLXl+n2ga7aDPqTvdD4gQc/pmVUnzOInu33dr/xfQL5V5ai B/QYPIyI7UO8wRbuy0uDChW16/+ZE96RD69Zf1/NOEw4V+ZfsZciWVm3bJk1Gl3t ZuHE0u+HLfbfbJT/IB359RuUnRs3342kePuvYd0nMCnmJ8+V0Z/eDNzY9+nZ4iI= =Fv5M -----END PGP SIGNATURE----- From nobody Thu Mar 13 15:58:31 2014 Return-Path: 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 AF0621A0747 for ; Thu, 13 Mar 2014 15:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, IP_NOT_FRIENDLY=0.334] autolearn=no 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 QfpA1Ogcgicr for ; Thu, 13 Mar 2014 15:58:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (agjbgdcfdbfj.dreamhost.com [69.163.253.159]) by ietfa.amsl.com (Postfix) with ESMTP id A33B61A06EE for ; Thu, 13 Mar 2014 15:58:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 2C58C674058 for ; Thu, 13 Mar 2014 15:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=b2Fuz2AvONG+Tb2aaN0P arXp4GA=; b=WLBjxu9E9zBopC4FG1IlnIUqQbHFdQ+u2Y3Q2EjF+HOuRNOp3mXm 8VWnYOj98OC8FZ444+MDCRobDiMAP7DSxouipzPsVtClRUVuzrZq+zI5b37XhO9/ q9sSwGiXjyfusDptufVmWophk6WRI6TV9/xSGQ/Nj+opxElvdyxvusA= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id D4962674059 for ; Thu, 13 Mar 2014 15:58:21 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so1430349wes.25 for ; Thu, 13 Mar 2014 15:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tqPnT8Hzm9vX89XB02m23IM5Jo2vQN6od+QoyTSzMxI=; b=Ec30bGLI+Jhro864aQYnrRWeVsKAMDrAuicT9M7o2Z33P4elfBt9yVWjZNLUI+ODVU wdr9xCkZk4Ll+jCi17uBwiLDdLJDDN+SE/N9pZvmMmaz9gBl3wnzdfexseT88is64a7S xClxgCbTTT+OU2ivLeyAwcjJj7NHQforvpRdTVoO2h69NPqqw24ewic0aAn1v9nEDI8h hC7BorETK4zpOUozS0ml3Vjh3HjMPMejwny0988tARLvKL1Qs06v1mIdkjaZmLgl4hTU RH31Rg8JIqIIAY7xfkwJ/IpGHFGX7TN+6n5CnYQVu3u0TVNB69OgFaigspKViu+RLW6v MaWA== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr3532850wiw.39.1394751500523; Thu, 13 Mar 2014 15:58:20 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 15:58:20 -0700 (PDT) In-Reply-To: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 13 Mar 2014 17:58:20 -0500 Message-ID: From: Nico Williams To: Larry Masinter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tPp0ConY0Bae3HQgFqSrjwiEeIg Cc: "json@ietf.org" , Matthew Morley , Paul Hoffman Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:58:29 -0000 On Thu, Mar 13, 2014 at 4:39 PM, Larry Masinter wrote: >> Arguably JSON text sequences are a new format, > > yes It seems we're getting consensus on that much. >> deserving of its own MIME type and so on. > > no, not all formats need MIME types. There are infinitely many formats. > MIME is one way of noting a file format and distinguishing it from others, but most applications don't NEED to name the types they accept and in general, they can't. The same argument leads to not needing application/json either. And yet there it is. For HTTP applications an application/json-text-sequence type might mean that a server could generate N objects one at a time instead of generating them all into a top-level array then sending that once built. Sure, it's not hard to build a top-level array in an online manner, but if you've ever run into an application that doesn't, you know that there is value in this. > I think to justify a new MIME type, you need to provide a concrete use case that would actually use it and need it. In most of the content-negotiation scenarios, MIME types are far too course-grained to express content-features. A proprietary app I work could use this. It's a database, queries return results, as expected, specifically as a top-level array or results -- each result being roughly like a SQL row. Actually, it's an app built out of Rails and Postgresql, of which there are many out there. Who knows, it might be trivial to deploy this new format type. Nico -- From nobody Thu Mar 13 16:14:32 2014 Return-Path: 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 96FBA1A0764 for ; Thu, 13 Mar 2014 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 94gj7JblLIRA for ; Thu, 13 Mar 2014 16:14:11 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (agjbgdcfdbge.dreamhost.com [69.163.253.164]) by ietfa.amsl.com (Postfix) with ESMTP id EC18C1A06EE for ; Thu, 13 Mar 2014 16:14:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7825210070 for ; Thu, 13 Mar 2014 16:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; s=cryptonector.com; bh=nkckGzKWme+Rcx MLXFFecwrwXzw=; b=w8x5r2jwr8cocB9Qc0Ecz/agOIjetWicylX36qwkZ5Ud/S 2ahaReZ+xepAOW4nMzwhZRSNCLY0UlPI4PBrW11zPf2xUxBeN/Ka+ldiA6tpXfYV NQNTWaN/TN7AVJAElJu9pycXOnHlyMLVzowX440rYhVOkcZcXYAnwWvbaERno= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 2BADC1005D for ; Thu, 13 Mar 2014 16:14:04 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1479773wes.34 for ; Thu, 13 Mar 2014 16:14:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZYmzPuFFiT7ipMBMQXhbxtnpmHg30RVD8Al1Glsr3AI=; b=ASfDKqQFNHtJJZk1BOEe+dUiow6cVcxZYpME2PxHVYcV0fAXrznBpuktwjjou4npdz M6fBnMjrKp6Ti0La6AVAfX18p2F/VZfm7UgGxOKYxVpiC6CtyOD2NyXoG7bVEENRgHEE lM2Y6gBEmW1j8OaD38DiynB7HET7OZUL//i+80gpQRY767m8gQk5KubtnGNSLQRtb2DZ zTSCs1+a3WkoVkXE1rn9W3hd/TGp0U0zE7yuNqQq+u0LfzGVYqiHXQ/r1HYmQa8+Ywid zWhnvYQkT3YDprDz2A5vJ/zyhl7tsIaY7hJUMTUVG6YY/o6KUimMIrCYReY1SrTF7KKM lrxg== MIME-Version: 1.0 X-Received: by 10.194.60.37 with SMTP id e5mr3781894wjr.32.1394752443167; Thu, 13 Mar 2014 16:14:03 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 16:14:03 -0700 (PDT) Date: Thu, 13 Mar 2014 18:14:03 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/0oS47212lqAEAIFLB_AXPouCPqk Cc: Paul Hoffman , "json@ietf.org" , Matthew Morley , Larry Masinter Subject: [Json] JSON text sequences and semi-online parsing (Re: Regarding JSON text sequence ambiguities (...) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 23:14:14 -0000 On Thu, Mar 13, 2014 at 4:43 PM, Tim Bray wrote: > I=E2=80=99m halfway convinced that it might be useful to say that if you = are > persisting something as chunks of JSON, use X as a separator. I wouldn= =E2=80=99t be But they aren't chunks. They are proper, fully-formed JSON texts. > surprised to see the advent of standardized log-as-JSON libraries. I=E2= =80=99d go Neither would I. > further and say that if you are doing this, use objects too. Having said I'm going to write a separate reply to this. Your insistence on top-level objectness deserves a complete treatment. > that, it=E2=80=99s not obvious that this is the kind of format that you= =E2=80=99d > interchange much, so the case for a media type is weak. Let's talk about not-online, online, and what I'll call semi-online parsing= . Consider jq once more. At this time jq's parser handles incremental parsing, but is not online. This means that it can parse a top-level array of 10e6 values, say, incrementally but it won't produce any values until the final ']' is read. But jq gladly reads JSON text sequences, producing each top-level value as it is read. Therefore jq can handle JSON text sequences in a semi-online way: online for the sequence, not online for each element. A semi-online parsing approach actually happens to be a very useful way to deal with logs and databases, where you know you're dealing with a sequence of things, possibly of indeterminate size, possibly infinite (tail -f ...), but where each element of the sequence is generally expected to be small. Not-at-all-online parsing simply does not work in these cases. But fully-online parsing is a real PITA, since the parser then produces outputs like [, ] or worse, and one is likely to aggregate results that form discrete entities, usually one or two levels down from the top-level. Now, it should be possible to build a semi-online JSON parser that is online only for top-level arrays. But if you have a not-online JSON parser you can just use JSON text sequences to build a semi-online JSON text sequence parser. I.e., it's trivial to implement semi-online parsing of JSON text sequences with any off-the-shelf JSON text parser. That's *huge* win because not-online JSON parsers are a dime a dozen, and a semi-online parse is pretty much the sweet spot for online vs. simple. This is exactly what jq does, as described above. Nico -- From nobody Thu Mar 13 16:23:25 2014 Return-Path: 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 A35FC1A06EE for ; Thu, 13 Mar 2014 16:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4hAkz-u3Hl1M for ; Thu, 13 Mar 2014 16:23:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7201A0790 for ; Thu, 13 Mar 2014 16:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140313232320.17203.35903.idtracker@ietfa.amsl.com> Date: Thu, 13 Mar 2014 16:23:20 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/h0HVaz8S6Sx2IY_8Mi8yQqoGPLo Subject: [Json] Milestones changed for json WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 23:23:23 -0000 Changed milestone "Request publication of JSON specification", set due date to February 2014 from January 2014, resolved as "Done". URL: http://datatracker.ietf.org/wg/json/charter/ From nobody Thu Mar 13 16:24:00 2014 Return-Path: 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 1EFC11A0786 for ; Thu, 13 Mar 2014 16:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XOReb-bQbeqQ for ; Thu, 13 Mar 2014 16:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D90721A079E for ; Thu, 13 Mar 2014 16:23:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140313232356.17195.37615.idtracker@ietfa.amsl.com> Date: Thu, 13 Mar 2014 16:23:56 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/EQwzbephJy7-w5lUKTlAzVnB29o Subject: [Json] Milestones changed for json WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 23:23:59 -0000 Deleted milestone "Request publication of JSON specification". URL: http://datatracker.ietf.org/wg/json/charter/ From nobody Thu Mar 13 16:24:31 2014 Return-Path: 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 53F4B1A0798 for ; Thu, 13 Mar 2014 16:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GBYRuFM3-74N for ; Thu, 13 Mar 2014 16:24:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3F11A0786 for ; Thu, 13 Mar 2014 16:24:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140313232426.17256.73308.idtracker@ietfa.amsl.com> Date: Thu, 13 Mar 2014 16:24:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/qtiAe-NlA8Ga4GRjFzOgugQkY0U Subject: [Json] Milestones changed for json WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 23:24:29 -0000 URL: http://datatracker.ietf.org/wg/json/charter/ From nobody Thu Mar 13 16:28:06 2014 Return-Path: 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 C1F791A0795 for ; Thu, 13 Mar 2014 16:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 BG0Fuzrt2B71 for ; Thu, 13 Mar 2014 16:28:03 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id C98321A0798 for ; Thu, 13 Mar 2014 16:28:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,650,1389704400"; d="scan'208";a="188682165" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 14 Mar 2014 10:27:56 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7376"; a="260482220" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 14 Mar 2014 10:27:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Fri, 14 Mar 2014 10:27:55 +1100 From: "Manger, James" To: Larry Masinter Date: Fri, 14 Mar 2014 10:27:54 +1100 Thread-Topic: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) Thread-Index: Ac8/D7+DcUOOggBKShuVa/3mAi4zUwAAU/qg Message-ID: <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/F8EZ0JiufwRxG5VrMTBIkpsuiGo Cc: "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 23:28:05 -0000 PiA+PiBkZXNlcnZpbmcgb2YgaXRzIG93biBNSU1FIHR5cGUgYW5kIHNvIG9uLg0KPiA+DQo+ID4g bm8sIG5vdCBhbGwgZm9ybWF0cyBuZWVkIE1JTUUgdHlwZXMuIFRoZXJlIGFyZSBpbmZpbml0ZWx5 IG1hbnkNCj4gZm9ybWF0cy4NCj4gPiBNSU1FIGlzIG9uZSB3YXkgb2Ygbm90aW5nIGEgZmlsZSBm b3JtYXQgYW5kIGRpc3Rpbmd1aXNoaW5nIGl0IGZyb20NCj4gb3RoZXJzLCBidXQgbW9zdCBhcHBs aWNhdGlvbnMgZG9uJ3QgTkVFRCB0byBuYW1lIHRoZSB0eXBlcyB0aGV5IGFjY2VwdA0KPiBhbmQg aW4gZ2VuZXJhbCwgdGhleSBjYW4ndC4NCj4gDQo+IFRoZSBzYW1lIGFyZ3VtZW50IGxlYWRzIHRv IG5vdCBuZWVkaW5nIGFwcGxpY2F0aW9uL2pzb24gZWl0aGVyLiAgQW5kDQo+IHlldCB0aGVyZSBp dCBpcy4NCj4gDQo+IEZvciBIVFRQIGFwcGxpY2F0aW9ucyBhbiBhcHBsaWNhdGlvbi9qc29uLXRl eHQtc2VxdWVuY2UgdHlwZSBtaWdodA0KPiBtZWFuIHRoYXQgYSBzZXJ2ZXIgY291bGQgZ2VuZXJh dGUgTiBvYmplY3RzIG9uZSBhdCBhIHRpbWUgaW5zdGVhZCBvZg0KPiBnZW5lcmF0aW5nIHRoZW0g YWxsIGludG8gYSB0b3AtbGV2ZWwgYXJyYXkgdGhlbiBzZW5kaW5nIHRoYXQgb25jZQ0KPiBidWls dC4gIFN1cmUsIGl0J3Mgbm90IGhhcmQgdG8gYnVpbGQgYSB0b3AtbGV2ZWwgYXJyYXkgaW4gYW4g b25saW5lDQo+IG1hbm5lciwgYnV0IGlmIHlvdSd2ZSBldmVyIHJ1biBpbnRvIGFuIGFwcGxpY2F0 aW9uIHRoYXQgZG9lc24ndCwgeW91DQo+IGtub3cgdGhhdCB0aGVyZSBpcyB2YWx1ZSBpbiB0aGlz Lg0KPiANCj4gPiBJIHRoaW5rIHRvIGp1c3RpZnkgYSBuZXcgTUlNRSB0eXBlLCB5b3UgbmVlZCB0 byBwcm92aWRlIGEgY29uY3JldGUNCj4gdXNlIGNhc2UgdGhhdCB3b3VsZCBhY3R1YWxseSB1c2Ug aXQgYW5kIG5lZWQgaXQuICBJbiBtb3N0IG9mIHRoZQ0KPiBjb250ZW50LW5lZ290aWF0aW9uIHNj ZW5hcmlvcywgTUlNRSB0eXBlcyBhcmUgZmFyIHRvbyBjb3Vyc2UtZ3JhaW5lZCB0bw0KPiBleHBy ZXNzIGNvbnRlbnQtZmVhdHVyZXMuDQoNCg0KTWVkaWEgdHlwZXMgYXJlIGNoZWFwIGFyZW7igJl0 IHRoZXk/IEkgY2Fubm90IHNlZSBhbnkgcmVhc29uIG5vdCB0byBkZWZpbmUgb25lIHdoaWxlIHNw ZWNpZnlpbmcgYSBzZXF1ZW5jZSBvZiBKU09OIHZhbHVlcy4NCg0KSG93IGFib3V0DQogIGFwcGxp Y2F0aW9uL2pzb25zDQppdCBpcyBhIGJpdCBzaG9ydGVyIHRoYW4gYXBwbGljYXRpb24vanNvbi10 ZXh0LXNlcXVlbmNlOyBhbmQgd2UgY2FuIHVzZSAranNvbnMgYXMgYSBtZWRpYSB0eXBlIGV4dGVu c2lvbiBpZiByZXF1aXJlZC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Thu Mar 13 17:29:51 2014 Return-Path: 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 CEAD41A0786 for ; Thu, 13 Mar 2014 17:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 TdZPbdmqK5IX for ; Thu, 13 Mar 2014 17:29:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B500B1A0796 for ; Thu, 13 Mar 2014 17:29:46 -0700 (PDT) Received: from netb ([89.204.139.151]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M2Glc-1XGDbK3AZw-00s8Xt; Fri, 14 Mar 2014 01:29:32 +0100 From: Bjoern Hoehrmann To: "Manger, James" Date: Fri, 14 Mar 2014 01:29:30 +0100 Message-ID: References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ggpfFfWHvZuwajqD3PZOebt9e0m6+wmLce6sQMTBffbWyGBRMAt JPLOXeIyPem6KGsbPHMO7IZeZ6C9velpLK3/wavcx652sJb7PQTDZJZePa6V8d+B93vz8Lv UKVx1r6tEe/5hJ/uiiP2a2ph0Lr4XfZu7wES8iu/bxXRA2NT3Te6E/CnDTw5JIDyX7cFI9q Eo4KHILNAnK/esZ2j/yjg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/oSPxIKJVq3IZKM9pBxWOWN595H0 Cc: "json@ietf.org" , Larry Masinter Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 00:29:50 -0000 * Manger, James wrote: >How about > application/jsons >it is a bit shorter than application/json-text-sequence; and we can use >+jsons as a media type extension if required. Single character differences are not a very good pattern and this one may also have the wrong connotations (e.g., is 'jsons' to 'json' as 'https' is to 'http'). -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Thu Mar 13 17:32:03 2014 Return-Path: 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 405B51A0778 for ; Thu, 13 Mar 2014 17:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 TMV6knHF8DXR for ; Thu, 13 Mar 2014 17:31:57 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8E1A0752 for ; Thu, 13 Mar 2014 17:31:57 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so2097608qcx.24 for ; Thu, 13 Mar 2014 17:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7otj/AhA0iA/mKWo4eHZXhZDwCpCFZpdlrVjqrXpngw=; b=UJbic8pr0mIaq0YdOia0bZPAjsXs5MHbKFYX9seuMWR7deEAUKrHBFmX3eBFbwGJWp 2fuVe4gAi6/vrmQd7NjLcEf8osqiRBqLiGoyU1u9f4a8C5qJn8VWVf/oUhXXc4L2Ojjq Jn3RavddC7HdhnlogxqwI2F2oXG9UsWRj77rMAIzRDuvQpC6BcXDqjBaXFQpLzaWnuj5 AkcCMCvHrGItoLloMW+IoC1iQ/wjAgjiKppojxgP0qApTYyqZ40IY1o52Q7Okhsyxdlu mTMeUVuGmsLnHp46WfEOfbwxwXoXs/8OKW9P/umlvZzkN1F/nz9ZjIHibmIZpp0Z9nfH +ZGQ== MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr6298786qai.16.1394757110991; Thu, 13 Mar 2014 17:31:50 -0700 (PDT) Received: by 10.140.42.164 with HTTP; Thu, 13 Mar 2014 17:31:50 -0700 (PDT) In-Reply-To: References: <20140307171244.B1B8D7FC392@rfc-editor.org> <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> Date: Thu, 13 Mar 2014 17:31:50 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c2c27a262cf104f4863277 Archived-At: http://mailarchive.ietf.org/arch/msg/json/0_LNrrqpNt6QxBmMHt9BTmWPjuE Cc: Barry Leiba , Pete Resnick , Paul Hoffman , "json@ietf.org" , "vfaronov@gmail.com" , "mamille2@cisco.com" , Larry Masinter Subject: Re: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 00:32:00 -0000 --001a11c2c27a262cf104f4863277 Content-Type: text/plain; charset=ISO-8859-1 Oh bummer, I had raised this earlier: - Rob On Thu, Mar 13, 2014 at 2:33 PM, Tim Bray wrote: > That idea is at least plausible. And I bet a walk through the unicode > separator and white-space definitions might turn up a few more candidates. > > > On Thu, Mar 13, 2014 at 2:31 PM, Larry Masinter wrote: > >> > The WG chairs request that you approve this errata. >> >> >> I think the errata would be more useful if it actually explained the >> \u2028, \u2029 exception, rather than leaving it in a potentially unstable >> reference >> http://timelessrepo.com/json-isnt-a-javascript-subset >> >> Should \u2028 \u2029 characters be disallowed from an "i-json" profile? >> Since the purpose is a "safe subset"? >> >> >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c2c27a262cf104f4863277 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh bummer, I had raised this earlier:


- Rob


On Thu, Mar 13, 2014 at 2:33 PM, Tim Bray <tbra= y@textuality.com> wrote:
That idea is at least plausible. And I bet a wa= lk through the unicode separator and white-space definitions might turn up = a few more candidates.


On Thu, Mar 1= 3, 2014 at 2:31 PM, Larry Masinter <masinter@adobe.com> wro= te:
> The WG chairs request that you app= rove this errata.


I think the errata would be more useful if it actually explained the = \u2028, \u2029 exception, rather than leaving it in a potentially unstable = reference
http://timelessrepo.com/json-isnt-a-javascript-subset

Should \u2028 \u2029 characters be disallowed from an "i-json" pr= ofile? Since the purpose is a "safe subset"?




_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--001a11c2c27a262cf104f4863277-- From nobody Thu Mar 13 18:17:06 2014 Return-Path: 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 13CEB1A07BB for ; Thu, 13 Mar 2014 18:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 MVp3MAyAwNz6 for ; Thu, 13 Mar 2014 18:17:03 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id C2EDD1A07BA for ; Thu, 13 Mar 2014 18:17:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,650,1389704400"; d="scan'208";a="201709574" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 14 Mar 2014 12:16:54 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7376"; a="203707113" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 14 Mar 2014 12:16:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 14 Mar 2014 12:16:08 +1100 From: "Manger, James" To: Bjoern Hoehrmann Date: Fri, 14 Mar 2014 12:16:07 +1100 Thread-Topic: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) Thread-Index: Ac8/HH1PhVawtQI6T1Cf4bMGsncA4wABbUXw Message-ID: <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/HSp0sqqqkhL965FXq1xTGiexrv4 Cc: "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:17:04 -0000 PiA+ICBhcHBsaWNhdGlvbi9qc29ucw0KDQo+IFNpbmdsZSBjaGFyYWN0ZXIgZGlmZmVyZW5jZXMg YXJlIG5vdCBhIHZlcnkgZ29vZCBwYXR0ZXJuIGFuZCB0aGlzIG9uZQ0KPiBtYXkgYWxzbyBoYXZl IHRoZSB3cm9uZyBjb25ub3RhdGlvbnMgKGUuZy4sIGlzICdqc29ucycgdG8gJ2pzb24nIGFzDQo+ ICdodHRwcycgaXMgdG8gJ2h0dHAnKS4NCg0KSXQgaGFzIHRoZSBwZXJmZWN0IGNvbm5vdGF0aW9u OiBqc29ucyBsb29rcyBsaWtlIHRoZSBwbHVyYWwgb2YganNvbiwgd2hpY2ggaXMgcGVyZmVjdCBm b3IgYSBmb3JtYXQgaG9sZGluZyBhbnkgbnVtYmVyIG9mIEpTT04gdmFsdWVzLg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCg== From nobody Thu Mar 13 18:25:25 2014 Return-Path: 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 2E1611A07DA for ; Thu, 13 Mar 2014 18:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no 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 wSFNpTfs0rQa for ; Thu, 13 Mar 2014 18:25:19 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (unknown [69.163.253.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0913B1A07B8 for ; Thu, 13 Mar 2014 18:25:18 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 80A552005D10B for ; Thu, 13 Mar 2014 18:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FRClLRJI1ZpNfmH9OH/0 KF2eDW8=; b=R/j3aouomqEwqw7YISgDy7r0CIpsU9L4W/JmIO4YBfGQ92c55gXf 5IOwFhoZ/Du6RQk7eOwVejpd1W6G4Zblc9eIAmSZaW0k25NVe1ayWDKSvZ/JW4l0 Vl1J2aLd6/x3ybB/CdiBYJrgJPRX/WsYZHmg+opd504mWP9VpZ6L7Ac= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 33DD12005D10A for ; Thu, 13 Mar 2014 18:25:12 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hm4so1952272wib.1 for ; Thu, 13 Mar 2014 18:25:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rGdvnOcmUqr5tiIdOSuU43VudduV3rnhLcquPDt/5DU=; b=PNoM6LsE3jtb8vfFEmjcs+qEhGLmkkevyHlZvKGxgLTt/MIgE18M5Q7+Y/667q+05z ixM+H8EOJsSPk2DndvgUbDl1gFXPE6QPL1G5CPnwQWy4It/QekGfDq2+Vh5363ZzvQay vPt7pFT86sSJlqpxxSTzkBxZPy0poRu3SPaa3lkmgiwbM6mwHBDucfDqeDa6R+MkcPcL BVJ2hZL9pYoS5zoM2o7mfvIW9FuEQtQkIORGPa69oFda4Jz/xSzrdiBHtWYJ3zCLwOHu bhuZMdUo3AooBkefm77r9D5mxxBwDIQMWNVWR7TwbhtPNLnETkoxpqXUuZVq9ZJMaJdY qT5A== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr3900125wib.5.1394760311133; Thu, 13 Mar 2014 18:25:11 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 18:25:11 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 13 Mar 2014 20:25:11 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/GyYOgzvVzH4tkRvPEfI1x0-_hEE Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 01:25:20 -0000 On Thu, Mar 13, 2014 at 8:16 PM, Manger, James wrote: >> > application/jsons > >> Single character differences are not a very good pattern and this one >> may also have the wrong connotations (e.g., is 'jsons' to 'json' as >> 'https' is to 'http'). > > It has the perfect connotation: jsons looks like the plural of json, which is perfect for a format holding any number of JSON values. I'm sympathetic to a "single character differences" lead to typos/errors argument. I'm also sympathetic to an argument about wasting bandwidth. I happen to like application/jsons, but would settle for application/json-sequence. Nico -- From nobody Thu Mar 13 19:08:58 2014 Return-Path: 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 E3BFD1A0813 for ; Thu, 13 Mar 2014 19:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 rLYx4hv5Mn2W for ; Thu, 13 Mar 2014 19:08:54 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 626611A0831 for ; Thu, 13 Mar 2014 19:08:53 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2E28WuT023759; Fri, 14 Mar 2014 11:08:32 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 712a_8ba9_8aad333c_ab1d_11e3_991c_001e6722eec2; Fri, 14 Mar 2014 11:08:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 90598C048D; Fri, 14 Mar 2014 11:08:31 +0900 (JST) Message-ID: <53226496.5020806@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 11:08:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , "Manger, James" References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/VA3QbY9UdlyvEsEOgis-3-4s3P0 Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 02:08:57 -0000 On 2014/03/14 10:25, Nico Williams wrote: > On Thu, Mar 13, 2014 at 8:16 PM, Manger, James > wrote: >>>> application/jsons >> >>> Single character differences are not a very good pattern and this one >>> may also have the wrong connotations (e.g., is 'jsons' to 'json' as >>> 'https' is to 'http'). >> >> It has the perfect connotation: jsons looks like the plural of json, which is perfect for a format holding any number of JSON values. > > I'm sympathetic to a "single character differences" lead to > typos/errors argument. I'm also sympathetic to an argument about > wasting bandwidth. > > I happen to like application/jsons, but would settle for > application/json-sequence. The fact that something like application/json-text-sequence is lengthy also has the advantage that it may give a hint that this isn't a widely used format, whereas JSON itself is. And yes, MIME types, like any other sort of identifiers, are cheap. The cost isn't in the identifier itself, but in the confusion and loss of network effects that may result. Regards, Martin. From nobody Thu Mar 13 19:27:34 2014 Return-Path: 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 2C4FB1A06C1 for ; Thu, 13 Mar 2014 19:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 xs7Y5-gIypOh for ; Thu, 13 Mar 2014 19:27:29 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4141A06BF for ; Thu, 13 Mar 2014 19:27:29 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WOHq3-0000zE-SW; Thu, 13 Mar 2014 22:27:11 -0400 Date: Thu, 13 Mar 2014 22:27:11 -0400 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20140314022711.GL1554@mercury.ccil.org> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> <53226496.5020806@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53226496.5020806@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/FGHwsrixPfsHlilbGAU5CWEmEA4 Cc: Nico Williams , Bjoern Hoehrmann , "Manger, James" , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 02:27:31 -0000 "Martin J. Drst" scripsit: > The fact that something like application/json-text-sequence is > lengthy also has the advantage that it may give a hint that this > isn't a widely used format, whereas JSON itself is. No format is widely used when first defined. An advantage of a simple identifier is that it can be used as a "+" suffix. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie From nobody Thu Mar 13 20:03:06 2014 Return-Path: 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 ED2D61A0853 for ; Thu, 13 Mar 2014 20:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 WYnQRyc4Phn1 for ; Thu, 13 Mar 2014 20:03:02 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 597971A0700 for ; Thu, 13 Mar 2014 20:03:01 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2E32mnF002390; Fri, 14 Mar 2014 12:02:48 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 712a_ae3d_1fcc70d4_ab25_11e3_991c_001e6722eec2; Fri, 14 Mar 2014 12:02:48 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 37BFCC042B; Fri, 14 Mar 2014 12:02:48 +0900 (JST) Message-ID: <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 12:02:39 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matt Miller , "json@ietf.org" References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> In-Reply-To: <53222FFC.8070204@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/wqGOBPhl2_WgSsnU1ZDniLYtICQ Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 03:03:04 -0000 Hello Matt, On 2014/03/14 07:23, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 3/13/14, 3:23 PM, Larry Masinter wrote: >> I wonder if there is any lesson from XMPP-- which wanted >> sequence-of-XML-values in an indefinite length stream -- that would >> apply to JSON. What would XMPP look like if it were redone in JSON >> instead of XML? >> > > /me exchanges JSON chair hat for XMPP enthusiast hat ... > > If XMPP didn't exist and we instead did JMPP, it might be a series of > discrete objects. However, the direction of the later "XMPP over " > adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use > an existing transport that provides block-oriented framing around > complete structures. > > Dealing with partial XML-like structures in XMPP has ranged from > inconvenient to impractical because the vast majority of existing XML > software has assumed a whole XML document when parsing starts. There > are few libraries that truly allow one to feed XML in fits and starts > and get timely output without some amount of modification or > preprocessing. When the XMPP community took efforts to apply XMPP > over other transports, the direction has so far leaned toward the > whole documents that most implementations expect; even though the > preprocessing required is rather small, the ability to re-use existing > implementations without first considering oft-unpublished details was > a very powerful motivator. This is very valuable feedback. As far as I understand, the problem for XMPP has at least two parts: 1) The XML document arrives in pieces. 2) Parsing is done in pieces My understanding is that parsing in pieces is well covered by SAX parsers, so that the problems essentially came from 1). But problem 1) doesn't apply to JSON text sequences exchanged as MIME types, and it doesn't apply to log files as these are rarely read, and when read, that could just be done with something like > echo ']' > json-array-close.txt > cat logfile.json json-array-close.txt | json-parse (using [pseudo-]shell syntax). As for delayed exchange of multiple JSON texts, e.g. a (completely hypothetical) JMPP (JSON Messaging and Presence Protocol), one would try to use a message-oriented transport (e.g. WebSockets) and then not need a concept of JSON text sequences at all. Regards, Martin. From nobody Thu Mar 13 20:58:25 2014 Return-Path: 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 B42511A088C for ; Thu, 13 Mar 2014 20:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 Ulj4L2lt4jsM for ; Thu, 13 Mar 2014 20:58:21 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A11A0888 for ; Thu, 13 Mar 2014 20:58:21 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2E3w2mR014239; Fri, 14 Mar 2014 12:58:02 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 712a_cfd6_d72a079e_ab2c_11e3_991c_001e6722eec2; Fri, 14 Mar 2014 12:58:02 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 478D2C042B; Fri, 14 Mar 2014 12:58:02 +0900 (JST) Message-ID: <53227E37.9050300@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 12:57:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Cowan References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> <53226496.5020806@it.aoyama.ac.jp> <20140314022711.GL1554@mercury.ccil.org> In-Reply-To: <20140314022711.GL1554@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/xaqPS-4pExaLoF204mIDn5PtbCE Cc: Nico Williams , Bjoern Hoehrmann , "Manger, James" , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 03:58:23 -0000 On 2014/03/14 11:27, John Cowan wrote: > "Martin J. D=C3=BCrst" scripsit: > >> The fact that something like application/json-text-sequence is >> lengthy also has the advantage that it may give a hint that this >> isn't a widely used format, whereas JSON itself is. > > No format is widely used when first defined. Yes. But many if not most formats are defined but then never widely used. > An advantage of a simple identifier is that it can be used as a "+" > suffix. As far as I know, there are no limits on the theoretical number of=20 characters in Mime types, subtypes, or "+" suffixes. And I think creating a pleothra of json-related formats, and even giving=20 them "+" suffixes, goes just way overboard. The JSON text sequence idea comes from a minor inconvenience of JSON=20 arrays. The benefit of JSON is that it is simple and straightforward,=20 but that's apparently lost on most people in this discussion ;-(. Regards, Martin. From nobody Thu Mar 13 21:04:15 2014 Return-Path: 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 3E4861A0007 for ; Thu, 13 Mar 2014 21:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 H3UCfAAN1wL8 for ; Thu, 13 Mar 2014 21:04:11 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DE98A1A0005 for ; Thu, 13 Mar 2014 21:04:10 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so4809162wib.2 for ; Thu, 13 Mar 2014 21:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q7SwYaiuL8dpMl6+BnNA7hwsV3hPVnoG4VEjpzYGc4M=; b=uEoV8VY1aV05K2eHa3j9GGj0fm67iBZKNAEeEw9uHPWizdkYQSg6lGBpQsxlX3Jtdf TTP+YBk3RkMxDJJMIduYTIurmo4Ry1PFLrIqVcaraQUNhBgqfQ/vNDSVAaBOERY8JF30 XuwDbgz6VCFr0KEEm5PgoFxRS3mgDG5aHbS8Igen4oTKRxkdkrsYUPksYSVGgiJomXEK CuLQXhHwFaSyQ86AQ77q63YehIGu2swwLAyBxtzQ7j6zUIZECKVUt0bD4Uzd56LDb+Fj EFf3+cOSKF2JoUZZw5Sf2aDsBncEysm8PQwrRcF/335Tx/pBswzyc9t5kyf6vgAW/mfU DNtg== MIME-Version: 1.0 X-Received: by 10.180.185.232 with SMTP id ff8mr4261810wic.25.1394769843797; Thu, 13 Mar 2014 21:04:03 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Thu, 13 Mar 2014 21:04:03 -0700 (PDT) In-Reply-To: <5322714F.6080508@it.aoyama.ac.jp> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 04:04:03 +0000 Message-ID: From: Tatu Saloranta To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=001a11c364ba15459704f489298d Archived-At: http://mailarchive.ietf.org/arch/msg/json/XEPL4SnOCkanqWatcY2VWOpSPFI Cc: "json@ietf.org" , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:04:13 -0000 --001a11c364ba15459704f489298d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 3:02 AM, "Martin J. D=FCrst" wrote: > Hello Matt, > > > On 2014/03/14 07:23, Matt Miller wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 3/13/14, 3:23 PM, Larry Masinter wrote: >> >>> I wonder if there is any lesson from XMPP-- which wanted >>> sequence-of-XML-values in an indefinite length stream -- that would >>> apply to JSON. What would XMPP look like if it were redone in JSON >>> instead of XML? >>> >>> >> /me exchanges JSON chair hat for XMPP enthusiast hat ... >> >> If XMPP didn't exist and we instead did JMPP, it might be a series of >> discrete objects. However, the direction of the later "XMPP over " >> adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use >> an existing transport that provides block-oriented framing around >> complete structures. >> >> Dealing with partial XML-like structures in XMPP has ranged from >> inconvenient to impractical because the vast majority of existing XML >> software has assumed a whole XML document when parsing starts. There >> are few libraries that truly allow one to feed XML in fits and starts >> and get timely output without some amount of modification or >> preprocessing. When the XMPP community took efforts to apply XMPP >> over other transports, the direction has so far leaned toward the >> whole documents that most implementations expect; even though the >> preprocessing required is rather small, the ability to re-use existing >> implementations without first considering oft-unpublished details was >> a very powerful motivator. >> > > This is very valuable feedback. > > As far as I understand, the problem for XMPP has at least two parts: > 1) The XML document arrives in pieces. > 2) Parsing is done in pieces > > My understanding is that parsing in pieces is well covered by SAX parsers= , > so that the problems essentially came from 1). But problem 1) doesn't app= ly > to JSON text sequences exchanged as MIME types, and it doesn't apply to l= og > files as these are rarely read, and when read, that could just be done wi= th > something like > > echo ']' > json-array-close.txt > > cat logfile.json json-array-close.txt | json-parse > (using [pseudo-]shell syntax). > > As for delayed exchange of multiple JSON texts, e.g. a (completely > hypothetical) JMPP (JSON Messaging and Presence Protocol), one would try = to > use a message-oriented transport (e.g. WebSockets) and then not need a > concept of JSON text sequences at all. > > Major challenge with sequence of XML documents is really just implementors, and inertia. Having written a fully conformat XML parser that optionally supports "fragment mode" (Woodstox for Java; implements SAX and Stax APIs) I can say that compared to all other work, supporting multiple root-level documents is a minor addition. Mode is used/useful for supporting XMPP, as well as for use for streaming logging, similar to what has been discussed for JSON. It has to be explicitly enabled (since such usage is non-compliant, having multiple roots). There are some minor details (like xml declaration, what to do if it is repeated) to deal with, to allow simple concatenation, but all in all it is not a big technical problem. I mean, compared to writing actual fully compliant parser (supporting DTD is 80+% of the deal). -+ Tatu +- > Regards, Martin. > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c364ba15459704f489298d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 14, 2014 at 3:02 AM, "Martin J. D=FCrst&q= uot; <duerst@it.aoyama.ac.jp> wrote:
Hello Matt,
<= div class=3D"h5">

On 2014/03/14 07:23, Matt Miller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 3/13/14, 3:23 PM, Larry Masinter wrote:
I wonder if there is any lesson from XMPP-- =A0which wanted
sequence-of-XML-values in an indefinite length stream -- that would
apply to JSON. What would XMPP look like if it were redone in JSON
instead of XML?


/me exchanges JSON chair hat for XMPP enthusiast hat ...

If XMPP didn't exist and we instead did JMPP, it might be a series of discrete objects. =A0However, the direction of the later "XMPP over &l= t;x>"
adaptations (e.g., [BOSH] and [XMPP-WS]) speak toward wanting to use
an existing transport that provides block-oriented framing around
complete structures.

Dealing with partial XML-like structures in XMPP has ranged from
inconvenient to impractical because the vast majority of existing XML
software has assumed a whole XML document when parsing starts. =A0There
are few libraries that truly allow one to feed XML in fits and starts
and get timely output without some amount of modification or
preprocessing. =A0When the XMPP community took efforts to apply XMPP
over other transports, the direction has so far leaned toward the
whole documents that most implementations expect; even though the
preprocessing required is rather small, the ability to re-use existing
implementations without first considering oft-unpublished details was
a very powerful motivator.

This is very valuable feedback.

As far as I understand, the problem for XMPP has at least two parts:
1) The XML document arrives in pieces.
2) Parsing is done in pieces

My understanding is that parsing in pieces is well covered by SAX parsers, = so that the problems essentially came from 1). But problem 1) doesn't a= pply to JSON text sequences exchanged as MIME types, and it doesn't app= ly to log files as these are rarely read, and when read, that could just be= done with something like
> echo ']' > json-array-close.txt
> cat logfile.json json-array-close.txt | json-parse
(using [pseudo-]shell syntax).

As for delayed exchange of multiple JSON texts, e.g. a (completely hypothet= ical) JMPP (JSON Messaging and Presence Protocol), one would try to use a m= essage-oriented transport (e.g. WebSockets) and then not need a concept of = JSON text sequences at all.


Major challenge with sequence of XML d= ocuments is really just implementors, and inertia.
Having wri= tten a fully conformat XML parser that optionally supports "fragment m= ode" (Woodstox for Java; implements SAX and Stax APIs) I can say that = compared to all other work, supporting multiple root-level documents is a m= inor addition. Mode is used/useful for supporting XMPP, as well as for use = for streaming logging, similar to what has been discussed for JSON. It has = to be explicitly enabled (since such usage is non-compliant, having multipl= e roots).

There are some minor details (like xml declaration, what to do if it is= repeated) to deal with,
to allow simple concatenation, but all in all = it is not a big technical problem. I mean, compared to writing actual fully= compliant parser (supporting DTD is 80+% of the deal).

-+ Tatu +-

=A0
Regards, =A0 Martin.


_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c364ba15459704f489298d-- From nobody Thu Mar 13 21:17:33 2014 Return-Path: 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 0FE4F1A000A for ; Thu, 13 Mar 2014 21:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no 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 CAprLzX4fmkF for ; Thu, 13 Mar 2014 21:17:30 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id D90B41A0002 for ; Thu, 13 Mar 2014 21:17:29 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id D7EDB59805F for ; Thu, 13 Mar 2014 21:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=NKIcoAzkCTuJI9NWp9ph34lhOD4=; b=HVlO1H8tqkS rQnaqHvtfl34KbyfsKX4+QHBjIKt5PPCy52biAs+9qMwmWw+upYE5KvOgqgFsys2 1krnZ7DdsiOtl1nmlL3PlkjflBZnKQ0JPmdeZYjxyPTaNKVCJgXrWNyeuvr3fRju CudGsvoXZoEsqhGDAbRMEeu5ZMWeoypo= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 8C518598057 for ; Thu, 13 Mar 2014 21:17:22 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so1594078wes.26 for ; Thu, 13 Mar 2014 21:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dLkfk3iTBoWM+elW6+TqaZuGNnOz/KETdpbGLNwf194=; b=Xv5e9wkse4zbKVmaaBLRJh/Fn2lc/OMUEgM1X+WpRkKNmtj/Lzmupq4Sy7yMXu2JcY qEugJTzYb0C11XUpo57z9lf/0ZiZE2zPE6sgFc8t6i9SD4TEu64HtMnoe+cMHhOjciUa yXbJgXUgJkB77DItHFOU7K/t5ZZcl3mZW+axQuTqJkg1N/11x0Y48kinJjFD+MWKClWW iDDSmX791p+kJgjNuPwVAikC6p6zDUUmMy/B+Khsuq5QLXHFCB/kS1kQdal3KN3RgjLO Fyt2z/d+B6tYTJwC8nJz2yya7jcdZi6s3rrKz8AW3iyOD+Y+jEKLVaSY7V3z5KliFP4K aS7g== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr4310617wib.39.1394770641233; Thu, 13 Mar 2014 21:17:21 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 21:17:21 -0700 (PDT) In-Reply-To: <53227E37.9050300@it.aoyama.ac.jp> References: <3416a6327a8a4cd3b49bee3c2e548870@BL2PR02MB307.namprd02.prod.outlook.com> <255B9BB34FB7D647A506DC292726F6E115402F019B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115402F04C6@WSMSG3153V.srv.dir.telstra.com> <53226496.5020806@it.aoyama.ac.jp> <20140314022711.GL1554@mercury.ccil.org> <53227E37.9050300@it.aoyama.ac.jp> Date: Thu, 13 Mar 2014 23:17:21 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/ZfUhyzlQeFkYKOGHtRrIQ7pXQcs Cc: "Manger, James" , Bjoern Hoehrmann , John Cowan , "json@ietf.org" Subject: Re: [Json] Regarding JSON text sequence ambiguities (Re: serializing sequences of JSON values) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:17:31 -0000 On Thu, Mar 13, 2014 at 10:57 PM, "Martin J. D=C3=BCrst" wrote: > The JSON text sequence idea comes from a minor inconvenience of JSON arra= ys. Hmm? For me it comes from jq, and there it's just... natural, nothing to do with inconveniences of JSON arrays, and everything to do with the need to have indeterminate-length streams of values. Exploring that further there's the fact that non-online JSON parsers can be used to construct JSON text sequence parsers that handle each text in a non-online manner, but the sequence in an online manner -- this makes a world of a difference when processing large amounts of data encoded in JSON: - One big array + not-online parser -> can't process more than fits in memory parsed, and can't start until it's all parsed. - JSON text sequence + not-online parser -> no limit based on number of texts, just size of each text. Needless to say, online parsers can handle huge texts just fine, but they are very difficult to use. JSON text sequences are just the sweet spot for easy of use and performance. > The benefit of JSON is that it is simple and straightforward, but that's > apparently lost on most people in this discussion ;-(. Which is why people want to use it more and more, even for large datasets, and then you run into the need for an online parser. Or JSON text sequencing. Nico -- From nobody Thu Mar 13 21:21:20 2014 Return-Path: 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 3DBE71A000A for ; Thu, 13 Mar 2014 21:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 Sw4bRM5BZBG4 for ; Thu, 13 Mar 2014 21:21:17 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (unknown [69.163.253.176]) by ietfa.amsl.com (Postfix) with ESMTP id F2EB11A0002 for ; Thu, 13 Mar 2014 21:21:16 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 508356B007C for ; Thu, 13 Mar 2014 21:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=m6nqJxliztsI9iI1T/t6 /bCcpik=; b=gWYQBPuC7sEtqVcO13judd+9wfLoALY5yPexdJYZAlzkXxfl3HWW HhNtkxYFoxWDU1/JqFH0uZbUQvrf/YV0jzIG5mH7m9gNXdFm1tNrOQSzfwIUWbrA gtWQiFsesd0d/5cSkJO34hzUC5ExHVJWVoF8yV4mcWitWnc1kfpdNOY= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 02D8E6B007B for ; Thu, 13 Mar 2014 21:21:09 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so4814184wib.15 for ; Thu, 13 Mar 2014 21:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DNus/+yfHF40Xh9KT8Vpqn9fQd5Ve6d082/LTJ1ok5k=; b=L/UFc+SRK7UhJCnlig2uLitDhdifedgmuK1FEU0zwgEfcdJWrBVbh91TZoGUmhELVE 2DYEISWJcAIr9PE17ON1+MDIBvOl0VTwXxoRoXEhfttjFCXXETKbS3G/UukxHeUHuu3b TfwgDqnvATCuc8ual0zoesLiuOsfbhBxBYqc9WS6c/RGyDoFcs7KHNXC+naxkTAEouf3 R5PJiY05FKRB9LVXTVImSFvOPNkh8T+ZHh51rbwcf17xj3AaKqnfzfQUXcEeVGGQeDRW LiK6+UI334cGtVlgy1C50lS9/XePBXfZg6WYnsfabqY1dBw1AJjFRoMSI5lNA2HWt1aK BrVg== MIME-Version: 1.0 X-Received: by 10.194.78.173 with SMTP id c13mr4741523wjx.0.1394770868873; Thu, 13 Mar 2014 21:21:08 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Thu, 13 Mar 2014 21:21:08 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Thu, 13 Mar 2014 23:21:08 -0500 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/16X-XWzfpAUhcmRruQMNqtXHJwo Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Matt Miller , "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:21:18 -0000 On Thu, Mar 13, 2014 at 11:04 PM, Tatu Saloranta wrote: > Major challenge with sequence of XML documents is really just implementors, > and inertia. > Having written a fully conformat XML parser that optionally supports > "fragment mode" (Woodstox for Java; implements SAX and Stax APIs) I can say > that compared to all other work, supporting multiple root-level documents is > a minor addition. Mode is used/useful for supporting XMPP, as well as for > use for streaming logging, similar to what has been discussed for JSON. It > has to be explicitly enabled (since such usage is non-compliant, having > multiple roots). > > There are some minor details (like xml declaration, what to do if it is > repeated) to deal with, > to allow simple concatenation, but all in all it is not a big technical > problem. I mean, compared to writing actual fully compliant parser > (supporting DTD is 80+% of the deal). By comparison, parsing a JSON text sequence can be done with any JSON parser, especially when the encoder is nice enough to use "compact" encoding options and uses newline as the separator. To be efficient it's best to have an incremental parser (that is, that can be fed chunks of input until the end of the text is found). That's how jq handles JSON text sequences. It's really quite simple. Nico -- From nobody Thu Mar 13 22:27:19 2014 Return-Path: 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 3424C1A0040 for ; Thu, 13 Mar 2014 22:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 29UNaU_bF1P9 for ; Thu, 13 Mar 2014 22:27:15 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF21A003D for ; Thu, 13 Mar 2014 22:27:15 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so1695491wes.15 for ; Thu, 13 Mar 2014 22:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KmYsc7FPqQmCS+XsGJfePzElrWX0SBR+JtESkwllFF0=; b=YG7wxgNLnJZBkA8JXqqTMwZGu03LrVy3p7LQB5ce3hdzZoCaoMqezLyPd9WKax9xeE GmKbbu57xADE/XLzG9w1RaPebtkOQeENuTYgWW/Qv+M4NxUoNMzDTdvMPV0KBe+/YzMl zhLyvQSyoBfET1mFcgvTK9hFvVWajczxavJCw4tfMzrJEJ5o+T8nxhK7WJHFTM7So3Fw 9XxYyowN2aW+MZR0Fx4bX5v+4IVFvO/0dTm377DlhMp55Cs308FRQ2tZnXC2xvvycbKw G1c1GGwpmdVRZz6nYvVw+5pnFRVyYSORUxiqHnG9/VrGeMFA9iWsr4+E07/gsmEqPa8V XbCw== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr4923008wjp.22.1394774828124; Thu, 13 Mar 2014 22:27:08 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Thu, 13 Mar 2014 22:27:08 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 05:27:08 +0000 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b3a82142c0f2b04f48a52b5 Archived-At: http://mailarchive.ietf.org/arch/msg/json/p8sO5lIuEtM90k2aN9dQRyuMp8o Cc: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , Matt Miller , "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 05:27:17 -0000 --047d7b3a82142c0f2b04f48a52b5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 4:21 AM, Nico Williams wrote: > On Thu, Mar 13, 2014 at 11:04 PM, Tatu Saloranta > wrote: > > Major challenge with sequence of XML documents is really just > implementors, > > and inertia. > > Having written a fully conformat XML parser that optionally supports > > "fragment mode" (Woodstox for Java; implements SAX and Stax APIs) I can > say > > that compared to all other work, supporting multiple root-level > documents is > > a minor addition. Mode is used/useful for supporting XMPP, as well as for > > use for streaming logging, similar to what has been discussed for JSON. > It > > has to be explicitly enabled (since such usage is non-compliant, having > > multiple roots). > > > > There are some minor details (like xml declaration, what to do if it is > > repeated) to deal with, > > to allow simple concatenation, but all in all it is not a big technical > > problem. I mean, compared to writing actual fully compliant parser > > (supporting DTD is 80+% of the deal). > > By comparison, parsing a JSON text sequence can be done with any JSON > parser, especially when the encoder is nice enough to use "compact" > encoding options and uses newline as the separator. To be efficient > it's best to have an incremental parser (that is, that can be fed > chunks of input until the end of the text is found). > > That's how jq handles JSON text sequences. It's really quite simple. > > Yes, absolutely. This is also one area where otherwise frustrating feature of JSON -- requirement that linefeeds must be quoted in text values -- helps. -+ Tatu +- --047d7b3a82142c0f2b04f48a52b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 14, 2014 at 4:21 AM, Nico Williams <nic= o@cryptonector.com> wrote:
On Thu, Mar 13, 2014 at 11:0= 4 PM, Tatu Saloranta <tsaloranta= @gmail.com> wrote:
> Major challenge with sequence of XML documents is really just implemen= tors,
> and inertia.
> Having written a fully conformat XML parser that optionally supports > "fragment mode" (Woodstox for Java; implements SAX and Stax = APIs) I can say
> that compared to all other work, supporting multiple root-level docume= nts is
> a minor addition. Mode is used/useful for supporting XMPP, as well as = for
> use for streaming logging, similar to what has been discussed for JSON= . It
> has to be explicitly enabled (since such usage is non-compliant, havin= g
> multiple roots).
>
> There are some minor details (like xml declaration, what to do if it i= s
> repeated) to deal with,
> to allow simple concatenation, but all in all it is not a big technica= l
> problem. I mean, compared to writing actual fully compliant parser
> (supporting DTD is 80+% of the deal).

By comparison, parsing a JSON text sequence can be done with any JSON=
parser, especially when the encoder is nice enough to use "compact&quo= t;
encoding options and uses newline as the separator. =A0To be efficient
it's best to have an incremental parser (that is, that can be fed
chunks of input until the end of the text is found).

That's how jq handles JSON text sequences. =A0It's really quite sim= ple.


Yes, absolutely. This is also one area= where otherwise frustrating feature of JSON -- requirement that linefeeds = must be quoted in text values -- helps.

-+ Tatu +-

=A0
--047d7b3a82142c0f2b04f48a52b5-- From nobody Fri Mar 14 00:41:20 2014 Return-Path: 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 3179D1A00A5 for ; Fri, 14 Mar 2014 00:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no 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 1XEvFG6-IwBs for ; Fri, 14 Mar 2014 00:41:18 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (mysql.benrbradley.com [69.163.253.146]) by ietfa.amsl.com (Postfix) with ESMTP id 42FB71A0059 for ; Fri, 14 Mar 2014 00:41:18 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id A80BA2005D10D for ; Fri, 14 Mar 2014 00:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=s8nPBNNAE5UOeJegXXEa rntId5g=; b=xXjYuTysPD7xcQPlh0iqDWkPLb+mpAKDHn9aw0XNLc4HC2IQzUL9 fmhqspU4OWl/6oFuURtfC4huytbv/JddZNSsPeR9cubeU2EWJNpYI/IihWjeJ0Q0 U+iMCzQ+ftVBEXYiqHWbXLq+UT9q9TB3Iapw8iGBSnfvcrEzUGSfXFI= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 5BC5F2005D10A for ; Fri, 14 Mar 2014 00:41:11 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn9so4935919wib.16 for ; Fri, 14 Mar 2014 00:41:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s7FbpJjbgE1BB6jUZh5MLsYb0BhsbVMZajLqa56jY/Y=; b=hNEnbK0aX3ZtmPl8VfDu9iLoSE6p2ZS/1qhrnPzX3D7IZ9vNKfs4U0+m2RGQBrhSGL ZNVRukJqsXUM5JBcdA5ikB+t2423L7YtbeD8DQUiagHspGyYHBV8A5NGV1gb8ikPIJ7+ 2ex3mvv68C4xz0KWQccmHxiE/ZYuKZNcqlk69WR51Pa6B6ee5TQI/Co0cdsg0Cbj4013 /1NVFN5LpfWQVka9QD0KSQFsbUVvlIlQ6bIY1Hss+//csSG53t/SFiUpNjkiQY6+EXLm 5R3V0PGUW0kCg6E7wF64w3OEHwbXVA/8I/meXgfw5DNH67aKgp+/nHUeVy04GFSyWVbA fzog== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr4865705wib.5.1394782869993; Fri, 14 Mar 2014 00:41:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 00:41:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 00:41:09 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 02:41:09 -0500 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: multipart/alternative; boundary=f46d04430670813db504f48c319f Archived-At: http://mailarchive.ietf.org/arch/msg/json/nKFv75oKeIgbBP2p_dK_D8pyEMQ Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Matt Miller , json@ietf.org Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 07:41:19 -0000 --f46d04430670813db504f48c319f Content-Type: text/plain; charset=UTF-8 On Mar 14, 2014 12:27 AM, "Tatu Saloranta" wrote: > On Fri, Mar 14, 2014 at 4:21 AM, Nico Williams wrote: >> That's how jq handles JSON text sequences. It's really quite simple. >> > > Yes, absolutely. This is also one area where otherwise frustrating feature of JSON -- requirement that linefeeds must be quoted in text values -- helps. Indeed! That's the best reason to recommended the use of newline for maximum interop, maybe even require it. --f46d04430670813db504f48c319f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 14, 2014 12:27 AM, "Tatu Saloranta" <tsaloranta@gmail.com> wrote:
> On Fri, Mar 14, 2014 at 4:21 AM, Nico Williams <nico@cryptonector.com> wrote:
>> That's how jq handles JSON text sequences. =C2=A0It's real= ly quite simple.
>>
>
> Yes, absolutely. This is also one area where otherwise frustrating fea= ture of JSON -- requirement that linefeeds must be quoted in text values --= helps.

Indeed!=C2=A0 That's the best reason to recommended the = use of newline for maximum interop, maybe even require it.

--f46d04430670813db504f48c319f-- From nobody Fri Mar 14 09:37:48 2014 Return-Path: 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 00D821A018D for ; Fri, 14 Mar 2014 09:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 EZRSx7P22vpY for ; Fri, 14 Mar 2014 09:37:39 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id 813DE1A017C for ; Fri, 14 Mar 2014 09:37:25 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 9047431805D for ; Fri, 14 Mar 2014 09:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=whzBDwHxFBmsEhgvp0Aw i0/fv3A=; b=IT1n0JJllYMcqA11dsyUcylBy8QfyXfIU2i6T113nm1qi6gxeNNq 93eYSE54tyvf2rGsYvUxC8tg5flCJUkfXyhjF3q2P1LpbB+sHYuoOy91z+NknQAT McgLTaJ568x/lxj505FB3H+40Q2yA7CcNXTneRE0UjNn6lGYzX7taXI= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 42280318057 for ; Fri, 14 Mar 2014 09:37:18 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so2429090wgh.32 for ; Fri, 14 Mar 2014 09:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IVOF5cLGiTJ6Pth9BJaJnX2Gant7WMsfyuhfEtWa59Q=; b=ANZS3SZhXvV+asN4EugWN7+n4vW7RYMGSoddq40PMVukATnNkSEvDKTcz6Lis1WnmM Sp3kEOjkVLHgzWpYUPe1/kunfGBDvFtmr1hQImCAh3LRxK2AQAQ/dzRZMhl17TtBsm7g vBREe6BdhU9snF7xo4dYh4UcvtInkG3k8p5WZWZgMxmyJrAc6rj90JO1B5x3ecJoHbVb GiDZx44BV0CT19W6MLp8jdau4AfUfDn4wmWZGHITanEg9qXwd6kJ/NtpW4aN9rRXTAGB YLT1bxdW+6zlhIyoiBNI/hk35ShhwT2vak5ibAzMoj4qnHPM+ZEnE+aLazGt+dfWhYUE 6xBw== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr6940532wiw.39.1394815037036; Fri, 14 Mar 2014 09:37:17 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 09:37:16 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 11:37:16 -0500 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/8ynExNnoQ0l_-620bNTTdkowco8 Cc: Matt Miller , "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:37:41 -0000 The most interoperable form of JSON text sequence would be this: encoders MUST not use newlines in their JSON text encodings and MUST follow each JSON text with a newline. From nobody Fri Mar 14 09:48:38 2014 Return-Path: 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 72AA31A017E for ; Fri, 14 Mar 2014 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 InI_a1IybyQH for ; Fri, 14 Mar 2014 09:48:35 -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 A8C6B1A00F1 for ; Fri, 14 Mar 2014 09:48:34 -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.5/8.14.5) with ESMTP id s2EGmElt005206; Fri, 14 Mar 2014 17:48:14 +0100 (CET) Received: from eduroam-pool7-0603.wlan.uni-bremen.de (eduroam-pool7-0603.wlan.uni-bremen.de [134.102.114.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1E0B528D; Fri, 14 Mar 2014 17:48:14 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Fri, 14 Mar 2014 17:48:12 +0100 X-Mao-Original-Outgoing-Id: 416508492.876836-29f7ea6ebf531bbef360c180cdad69ea Content-Transfer-Encoding: quoted-printable Message-Id: <4EDB6664-434E-46B3-9B15-BE1508C3EE2C@tzi.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/SsxX1zsFJ--_nV8Zc1KMlMeLKk0 Cc: "json@ietf.org" , Tatu Saloranta , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:48:36 -0000 On 14 Mar 2014, at 17:37, Nico Williams wrote: > The most interoperable form of JSON text sequence would be this: > encoders MUST not use newlines in their JSON text encodings and MUST > follow each JSON text with a newline. +1, and if there is any point in writing this up, we should only write = up this most interoperable variant. Gr=FC=DFe, Carsten From nobody Fri Mar 14 10:05:06 2014 Return-Path: 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 C74F01A018B for ; Fri, 14 Mar 2014 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 u8P6RslNhflZ for ; Fri, 14 Mar 2014 10:04:57 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (mysql.benrbradley.com [69.163.253.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1591A01A7 for ; Fri, 14 Mar 2014 10:04:48 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id ABC092005D111 for ; Fri, 14 Mar 2014 10:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tpws8wKh6Gqv7SN49Hol kmxUZmw=; b=evWdYxWr48se12e5zw2cd5SBp24xq1exaPIX8SPFkG2Mt14Minsc LvAUTpVGtdWRrz4cw32aOp7Yk6I7QnqIiwIZ9N9xaDVgB/ldxxBI2g4X+bD/ModM moAGAgBa5Nn54+NOuiRKwkZDNNPbpkjJkSf0Ib0BZWj7iG9pdyy6WeE= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 600D02005D10F for ; Fri, 14 Mar 2014 10:04:41 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so2421688wgh.35 for ; Fri, 14 Mar 2014 10:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7QslmPT8SFGYwiWC0ggUbB7ev2oyvPO3eLitVqM6Ryg=; b=QlLC1tyAtq2fZV1NByQGr94d7trZOI0IUbe+FwBTFxXaJ0it4hQHtC3UgQou7iQHD3 zRm5ml5Nt2D1gdBBpVt3KV9dC7HpIOyklysgw25dWzV+3f0pnkZ3NdoRshWW3hRexyFd jwdA9/GzF8+HBn7J6nRfsqQZrdR4YGTI/g+3ztjlB4Il7O1ATZ/7aVRAUajBbMbBwlfx C4tq/ucqrjyRvtTgeXDzKw1QjFr96vDk7vLLF2IjCIg+w0I2psudz/w6hr9AYN0h5y5t qSrOv/50n6+UDMyW4XfoKQtYwuHLQlq6mkaCw6UI365T6+qkIU3XI5akNWvnSX6HG6uq Qrcw== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr7545571wjq.40.1394816680372; Fri, 14 Mar 2014 10:04:40 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 10:04:40 -0700 (PDT) In-Reply-To: <4EDB6664-434E-46B3-9B15-BE1508C3EE2C@tzi.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <4EDB6664-434E-46B3-9B15-BE1508C3EE2C@tzi.org> Date: Fri, 14 Mar 2014 12:04:40 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/uoFMvhc70oB7bPU5rFMuGoEmDUo Cc: "json@ietf.org" , Tatu Saloranta , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:04:58 -0000 On Fri, Mar 14, 2014 at 11:48 AM, Carsten Bormann wrote: >> The most interoperable form of JSON text sequence would be this: >> encoders MUST not use newlines in their JSON text encodings and MUST >> follow each JSON text with a newline. > > +1, and if there is any point in writing this up, we should only write up this most interoperable variant. Alright, I'll submit an I-D tonight. As for MIME types, for all those apps that expose JSON HTTP APIs but which also deal in HTML, using a client's Accept (and Content-Type) header to distinguish formats... we'll need a MIME type for JSON text sequences. Nico -- From nobody Fri Mar 14 10:24:46 2014 Return-Path: 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 427611A0191 for ; Fri, 14 Mar 2014 10:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.148 X-Spam-Level: X-Spam-Status: No, score=-14.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 aJum1Dx919ye for ; Fri, 14 Mar 2014 10:24:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 196861A018E for ; Fri, 14 Mar 2014 10:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4627; q=dns/txt; s=iport; t=1394817873; x=1396027473; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Sa7sUEhtH00vJ4gmjRE6/VUi0+Reoll1gppGp49/3Bk=; b=nJzg/N/uDROnk1jgravu1J3/tUy6Fa7TlWEmD8gphoXB0BJXwmwQjuOy NgEpkeC7N4ntvOpfa5PZeL2WR3sCWnA7BsaeCfHlzsQkBwCLaAGUEisuX 3aRpdCQqQ231R+eDXfkhRa4EifZqJyUJnPvs3NulGzF6YnGMTaysN9QYk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMJAMc6I1OtJXG9/2dsb2JhbABZDoJ4O1eDBqVrBJh9gRkWdIIlAQEBAwEjDwFFBgsLGAICBRYLAgIJAwIBAgFFBgEMBgIBARCHXQixW6I5F4EpjQs6gm+BSQEDiVGOdJIugm5eggw X-IronPort-AV: E=Sophos;i="4.97,656,1389744000"; d="scan'208";a="310391130" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 14 Mar 2014 17:24:33 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2EHOWqV028243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 17:24:32 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.33) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 14 Mar 2014 12:24:32 -0500 Message-ID: <53233B4F.3060108@cisco.com> Date: Fri, 14 Mar 2014 11:24:31 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "json@ietf.org" References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> In-Reply-To: <5322714F.6080508@it.aoyama.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.33] Archived-At: http://mailarchive.ietf.org/arch/msg/json/3aYBLyT8C1977yRVT7XRJWfdXHg Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:24:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 /me still wears no hat ... On 3/13/14, 9:02 PM, "Martin J. Dürst" wrote: > Hello Matt, > > On 2014/03/14 07:23, Matt Miller wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 3/13/14, 3:23 PM, Larry Masinter wrote: >>> I wonder if there is any lesson from XMPP-- which wanted >>> sequence-of-XML-values in an indefinite length stream -- that >>> would apply to JSON. What would XMPP look like if it were >>> redone in JSON instead of XML? >>> >> >> /me exchanges JSON chair hat for XMPP enthusiast hat ... >> >> If XMPP didn't exist and we instead did JMPP, it might be a >> series of discrete objects. However, the direction of the later >> "XMPP over " adaptations (e.g., [BOSH] and [XMPP-WS]) speak >> toward wanting to use an existing transport that provides >> block-oriented framing around complete structures. >> >> Dealing with partial XML-like structures in XMPP has ranged from >> inconvenient to impractical because the vast majority of existing >> XML software has assumed a whole XML document when parsing >> starts. There are few libraries that truly allow one to feed XML >> in fits and starts and get timely output without some amount of >> modification or preprocessing. When the XMPP community took >> efforts to apply XMPP over other transports, the direction has so >> far leaned toward the whole documents that most implementations >> expect; even though the preprocessing required is rather small, >> the ability to re-use existing implementations without first >> considering oft-unpublished details was a very powerful >> motivator. > > This is very valuable feedback. > > As far as I understand, the problem for XMPP has at least two > parts: 1) The XML document arrives in pieces. 2) Parsing is done in > pieces > > My understanding is that parsing in pieces is well covered by SAX > parsers, so that the problems essentially came from 1). But problem > 1) doesn't apply to JSON text sequences exchanged as MIME types, > and it doesn't apply to log files as these are rarely read, and > when read, that could just be done with something like >> echo ']' > json-array-close.txt cat logfile.json >> json-array-close.txt | json-parse > (using [pseudo-]shell syntax). > There exists a number of SAX parsers that will not emit events until they have consumed a certain amount of input or a complete XML document, whichever is first. The most notable that comes to mind is in .NET, but I've also encountered some implementations in Java that behave this way. There are also a number of platforms where a whole-document XML parser is available "built-in" but a SAX parser requires additional modules/libraries/etc (or don't even exist). JSON is it's own thing, but my experience and observation shows to me it's not that much different than the journey XML followed. > As for delayed exchange of multiple JSON texts, e.g. a (completely > hypothetical) JMPP (JSON Messaging and Presence Protocol), one > would try to use a message-oriented transport (e.g. WebSockets) and > then not need a concept of JSON text sequences at all. > The XMPP community started with things that mimicked the "raw TCP" model, but moved to better take advantage of the underlying transports message-framing, and not deal with sequences at all. Whenever the bi-annual discussion on "Jabber™ 2.0" or "XMPP 2.0" comes up, the major discussion is about framing, so we don't repeat our mistakes of the past. The next incursion could very well focus on WebSocket for that framing. At this point, I personally just don't see a lot of value in having a media type for JSON text sequences. I wonder how often a "Content-Type: application/json-sequence" (or whatever is agreed to) will actually be encountered over the wire. Others mile may vary, I suppose. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTIztPAAoJEDWi+S0W7cO1t1kIAKqB4FJ09zCn8cZv5khKUV1X QiH//DwOuxm13RdAHlekhbvZ/DADsppzJr/U83iGVt4S5qJMq5lXdy0GK0PzSMlm 6k46ZQHsNyiLAN4cHqKLGusJ/AJ4zQGuHjL8KA0DNWseQ7zD6p+W6vHx1tEOa3c2 PN0zHQF0M/iuz/7RN7KlIhgaw8s483PSLy3McktshQ2deEbm95iItSriCpKOVhhQ 9VplZ0FTYUg08dWcWZQ5k9fnKzmLc0T8hg4sgxE7yyCfpTI8C6Y4RdXdoqy7MEss vdAbaUhPbf/YiSRSheqQlzbOQDph2+0SFrslwybJPjlKXjUu2inRNqzmNDWQStg= =TjoE -----END PGP SIGNATURE----- From nobody Fri Mar 14 12:31:08 2014 Return-Path: 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 944DE1A01A0 for ; Fri, 14 Mar 2014 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hr0r1KJwonOX for ; Fri, 14 Mar 2014 12:30:58 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C61A00A9 for ; Fri, 14 Mar 2014 12:30:57 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n15so1086490wiw.1 for ; Fri, 14 Mar 2014 12:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gMpNHiYnEuxKALjACeb+YZGy6uLHBnBpvjW4grunFAI=; b=T/fzRp5W64vhnQ6t5EyBPQODoQIBbHfcNb3GhK9Yb6yWxpBtXbopf6amr72J/X5JnH +KLeYU8o1wyC0GdPIGDXFhUNX0RTxB2n39wVBH8jABf9ciRD41T2a17fk1hRqCffzir1 Lrg1hkNU6OCYZtJATnBfxJ23Ir/7LmsxAK0QKkH00byTMVtG4+WrMIcDU23B1uCS2DUb Q5CdaXk0Xw86V8sPSYStVJ3HUEGaRAQ4xty7fyv7v3chqV1vqhXJMjo0UhWx3Pak8BFg MIGHMMG52GxfgHBI0dHadLPd6JbWkQ2GJ6AzurGlqscO4qFiHiabcsdUoRrFeLOX1ODF to8A== MIME-Version: 1.0 X-Received: by 10.194.21.193 with SMTP id x1mr7879119wje.33.1394825450353; Fri, 14 Mar 2014 12:30:50 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Fri, 14 Mar 2014 12:30:50 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 19:30:50 +0000 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b5d56107dfa5304f4961bec Archived-At: http://mailarchive.ietf.org/arch/msg/json/thCdBYPWzLYtqtuOGkxt1JSlwfY Cc: Matt Miller , "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 19:31:06 -0000 --047d7b5d56107dfa5304f4961bec Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams wrote: > The most interoperable form of JSON text sequence would be this: > encoders MUST not use newlines in their JSON text encodings and MUST > follow each JSON text with a newline. > And presumably this would include all linefeeds that JSON specification supports? (\r, \n and \r\n). -+ Tatu +- --047d7b5d56107dfa5304f4961bec Content-Type: text/html; charset=ISO-8859-1
On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams <nico@cryptonector.com> wrote:
The most interoperable form of JSON text sequence would be this:
encoders MUST not use newlines in their JSON text encodings and MUST
follow each JSON text with a newline.

And presumably this would include all linefeeds that JSON specification supports? (\r, \n and \r\n).

-+ Tatu +-

--047d7b5d56107dfa5304f4961bec-- From nobody Fri Mar 14 15:39:13 2014 Return-Path: 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 EB2B91A0208 for ; Fri, 14 Mar 2014 15:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 Vnt3BaAcVDYr for ; Fri, 14 Mar 2014 15:39:09 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE71A01FE for ; Fri, 14 Mar 2014 15:39:09 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id rl12so3314807iec.4 for ; Fri, 14 Mar 2014 15:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pPfC1EJHHtR6q8Ea+RSd6YzPSs5sXW6KeM6M/vTwmHw=; b=wOZKKnRPlZqbPxReQTNdkv/NBizZIrgGV1ulbxykhK4LQLuoz/kf0REtYz3kigu2zF 0W7j2I9U1bRNZmRFxxjxeLwmHNYGrCOfkybTr1QQZEhDxodoTdThiUfS4unJTPhv3dt/ KRWRnTVAPAj+97jVafNUwRBniLB/M+RZmOaDtA8MP9VzVfssXEDhAKPsH+2HZSWXs9L+ 5iJuElA4rcmrtTu20RwVxxD8p/hSFdl7FhIowV067UvbrgJhmyZBB6SfdExOFDpS2gKe yVvkTMbHd9QLzjb1M5b/pA5t4FsiCq7HSew+ZzXUjxFHeQBKh9MFF7oz2KCFGy+V9e1U 5cTw== X-Received: by 10.43.138.8 with SMTP id iq8mr8814666icc.37.1394836741948; Fri, 14 Mar 2014 15:39:01 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.64.9.180 with HTTP; Fri, 14 Mar 2014 15:38:24 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> From: Jacob Davies Date: Fri, 14 Mar 2014 15:38:24 -0700 X-Google-Sender-Auth: Ev-JCmn4lhACoCTYvvlNrM4cnTg Message-ID: To: Tatu Saloranta Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ZceS3Uo2F4HQagihEkXiKxwbsbE Cc: Nico Williams , "json@ietf.org" , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 22:39:12 -0000 Requiring that the separator be newline and that the JSON be serialized without embedded newlines is convenient but seems like an awkward way to handle splittable sequences when there are other characters that are not permitted to appear in JSON texts that could be used with unmodified existing JSON emitters. For instance, form feed (ASCII 12) or record separator (ASCII 30). Yes, newline has the advantage of letting you use an existing read-line facility, but having to explain "A JSON sequence is a sequence of JSON texts - but they're special JSON texts with no newlines! - separated by newlines" seems pretty awkward. I can see how it would be convenient in some cases, but I think it's better for higher-level structures built on lower-level ones not to make special requirements of the latter. JSON has always allowed newlines. On Fri, Mar 14, 2014 at 12:30 PM, Tatu Saloranta wrote: > On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams > wrote: >> >> The most interoperable form of JSON text sequence would be this: >> encoders MUST not use newlines in their JSON text encodings and MUST >> follow each JSON text with a newline. > > > And presumably this would include all linefeeds that JSON specification > supports? (\r, \n and \r\n). > > -+ Tatu +- > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Fri Mar 14 15:50:45 2014 Return-Path: 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 978801A01F5 for ; Fri, 14 Mar 2014 15:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 cTQimALea1H2 for ; Fri, 14 Mar 2014 15:50:42 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id 703DC1A0212 for ; Fri, 14 Mar 2014 15:50:42 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 919CB598060 for ; Fri, 14 Mar 2014 15:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=laR8Gz6xgw9Wym75xwZk oo5/3s8=; b=G7M3MZL5KDJkUQ21NKBOpOUga6RASNe8mzioUmDfPEM8C7JTPEA5 LsC1RZyYtsI6llag2b99Gd70V6i3hOJFOyD6VfwbtMJI7pp/EdwNIgUwH+53hCM/ VIPZi6X8UsnWiGPW9L3HecaXdibjLoYzaN6fn95RiR9Sguv3FqsFZwo= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 4394E59805F for ; Fri, 14 Mar 2014 15:50:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so152790wiv.13 for ; Fri, 14 Mar 2014 15:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mMscLdCOaoYWYtw7SWEcRMuiL2bQIn00mhvk7UKndR4=; b=Haz2UyLt02yE2+QdrxA9FATIbBfbgrykjHy3QcRWlcIc5f015+DjEXSCyjNXPx55wp Nl02Jc87N2A2/jXlv9yODIjCCV1dVjkUMiP93UVT/4EWG2kUgCu1C/gPidDBEhYN6GwS /hBmL6TdUSaGVvS/mDwlobpJlQomhhaa1J6BmLUdHWo+uF96JlOVm6EPe0D/u3dNO5wc uWVmoL4QHjJONGK5kiAucB5TZFmJoh0KRbBMzyTBWnklU1zobHGxpOlOFio2pI7CkO/0 qLc1vLuRJXL5M7nvXvreG84MwEpB93zhPi+IlmUBaatEvZP5oWOfm5o3Kv9gyppQ9B6R rH+w== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr249548wib.39.1394837434117; Fri, 14 Mar 2014 15:50:34 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 15:50:34 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> Date: Fri, 14 Mar 2014 17:50:34 -0500 Message-ID: From: Nico Williams To: Jacob Davies Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Wa5L5j_YshvH0X3OafrPCq8IyR4 Cc: "json@ietf.org" , Tatu Saloranta , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 22:50:43 -0000 On Fri, Mar 14, 2014 at 5:38 PM, Jacob Davies wrote: > Requiring that the separator be newline and that the JSON be > serialized without embedded newlines is convenient but seems like an > awkward way to handle splittable sequences when there are other > characters that are not permitted to appear in JSON texts that could > be used with unmodified existing JSON emitters. For instance, form > feed (ASCII 12) or record separator (ASCII 30). Yes, newline has the > advantage of letting you use an existing read-line facility, but > having to explain "A JSON sequence is a sequence of JSON texts - but > they're special JSON texts with no newlines! - separated by newlines" > seems pretty awkward. > > I can see how it would be convenient in some cases, but I think it's > better for higher-level structures built on lower-level ones not to > make special requirements of the latter. JSON has always allowed > newlines. If we can assume incremental JSON parsers then there's no need to say that the separator may not appear in the JSON texts. However, we probably shouldn't assume incremental parsers. And, conveniently, every encoder I've ever seen has an option for emitting compact texts which includes not emitting newlines. Awkward it may be, but it's handy in two ways: 1) the dumbest parsers can handle it with no efficiency penalty, 2) sending compact texts saves bandwidth. jq, for example, has an incremental parser, so it can handle texts that have embedded newlines just fine. And it has an option to emit compact texts. It has no option for alternative text separators on the encoder side, but it does accept any JSON whitespace as text separators on the parser side and does not require a separator when it's not required to disambiguate texts (i.e., it accepts '[][]' as a sequence of two empty arrays). I think allowing implementation with the dumbest parsers is a debatable goal. If we don't have it, instead requiring incremental (or better) parsers, then we don't need to forbid newlines in texts, we can say any whitespace works as a text separator, and we can say that the separator may be omitted in some cases. Let's debate that possible goal: do we need to permit implementation of JSON text sequence parsing with non-incremental JSON parsers? I don't have a strong opinion on that. It'd certainly be most convenient to require at least incremental JSON text parsing capabilities, and it'd be less awkward. Nico -- From nobody Fri Mar 14 16:02:24 2014 Return-Path: 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 2728F1A01FE for ; Fri, 14 Mar 2014 16:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001] autolearn=no 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 NhrhMtWlLn9w for ; Fri, 14 Mar 2014 16:02:19 -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 616841A01F5 for ; Fri, 14 Mar 2014 16:02:19 -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.5/8.14.5) with ESMTP id s2EN1x1X012132; Sat, 15 Mar 2014 00:01:59 +0100 (CET) Received: from [192.168.217.140] (p54890704.dip0.t-ipconnect.de [84.137.7.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 27E5432A; Sat, 15 Mar 2014 00:01:59 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-4853ACD3-0F1A-4A77-8707-5E2986595686 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D167) In-Reply-To: Date: Sat, 15 Mar 2014 00:01:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> To: Tatu Saloranta Archived-At: http://mailarchive.ietf.org/arch/msg/json/vDrqvBOcxSLOUSs6oCPRXUZ42m4 Cc: Nico Williams , "json@ietf.org" , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:02:21 -0000 --Apple-Mail-4853ACD3-0F1A-4A77-8707-5E2986595686 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 14.03.2014, at 20:30, Tatu Saloranta wrote: >=20 >> On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams wr= ote: >> The most interoperable form of JSON text sequence would be this: >> encoders MUST not use newlines in their JSON text encodings and MUST >> follow each JSON text with a newline. >=20 > And presumably this would include all linefeeds that JSON specification su= pports? (\r, \n and \r\n). >=20 I hope not. \r newlines no longer exist in the real world. \r\n on the other hand is just a special case of \n, a sane parser can then j= ust key on \n. Gr=C3=BC=C3=9Fe, Carsten=20= --Apple-Mail-4853ACD3-0F1A-4A77-8707-5E2986595686 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 14.03.2014, at 2= 0:30, Tatu Saloranta <tsaloranta@= gmail.com> wrote:

On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams <nico@cryp= tonector.com> wrote:
The most interoperable form of JSON text seque= nce would be this:
encoders MUST not use newlines in their JSON text encodings and MUST
follow each JSON text with a newline.

And presumably this w= ould include all linefeeds that JSON specification supports? (\r, \n and \r\= n).
<= br>

I hope not.

\r newli= nes no longer exist in the real world.
\r\n on the other hand is j= ust a special case of \n, a sane parser can then just key on \n.
<= br>
Gr=C3=BC=C3=9Fe, Carsten 
= --Apple-Mail-4853ACD3-0F1A-4A77-8707-5E2986595686-- From nobody Fri Mar 14 16:21:03 2014 Return-Path: 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 760521A0212 for ; Fri, 14 Mar 2014 16:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 RMZ-GahIQdvU for ; Fri, 14 Mar 2014 16:20:58 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 61A5E1A0209 for ; Fri, 14 Mar 2014 16:20:58 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ik5so3594644vcb.28 for ; Fri, 14 Mar 2014 16:20:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LDv+60yuv883uVsZTWYkH7VneA/8VtDyanIwV3daKO0=; b=Yscf4Cen1SHqLbhx7LH6UEVw/cKAGJb7TAAzOdy4OUVb+2mebtqt5l8qCZ8hv9iwMQ mtjzJYB6woPrC8zyopk5KiHWmA1rR+mT6c/QLjeIX2cdv2FqR8iL68HZJ8KFJ8qmTi9M bG7JAs1sxutzXxB52CZ4JxXbEslbf07tCQOjLlcqmaCinvciDGqjNX5TPJ893VpCbSzN zbAZ05NvJjSr5a8l7QVjcODFe0SynhT4IeIwyvy2yYrxEcfhBd8nJ2u02imjnbVjLkMz CDK4wvM69dGl/oBVeThNJjCx00RUA7l2dj5WVo/83iZqnSOU/HxuTDOtajkc7x/D9vrb ba3Q== X-Gm-Message-State: ALoCoQl4WWnmgQAE+ORcnLQt2qn10UwIAmwrVDTZX3buDtKfoI5/Di+SiwDb5jZM5cEdDgC8sAwT MIME-Version: 1.0 X-Received: by 10.220.250.203 with SMTP id mp11mr8543726vcb.2.1394839251209; Fri, 14 Mar 2014 16:20:51 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Fri, 14 Mar 2014 16:20:51 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> Date: Fri, 14 Mar 2014 16:20:51 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013d05021665a704f49952ab Archived-At: http://mailarchive.ietf.org/arch/msg/json/jkIDHwPXUpnTQyi1GfQQxCkC_7g Cc: Nico Williams , Matt Miller , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:21:00 -0000 --089e013d05021665a704f49952ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m strongly negative about requiring people to avoid newlines in t= heir JSON in order to be able to string chunks of JSON together into a stream. JSON is unambiguously and easily parsable. To talk in abnf, I don=E2=80= =99t think we should be satisfied with anything less than this: JSON-sequence =3D JSON-text *(text-separator JSON-text) text-separator =3D 1*( %x20 / %x09 / %x0A / %x0D ) On Fri, Mar 14, 2014 at 4:01 PM, Carsten Bormann wrote: > > > On 14.03.2014, at 20:30, Tatu Saloranta wrote: > > On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams wro= te: > >> The most interoperable form of JSON text sequence would be this: >> encoders MUST not use newlines in their JSON text encodings and MUST >> follow each JSON text with a newline. >> > > And presumably this would include all linefeeds that JSON specification > supports? (\r, \n and \r\n). > > > > I hope not. > > \r newlines no longer exist in the real world. > \r\n on the other hand is just a special case of \n, a sane parser can > then just key on \n. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --089e013d05021665a704f49952ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= =E2=80=99m strongly negative about requiring people to avoid newlines in th= eir JSON in order to be able to string chunks of JSON together into a strea= m. =C2=A0JSON is unambiguously and easily parsable. =C2=A0To talk in abnf, = I don=E2=80=99t think we should be satisfied with anything less than this:<= /div>

JSON-sequence =3D JSON-text *(= text-separator JSON-text)
text-separator =3D 1*( =C2=A0%x20 / %x09 / %x0A / %x0D )



On Fri, Mar 14, 2014 at 4:01 P= M, Carsten Bormann <cabo@tzi.org> wrote:


On 14.03.2014, at 20:30, Tatu Saloranta <tsaloranta@gmail.com>= ; wrote:

On Fri, Mar = 14, 2014 at 4:37 PM, Nico Williams <nico@cryptonector.com> wrote:
The most interoperable form of JSON text seq= uence would be this:
encoders MUST not use newlines in their JSON text encodings and MUST
follow each JSON text with a newline.

And presumably this= would include all linefeeds that JSON specification supports? (\r, \n and = \r\n).


I hope not.

\r newlines no longer exist in the real world.
\r\n on the = other hand is just a special case of \n, a sane parser can then just key on= \n.

Gr=C3=BC=C3=9Fe, Carsten=C2=A0

_________= ______________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--089e013d05021665a704f49952ab-- From nobody Fri Mar 14 16:22:21 2014 Return-Path: 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 99C141A0214 for ; Fri, 14 Mar 2014 16:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 rRDso1DeQI2o for ; Fri, 14 Mar 2014 16:22:18 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id EE2BA1A0213 for ; Fri, 14 Mar 2014 16:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=593; q=dns/txt; s=iport; t=1394839331; x=1396048931; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pVcDiwlYRN1wJIjYQqpE/D5xR4MC+oWvuxiLWbUFjQA=; b=Sx/Z/gEsDEaptkSah4fE2Yecqc1Ja8QvsFjiK+eHvZKxlmO/peSZf/JH lX9wdnJqqiX/4GC47AnJRL7fwRPO9d4r8gw0geGGZFwQ/Rk9tYOyqL+nS 1+eqtdXpYjQI9Qd9MnXz9+6WJnkC3JVf4JEa53egHPdampHtPC3jWOaJM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUJAKqOI1OtJV2d/2dsb2JhbABZgwY7V6h4BJoRFnSCSVs9FhgDAgECAUsNCAEBh3UNojGxfReOE4UTBIkZOI50gTKQfINMggw X-IronPort-AV: E=Sophos;i="4.97,657,1389744000"; d="scan'208";a="27635953" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 14 Mar 2014 23:22:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2ENMAuX002933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Mar 2014 23:22:10 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.33) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 14 Mar 2014 18:22:10 -0500 Message-ID: <53238F21.2030508@cisco.com> Date: Fri, 14 Mar 2014 17:22:09 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.33] Archived-At: http://mailarchive.ietf.org/arch/msg/json/80btI1DWbAwDX7-yqeK4xiEAzI8 Subject: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:22:19 -0000 The chairs are seeking comment on whether we should adopt I-JSON (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our charter. Remember that adopting this draft does not mean it is done; changes can happen based on the consensus of the WG. Note that the current draft does *not* have the new MIME type nor the reserved field name that was heavily debated in London; that could be added later if there is WG consensus to do so. Please speak up whether or not you believe our charter should be amended to include this work item. --Paul Hoffman and Matt Miller From nobody Fri Mar 14 16:22:38 2014 Return-Path: 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 7A9421A021C for ; Fri, 14 Mar 2014 16:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 3oSTF7_szfgM for ; Fri, 14 Mar 2014 16:22:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 603B21A021B for ; Fri, 14 Mar 2014 16:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=759; q=dns/txt; s=iport; t=1394839343; x=1396048943; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=c2DQi/9Y3S+B6N7pS9KNRaXvynYaqgxdmMvTQ7a7B18=; b=l1c8xSLMSzkpht9pji1UY2ZoE4YZWuRCphG97CfFNDsQr0M62wBxjicY KM83ranBFRb349kZFuL8uyv//N0xw1LEq44bGXWZcz2JHOkcwubFfPgXp afKN6B6pV26Afq6IacXLvPiodHJzdUV4cjFfQDgmY8c8/KAvjnRyMIUrs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAKqOI1OtJV2c/2dsb2JhbABZgwaBEsFvgR4WdIJJWz0WGAMCAQIBSw0IAQGHdaI+sX0XkyYBA4kZOI50ki6Bb4Fdggw X-IronPort-AV: E=Sophos;i="4.97,657,1389744000"; d="scan'208";a="27646708" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 14 Mar 2014 23:22:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2ENMNTE003401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Mar 2014 23:22:23 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.33) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 14 Mar 2014 18:22:23 -0500 Message-ID: <53238F2E.5010105@cisco.com> Date: Fri, 14 Mar 2014 17:22:22 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.33] Archived-At: http://mailarchive.ietf.org/arch/msg/json/VuO9xbuj5MqF7ndxbQ3KTqK4fss Subject: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:22:37 -0000 The chairs are seeking comment on whether or not the WG wants to adopt one or more nomenclature / schema / description documents in the WG charter. A few such documents have been brought to the WG, but our initial take is that the WG doesn't want to make any of them WG documents. They could proceed towards becoming RFCs without any interaction from the WG, depending on the wishes of the ADs and/or the Independent Stream Editor. Once a nomenclature document is an RFC, other RFCs could use it to describe the JSON in those later RFCs. Please speak up whether or not you believe our charter should be amended to include a work item that would adopt one or more nomenclature / schema / description documents. --Paul Hoffman and Matt Miller From nobody Fri Mar 14 16:24:39 2014 Return-Path: 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 95B8C1A0212 for ; Fri, 14 Mar 2014 16:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9kfq-Vrt-yZ8 for ; Fri, 14 Mar 2014 16:24:36 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F41A0203 for ; Fri, 14 Mar 2014 16:24:36 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so3398034veb.22 for ; Fri, 14 Mar 2014 16:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=64hO0fRVcxfSAPLG90mlH/4X3F+lcfbX1ZtUUZHaLx0=; b=W6aK7/Qau+VLxI71wb1oNlqua1/eMHme0bSqEG2xXAVzwQ1O0i73jVr9V8DOHH5IQS BF46MayKViEyCntiKMrjf2JMoz6/crdf4WCUyJCFbzDdPaKvR/qIR9xcKPHiJUJQXmYw KWgh1L0zSR4wGvfsl80dtowwiN4cNawA94RsPI8tr2ClPMR9QZuRdvue20qhaDQH5aYK vcell/HFxAxbl9kf4oqv/DgZh/RIQfYPOm3Lf7czSCCkNYq3jLS4Big0IHV4LL5Vl4fD ayvUVJdGJ4pbL9U0LTSbZ6XnjjbhBYYlaOu9jddu52ZHlVVPV91sBrXSOwPbtMa4uXs1 EgQA== X-Gm-Message-State: ALoCoQlKfBiS2Wq80guQND5384nSBr9NRFFe0CinR+f8UOBIPlbGUlw9YKW2CrTLYutdB53jOqxc MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr8713820vcb.0.1394839469628; Fri, 14 Mar 2014 16:24:29 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Fri, 14 Mar 2014 16:24:29 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <53238F21.2030508@cisco.com> References: <53238F21.2030508@cisco.com> Date: Fri, 14 Mar 2014 16:24:29 -0700 Message-ID: From: Tim Bray To: Matt Miller Content-Type: multipart/alternative; boundary=001a11339ae41b33bc04f4995f31 Archived-At: http://mailarchive.ietf.org/arch/msg/json/JoQ9GetacL-WweW1Qd5PqLO-cEI Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:24:38 -0000 --001a11339ae41b33bc04f4995f31 Content-Type: text/plain; charset=UTF-8 (unsurprisingly) +1 On Fri, Mar 14, 2014 at 4:22 PM, Matt Miller wrote: > The chairs are seeking comment on whether we should adopt I-JSON > (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our > charter. Remember that adopting this draft does not mean it is done; > changes can happen based on the consensus of the WG. > > Note that the current draft does *not* have the new MIME type nor the > reserved field name that was heavily debated in London; that could be > added later if there is WG consensus to do so. > > Please speak up whether or not you believe our charter should be amended > to include this work item. > > > --Paul Hoffman and Matt Miller > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11339ae41b33bc04f4995f31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(un= surprisingly) +1


On Fri, Mar 14, 2014 at 4:22 PM, Matt Miller <mamille2@c= isco.com> wrote:
The chairs are seeking comment on whether we= should adopt I-JSON
(http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in ou= r
charter. Remember that adopting this draft does not mean it is done;
changes can happen based on the consensus of the WG.

Note that the current draft does *not* have the new MIME type nor the
reserved field name that was heavily debated in London; that could be
added later if there is WG consensus to do so.

Please speak up whether or not you believe our charter should be amended to include this work item.


--Paul Hoffman and Matt Miller

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11339ae41b33bc04f4995f31-- From nobody Fri Mar 14 16:27:57 2014 Return-Path: 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 374201A020F for ; Fri, 14 Mar 2014 16:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 PfT7mmPHDS-d for ; Fri, 14 Mar 2014 16:27:54 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 365011A0203 for ; Fri, 14 Mar 2014 16:27:54 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so3440600veb.38 for ; Fri, 14 Mar 2014 16:27:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8zJZ65fdMbBZns8xPu/6Z+BtQqv2C5sprZRiR1ZLwMI=; b=bWHk9mF68jcNvrguUj0FDbAn/ZfkeETrh62hhip+9mECu4IrW3uBZSELziG5qgSUBq O5yrFYwzFFqr3TdgrkLlc6QHfqJc49HLHH2acOOHLpOxPI7qUzWsy6u+jbAXLKc2k0rY IocDXR1gbkUxr/0W94eSKkdAF2QPjtsx2qj7Y2nmHs0jk+tQBHrh9EDMyVnSwm66G6Ow 0GjPxakEiu5NNLlkIWUK4h68G97KZdRutg1a1rduRhDcRy68yTcGRQMN2tHid2kF/ig4 /+3EcRnbJoI9Vw+UkbiuUM3/tlSDVbDvtvy3sH6xkObgPlUgUkEdLaqh8evYN/HTSEOy hGvQ== X-Gm-Message-State: ALoCoQk++p+jEoJwv4BQwB6x2dBX2t703TR4z3e6W8IybEP/VMuoE/lOYDwZc34Nf7XoRadtKSkn MIME-Version: 1.0 X-Received: by 10.58.229.167 with SMTP id sr7mr8383011vec.7.1394839666990; Fri, 14 Mar 2014 16:27:46 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Fri, 14 Mar 2014 16:27:46 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <53238F2E.5010105@cisco.com> References: <53238F2E.5010105@cisco.com> Date: Fri, 14 Mar 2014 16:27:46 -0700 Message-ID: From: Tim Bray To: Matt Miller Content-Type: multipart/alternative; boundary=047d7bd6b46adeb72404f4996af4 Archived-At: http://mailarchive.ietf.org/arch/msg/json/-RicQklu0MUOP01MC6_KJkkmuEI Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:27:56 -0000 --047d7bd6b46adeb72404f4996af4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m generally opposed to this work item on the basis that nobody ha= s provided an example of an existing RFC that would clearly be improved by the availability of such a thing. On Fri, Mar 14, 2014 at 4:22 PM, Matt Miller wrote: > The chairs are seeking comment on whether or not the WG wants to adopt > one or more nomenclature / schema / description documents in the WG > charter. A few such documents have been brought to the WG, but our > initial take is that the WG doesn't want to make any of them WG > documents. They could proceed towards becoming RFCs without any > interaction from the WG, depending on the wishes of the ADs and/or the > Independent Stream Editor. Once a nomenclature document is an RFC, other > RFCs could use it to describe the JSON in those later RFCs. > > Please speak up whether or not you believe our charter should be amended > to include a work item that would adopt one or more nomenclature / > schema / description documents. > > > --Paul Hoffman and Matt Miller > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7bd6b46adeb72404f4996af4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= =E2=80=99m generally opposed to this work item on the basis that nobody has= provided an example of an existing RFC that would clearly be improved by t= he availability of such a thing.


On Fri,= Mar 14, 2014 at 4:22 PM, Matt Miller <mamille2@cisco.com> = wrote:
The chairs are seeking comment on whether or= not the WG wants to adopt
one or more nomenclature / schema / description documents in the WG
charter. A few such documents have been brought to the WG, but our
initial take is that the WG doesn't want to make any of them WG
documents. They could proceed towards becoming RFCs without any
interaction from the WG, depending on the wishes of the ADs and/or the
Independent Stream Editor. Once a nomenclature document is an RFC, other RFCs could use it to describe the JSON in those later RFCs.

Please speak up whether or not you believe our charter should be amended to include a work item that would adopt one or more nomenclature /
schema / description documents.


--Paul Hoffman and Matt Miller

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7bd6b46adeb72404f4996af4-- From nobody Fri Mar 14 16:31:34 2014 Return-Path: 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 A65201A0203 for ; Fri, 14 Mar 2014 16:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 ZYvNQwJawJ7d for ; Fri, 14 Mar 2014 16:31:26 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DA2BD1A01CE for ; Fri, 14 Mar 2014 16:31:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WObZN-00010h-1q; Fri, 14 Mar 2014 19:31:17 -0400 Date: Fri, 14 Mar 2014 19:31:17 -0400 From: John Cowan To: Matt Miller Message-ID: <20140314233116.GD5053@mercury.ccil.org> References: <53238F21.2030508@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53238F21.2030508@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/4__9cW0xqb-ZR_UWaOhCynv2YUQ Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:31:27 -0000 Matt Miller scripsit: > Please speak up whether or not you believe our charter should be amended > to include this work item. +1 -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan From nobody Fri Mar 14 16:32:43 2014 Return-Path: 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 E3B191A0212 for ; Fri, 14 Mar 2014 16:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 IFd1Y5lmT57v for ; Fri, 14 Mar 2014 16:32:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C15391A01CE for ; Fri, 14 Mar 2014 16:32:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WObaP-000171-Cr; Fri, 14 Mar 2014 19:32:21 -0400 Date: Fri, 14 Mar 2014 19:32:21 -0400 From: John Cowan To: Tim Bray Message-ID: <20140314233221.GE5053@mercury.ccil.org> References: <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/Yz8Gs9fmcaCzvGNFjgrflZfARoE Cc: Nico Williams , Carsten Bormann , "json@ietf.org" , Tatu Saloranta , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:32:38 -0000 Tim Bray scripsit: > JSON is unambiguously and easily parsable. To talk in abnf, I don’t think > we should be satisfied with anything less than this: > > JSON-sequence = JSON-text *(text-separator JSON-text) > text-separator = 1*( %x20 / %x09 / %x0A / %x0D ) Emphatic +1. -- La mayyitan ma qadirun yatabaqqa sarmadi John Cowan Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi. cowan@ccil.org --Abdullah al-Hazred, Al-`Azif http://www.ccil.org/~cowan From nobody Fri Mar 14 17:19:01 2014 Return-Path: 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 099AD1A0220 for ; Fri, 14 Mar 2014 17:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 isCAmC6SWlQO for ; Fri, 14 Mar 2014 17:18:58 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1CD1A012B for ; Fri, 14 Mar 2014 17:18:57 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id k15so3321409qaq.1 for ; Fri, 14 Mar 2014 17:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uoukFY9pJ2ua0prRIFK0FvYBBIhRn3B5UrLnCtaTJok=; b=XMZslcYALC0aHH3BE0ev+lh4KemTRYSQDpQy9pjjjIq2wCHPt8o9CDnKcX4sLB/aUa yY2q07xDH43loR+Hwi6yXnfZ9jUaDyuwOx5nMVxfH6rLg4vyjhFWs1ckrkxDnrmjXPM7 zgw0sMrGXYuiyaICIQv41MbH6oOxxCZRI8NaeC/gz4iGdl++s6U7EHEP/YAPi5jZCR11 mTLEZrhzi4BIIUZQ1xGkSAhpePDhXxUcy1mAyN4X7YzVPqYRAZW2f9Zlti186PlOixHp fz1CnHLQM3Bq2YwhZ0D/PeAT9CQ0w9iSk3myMRia1ZjK7jYZQRzEbGmZtdHTcK6V8se0 OVDw== MIME-Version: 1.0 X-Received: by 10.140.109.228 with SMTP id l91mr12726528qgf.72.1394842730865; Fri, 14 Mar 2014 17:18:50 -0700 (PDT) Received: by 10.140.96.107 with HTTP; Fri, 14 Mar 2014 17:18:50 -0700 (PDT) In-Reply-To: <53238F21.2030508@cisco.com> References: <53238F21.2030508@cisco.com> Date: Fri, 14 Mar 2014 20:18:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt Miller Content-Type: multipart/alternative; boundary=001a1138fa847dab0304f49a2193 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4Ml59q0_Tes5y9o_Y8sll4m8J9U Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:19:00 -0000 --001a1138fa847dab0304f49a2193 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 7:22 PM, Matt Miller wrote: > The chairs are seeking comment on whether we should adopt I-JSON > (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our > charter. Remember that adopting this draft does not mean it is done; > changes can happen based on the consensus of the WG. > > Note that the current draft does *not* have the new MIME type nor the > reserved field name that was heavily debated in London; that could be > added later if there is WG consensus to do so. > > Please speak up whether or not you believe our charter should be amended > to include this work item. > +1 -- Website: http://hallambaker.com/ --001a1138fa847dab0304f49a2193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 7:22 PM, Matt Miller <= mamille2@cisco.com<= /a>> wrote:
The chairs are seeking comment on whether we= should adopt I-JSON
(http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in ou= r
charter. Remember that adopting this draft does not mean it is done;
changes can happen based on the consensus of the WG.

Note that the current draft does *not* have the new MIME type nor the
reserved field name that was heavily debated in London; that could be
added later if there is WG consensus to do so.

Please speak up whether or not you believe our charter should be amended to include this work item.

+1

=A0
--
Website: http://hallambaker.com/
--001a1138fa847dab0304f49a2193-- From nobody Fri Mar 14 17:30:47 2014 Return-Path: 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 A149D1A012A for ; Fri, 14 Mar 2014 17:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ejKRO5AM7tLl for ; Fri, 14 Mar 2014 17:30:44 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3D1A0121 for ; Fri, 14 Mar 2014 17:30:44 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id a108so9542031qge.3 for ; Fri, 14 Mar 2014 17:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NlnkaCsreGtd8rseebFr5lWPA3Z1zaLapPcPVuj+zr8=; b=06g0BoE5i7LFiTwW2Uk+npD1/owGaUCkOJPw/YDH/N9vkWPivxfmqJhaRs9STvlu+x wYOfvPHEXp4AjaA1nabm0MrZUx46i2GrE3j82nMHpQfa5G8fPHpR0/6aCt2PTPra3aV8 iFsxqNwKinnjm0IowpjYOYez1OiZ2SWAhDHKYq8a8GhV2mGrf+a/0f4+niWgI9akpa+q D006aLaOCKtWOBb5HjQN5lW4COi/kbnxNdPbqM9QS6YmdeOmux4qpSzaY/M5n+Zis8sB 9N/UKVWGMnigXeDF1er3/l1a4ILNrQRA3u4BqExvExvv1897c9Li5SmK7oQKrm5YyWs+ WqnQ== MIME-Version: 1.0 X-Received: by 10.224.131.193 with SMTP id y1mr13284677qas.86.1394843437273; Fri, 14 Mar 2014 17:30:37 -0700 (PDT) Received: by 10.140.96.107 with HTTP; Fri, 14 Mar 2014 17:30:37 -0700 (PDT) In-Reply-To: References: <53238F2E.5010105@cisco.com> Date: Fri, 14 Mar 2014 20:30:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b676c3c98992504f49a4b18 Archived-At: http://mailarchive.ietf.org/arch/msg/json/JkwxpzXe2XgUmMOfcYh8aHf7E_U Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:30:46 -0000 --047d7b676c3c98992504f49a4b18 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 7:27 PM, Tim Bray wrote: > I'm generally opposed to this work item on the basis that nobody has > provided an example of an existing RFC that would clearly be improved by > the availability of such a thing. > I think RFC 6962 could be improved substantially with some greater adherence to some structure. Like many JSON Web services, message data is split between the message contents and the URL. More importantly, I would like to kill all the parts of the document that specify the TLS data format (using a schema) and replace them with JSON structures. But that isn't going to be possible without a better way to define structures. I don't think it is just a JSON issue though. While implementing TRANS I added support for the TLV format to the parser. I have not yet added it to any of the encoder or decoder libraries though. It is pretty clear that the proposers of CT are only interested in addressing notary services for the certificate application and so they are obsessed with size and compactness. Which is fine. But I certainly don't wish to carry that data encoding into any other notary application. So being able to write a schema that allows the data structures to be rendered in the legacy TLS encoding and in JSON becomes quite important. -- Website: http://hallambaker.com/ --047d7b676c3c98992504f49a4b18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 14, 2014 at 7:27 PM, Tim Bray <tbray@textuality.com> wrote:
I’m generally opposed to this work item on the basis that nobody = has provided an example of an existing RFC that would clearly be improved b= y the availability of such a thing.

I think RFC 6962 could be improved s= ubstantially with some greater adherence to some structure.

<= /div>
Like many JSON Web services, message data is split between the me= ssage contents and the URL.

More importantly, I would like to kill all the parts of= the document that specify the TLS data format (using a schema) and replace= them with JSON structures. But that isn't going to be possible without= a better way to define structures.

I don't think it is just a JSON issue though. While= implementing TRANS I added support for the TLV format to the parser. I hav= e not yet added it to any of the encoder or decoder libraries though.

It is pretty clear that the proposers of CT are only in= terested in addressing notary services for the certificate application and = so they are obsessed with size and compactness. Which is fine. But I certai= nly don't wish to carry that data encoding into any other notary applic= ation. So being able to write a schema that allows the data structures to b= e rendered in the legacy TLS encoding and in JSON becomes quite important.<= /div>
 

--
Website: http://hallambaker.com/
--047d7b676c3c98992504f49a4b18-- From nobody Fri Mar 14 17:32:52 2014 Return-Path: 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 CA7621A012B for ; Fri, 14 Mar 2014 17:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 E_3zm_TR69ci for ; Fri, 14 Mar 2014 17:32:49 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id D67B31A0121 for ; Fri, 14 Mar 2014 17:32:48 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id j107so9511934qga.7 for ; Fri, 14 Mar 2014 17:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3QHcmyC8302a3Sb0pIogG/trL12MAwECzf/uMtIL0g0=; b=e4x5eAmx5mO7xjnmnqNcsZund5FTGfsnrR0mheOxezu/ssk3ZQBPF8RnD3vyhrReIv oCfw5pWVZNfNLNmpna2W642x3dS7Tt37jRvA7LycFcVviYTFqoYnK5eUGr4k8L4cjyEf Sb0gPmO9ie+wT5YwNRY7p+fejUL8yWmkFdnk2eLExdAzo67cGdImjbXt/on6a43LJr1E C6DL952W+MuyFpPvzaggKGfnr/unuw0M3MNA+6wr15VRf6OFOksKUl1bHXsoEllIQbJr r3fbNmWGSmwdQgNVk85C2gdJWfuZTEOEKuTQ87w5fJ5i83OAeUKSFTjJhJTqXgq/bPB1 fypg== MIME-Version: 1.0 X-Received: by 10.229.183.200 with SMTP id ch8mr13446008qcb.17.1394843561703; Fri, 14 Mar 2014 17:32:41 -0700 (PDT) Received: by 10.140.96.107 with HTTP; Fri, 14 Mar 2014 17:32:41 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> Date: Fri, 14 Mar 2014 20:32:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=001a1133916c0344fb04f49a5311 Archived-At: http://mailarchive.ietf.org/arch/msg/json/UMs3yJ0XkkcaGsex_WD1mro_ORY Cc: Nico Williams , Carsten Bormann , "json@ietf.org" , Tatu Saloranta , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:32:51 -0000 --001a1133916c0344fb04f49a5311 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 7:20 PM, Tim Bray wrote: > I'm strongly negative about requiring people to avoid newlines in their > JSON in order to be able to string chunks of JSON together into a stream. > JSON is unambiguously and easily parsable. To talk in abnf, I don't think > we should be satisfied with anything less than this: > > JSON-sequence = JSON-text *(text-separator JSON-text) > text-separator = 1*( %x20 / %x09 / %x0A / %x0D ) > > JSON-sequence = JSON-text *(text-separator JSON-text) text-separator = 1*( %x20 / %x09 / %x0A / %x0D / %2C) -- Website: http://hallambaker.com/ --001a1133916c0344fb04f49a5311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Mar 14, 2014 at 7:20 PM, Tim Bray <tbray@textuality.com= > wrote:
I’m = strongly negative about requiring people to avoid newlines in their JSON in= order to be able to string chunks of JSON together into a stream.  JS= ON is unambiguously and easily parsable.  To talk in abnf, I don&rsquo= ;t think we should be satisfied with anything less than this:

JSO= N-sequence =3D JSON-text *(text-separator JSON-text)
text-separator =3D 1*(  %x20 / %x09 / %x0A / %x0D )


JSO= N-sequence =3D JSON-text *(text-separator JSON-text)
text-separat= or =3D 1*(  %x20 / %x09 / %x0A / %x0D / %2C)


--
Website: http://hallambaker.com/
--001a1133916c0344fb04f49a5311-- From nobody Fri Mar 14 17:50:58 2014 Return-Path: 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 B829F1A021C for ; Fri, 14 Mar 2014 17:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 frMPPFRKFkFB for ; Fri, 14 Mar 2014 17:50:51 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id F392E1A022E for ; Fri, 14 Mar 2014 17:50:30 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 2E0128CB5A for ; Fri, 14 Mar 2014 17:50:24 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id DC95021DE6F for ; Fri, 14 Mar 2014 17:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=WuRefI6K92bguw5Bxght7JkZs1s=; b=dSjBZZd+TFT fW5QZQoMtEP5LAZkwKayA5esFdfAj4LD2MwXw0i/gwJUEL2awuw5aXecJcQiUbiV uRvm4zjFVVJXPzEWN9oBIW/0jfeYjAGtXVEOH3EWhgHRjCg6AvJp1gEs6NcFhPaC YvEpjxfCYLEo/Q4Loucyr/kYMC1dwr6Y= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 7E5B221DE6A for ; Fri, 14 Mar 2014 17:50:23 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so2727126wgh.31 for ; Fri, 14 Mar 2014 17:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MsNGdqj3Q2uTZOr2g/O64K0tZPHJ0WLBhIQXuRLCZPs=; b=Cz8cfuYhcYZg+KoR0uSnK6aRoMbfTGzU770QAN5ylR9EOWnEPQnZnszRF04gK5bLm4 +WKmx9P5DAwdDwp/HvIbhXzONXP5uPggIagsnjTNHNwcdJM+yFEizmzvG5dbfS2X3zwM s36nqewdLkssyp0gKnZCbLH+LmsRpWWUINRvEwuV5O5m1NyYu9XzxwMqxdaq68F0N+sH i4iUcYx8Go6W5OJChLZ153+LV7LohduqRzBSzcc0SYaBAIij1vO9NM3Jndc82TqNXEbB EaOvvPB/CFlrRrfimHR0IM89TqMxllmg0mrsHPu+Aa8f6oU+d0Kzm9AQA6yqiEjbx4g2 AnlQ== MIME-Version: 1.0 X-Received: by 10.194.62.206 with SMTP id a14mr9267787wjs.26.1394844622183; Fri, 14 Mar 2014 17:50:22 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 17:50:22 -0700 (PDT) In-Reply-To: References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> Date: Fri, 14 Mar 2014 19:50:22 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/nzYtMAaV9A6iAqpiGeqR575lGew Cc: Tatu Saloranta , Carsten Bormann , "json@ietf.org" , Tim Bray , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:50:53 -0000 On Fri, Mar 14, 2014 at 7:32 PM, Phillip Hallam-Baker wr= ote: > On Fri, Mar 14, 2014 at 7:20 PM, Tim Bray wrote: >> >> I=E2=80=99m strongly negative about requiring people to avoid newlines i= n their >> JSON in order to be able to string chunks of JSON together into a stream= . >> JSON is unambiguously and easily parsable. To talk in abnf, I don=E2=80= =99t think >> we should be satisfied with anything less than this: >> >> JSON-sequence =3D JSON-text *(text-separator JSON-text) >> text-separator =3D 1*( %x20 / %x09 / %x0A / %x0D ) >> > > JSON-sequence =3D JSON-text *(text-separator JSON-text) > text-separator =3D 1*( %x20 / %x09 / %x0A / %x0D / %2C) It's much better to say that a separator must follow every text, since then there's no need to concern ourselves as to ambiguities. It also permits parsers to produce values for texts like 'true ' or '1 ' as soon as the separator is read rather than waiting for a separator (or EOF) that might take a while to arrive. JSON-sequence =3D *(JSON-text 1*(text-separator)) text-separator =3D %x20 / %x09 / %x0A / %x0D / %2C I see no value in adding a comma (%2C) to the above. Nico -- From nobody Fri Mar 14 17:57:07 2014 Return-Path: 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 944961A0238 for ; Fri, 14 Mar 2014 17:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 apOC2mBNXS0l for ; Fri, 14 Mar 2014 17:57:04 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (agjbgdcfdbeb.dreamhost.com [69.163.253.141]) by ietfa.amsl.com (Postfix) with ESMTP id C84E31A0227 for ; Fri, 14 Mar 2014 17:57:04 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id E74692005D108 for ; Fri, 14 Mar 2014 17:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=TOjoGUwKFWWVVCnp22tWlwgCJ9s=; b=Ya9LM1rGWrP sToXZYE77Rlf5rEE6CJWCCvx8FFB9kRhcT/JoyK/AF3e0FVbwNKvOVwYL6xWehPO LRjqVn5Sd78f1JNvA241QNOB5GbsA3f7dzTHdmJWhIR8RkB0buiS5xylmBysJH+b /e2tj4ilr0NRDxZrb1rgNcsZ5EJGHWxk= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 9CDEB2005D105 for ; Fri, 14 Mar 2014 17:56:57 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so2776114wes.14 for ; Fri, 14 Mar 2014 17:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hoFPMWV2ptkREl0yS1kD1/yqsu/C2Wox6bmpSHbCc00=; b=Nx9Hk8lviAjjbDPgTBkerg8UkHoQ7GqxYy8v7YWPSMSPBrAcXQD2LBi6yohfjNI62n F9qHGtSQB61LqHBIsrtpqYVVZs429GGmOefd6NlqMP5Cw8GYsT7fzI5jdeCghVbZEB1r 6N3SsYFzsElOlLM+OjhZQVKX7FuOenYDUQfWy6vkyvcJfm+F6PZApm5y3UamTgMFI/hp U1fozJML4tOxaLmGZLATe1m76Y+7E294KG3LuT3L6vnhsQfyYDY4gO1kHR9fYLwDAt6m dplSJqk2VY5PyfqjDYrJD3DCUAdTz8POHdoFCF3Qt/WScV1TjMO0WwGQySy6/lcA5lUx vuaQ== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr652530wib.42.1394845016534; Fri, 14 Mar 2014 17:56:56 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 17:56:56 -0700 (PDT) In-Reply-To: References: <53238F2E.5010105@cisco.com> Date: Fri, 14 Mar 2014 19:56:56 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/5sHgK9ZRsnojJ45nWepHwx6NAzE Cc: Matt Miller , Tim Bray , IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:57:05 -0000 On Fri, Mar 14, 2014 at 7:30 PM, Phillip Hallam-Baker wr= ote: > On Fri, Mar 14, 2014 at 7:27 PM, Tim Bray wrote: >> I=E2=80=99m generally opposed to this work item on the basis that nobody= has >> provided an example of an existing RFC that would clearly be improved by= the >> availability of such a thing. > > I think RFC 6962 could be improved substantially with some greater adhere= nce > to some structure. It would also benefit from JSON text sequences... From nobody Fri Mar 14 17:58:44 2014 Return-Path: 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 C6C901A0237 for ; Fri, 14 Mar 2014 17:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 xlFaBwQ8JraS for ; Fri, 14 Mar 2014 17:58:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (agjbgdcfdbgf.dreamhost.com [69.163.253.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7081A0227 for ; Fri, 14 Mar 2014 17:58:41 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id D128D5406F for ; Fri, 14 Mar 2014 17:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=BgNvFM1GqaSLzKy/iFSpo/SPNkM=; b=HA7hm1aTCoH 6ASnzkWOkKg1mh3bCAe/+bWYVF41PLj+qjKIAKjRoMxo6oYcPvUYUG+1n7CXGyHR UbbaJjVcpinxW2HNb3DAFMeu8ND4yJhqZ1diwU+SBtMcxMwE6fISyGhQeQyA50DB bdauDcjarRTFR+rbVcDsEI4ZTx+ZfXnw= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 867215405B for ; Fri, 14 Mar 2014 17:58:34 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so2709231wes.4 for ; Fri, 14 Mar 2014 17:58:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=sJgSW/Gv3NrmgZDLaiLC4rFLeLBK3pGHjWgNxDbx9ew=; b=iTO6pcck9/eDtQesIwbu77RD4u5+Ezonb4zRm8n7JCKarNyu+KmrwTqPpcGn6bYa3Q UBSUtAv2qWkZaIyRtaduqQizBjQgr5R4pCOiOaqwmij/N1pmlalHk3WdZiV10jSc+vO7 YmbUirOO598iVnqfQEEH0goygVmYaGfiXgRqOcV4NgdEYtaMMtgDj6nQ3SqPQIxqMfdB tdTWN32NOxGg9KQlIgcc85rjo77U977QQB/ctBqyjmjvddddBvPOFjYjkYYccLyo3Rkk dKdH5WlCfo6XKrQ7UQhtnj3josHrn31uq+ONpVEEdxCYvuDg7Gs3kauxVtM1exkJ6yNN Ha9g== MIME-Version: 1.0 X-Received: by 10.194.62.206 with SMTP id a14mr9288958wjs.26.1394845113542; Fri, 14 Mar 2014 17:58:33 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 17:58:33 -0700 (PDT) Date: Fri, 14 Mar 2014 19:58:33 -0500 Message-ID: From: Nico Williams To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tWwC9qQGlEm48DdFedzjsSf_lEY Subject: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:58:43 -0000 Just submitted. ---------- Forwarded message ---------- From: Date: Fri, Mar 14, 2014 at 7:57 PM Subject: New Version Notification for draft-williams-json-text-sequence-00.txt To: Nicolas Williams A new version of I-D, draft-williams-json-text-sequence-00.txt has been successfully submitted by Nicolas Williams and posted to the IETF repository. Name: draft-williams-json-text-sequence Revision: 00 Title: JavaScript Object Notation (JSON) Text Sequences Document date: 2014-03-14 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-williams-json-text-sequence-00.txt Status: https://datatracker.ietf.org/doc/draft-williams-json-text-sequence/ Htmlized: http://tools.ietf.org/html/draft-williams-json-text-sequence-00 Abstract: This document describes the JSON text sequence format and associated media type. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Mar 14 18:58:46 2014 Return-Path: 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 4E09B1A022D for ; Fri, 14 Mar 2014 18:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 gurKpQ1EYSlq for ; Fri, 14 Mar 2014 18:58:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 962D31A0229 for ; Fri, 14 Mar 2014 18:58:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2F1wU26012276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Mar 2014 18:58:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Fri, 14 Mar 2014 18:58:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> References: <53238F2E.5010105@cisco.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/x5LsgWb7kaHeSawz50zYXuSybbs Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:58:42 -0000 On Mar 14, 2014, at 5:30 PM, Phillip Hallam-Baker = wrote: > I think RFC 6962 could be improved substantially with some greater = adherence to some structure. Could you maybe take that discussion to the trans working group? It is = not relevant to this WG. Thanks! --Paul Hoffman= From nobody Fri Mar 14 18:59:54 2014 Return-Path: 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 5259B1A022D for ; Fri, 14 Mar 2014 18:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 RQRUTQNWvpH1 for ; Fri, 14 Mar 2014 18:59:50 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9B31A0229 for ; Fri, 14 Mar 2014 18:59:50 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so3504867veb.39 for ; Fri, 14 Mar 2014 18:59:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y8a0l8wAwqmOSgkY+5pBjaaEaAbk6IHeK/5wYuRdPwI=; b=i09PhcjR1Ka9quScmmsUKcRJaZDJG+i4XtVdVOnsH65t4PG38FFTUZqvfzl+VUOjJY Lz2RFcGcoSpe0jNr0EsO34PbYJcsIq+QLQlHawpesomWKM8bMN0+BOwmKZ1UDtjNayq+ pJ6NOJMQVF+41P265mpi0QTWpLDg13BkuhUzCZn+SbH7UHumjqSabzuKYrucznOB6ax+ t2h2xKPRwtgyFs7vgJ+56rVMDOtJ/MY8AvKp3KHaWFCwrov57j/K2VQ3ELk2VBRujoJJ jFNWr+LwwhEUbsBYUc+uJcA2tHciyVKjx0pJB3EBQ0iMLqxMKtkfLDLqwX3BO5wrRgIR leJw== X-Gm-Message-State: ALoCoQl+7sfzm9h7Vk3buJwMumoVtV3S8M1RjbbHKRTPYpbFGb/FWdDpT0kbU3SJuYpFTTq/eEfK MIME-Version: 1.0 X-Received: by 10.221.29.137 with SMTP id ry9mr9167334vcb.6.1394848783016; Fri, 14 Mar 2014 18:59:43 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Fri, 14 Mar 2014 18:59:42 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> Date: Fri, 14 Mar 2014 18:59:42 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1133935c3a3c5c04f49b8af2 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4dNZ9MLEgejCmgscCWRD32fnR1w Cc: Phillip Hallam-Baker , IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:59:52 -0000 --001a1133935c3a3c5c04f49b8af2 Content-Type: text/plain; charset=UTF-8 Actually, I think it is relevant. If someone were to show an example of an RFC where a hypothetical nomenclature/schema spec would have made the RFC better, that would be a really good argument in the current charter discussion. On Fri, Mar 14, 2014 at 6:58 PM, Paul Hoffman wrote: > On Mar 14, 2014, at 5:30 PM, Phillip Hallam-Baker > wrote: > > > I think RFC 6962 could be improved substantially with some greater > adherence to some structure. > > Could you maybe take that discussion to the trans working group? It is not > relevant to this WG. Thanks! > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a1133935c3a3c5c04f49b8af2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Act= ually, I think it is relevant. =C2=A0If someone were to show an example of = an RFC where a hypothetical nomenclature/schema spec would have made the RF= C better, that would be a really good argument in the current charter discu= ssion.


On Fri,= Mar 14, 2014 at 6:58 PM, Paul Hoffman <paul.hoffman@vpnc.org><= /span> wrote:
On Mar 14, 2014, at 5:30 PM,= Phillip Hallam-Baker <hallam@gmail.= com> wrote:

> I think RFC 6962 could be improved substantially with some greater adh= erence to some structure.

Could you maybe take that discussion to the trans working group? It i= s not relevant to this WG. Thanks!

--Paul Hoffman
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a1133935c3a3c5c04f49b8af2-- From nobody Fri Mar 14 19:08:40 2014 Return-Path: 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 757AA1A022D for ; Fri, 14 Mar 2014 19:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ANObNU6vin_X for ; Fri, 14 Mar 2014 19:08:35 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE811A022C for ; Fri, 14 Mar 2014 19:08:35 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so3570704vcb.24 for ; Fri, 14 Mar 2014 19:08:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+EtZwFe1iQrRif4LHG28+161Gr/KbhQfYkzORXLMHLA=; b=kxCuck1cSD2+b4SbyycBkX9nXcYZk7ygLcWUTGUD9TO7/AqvVcL+LVYhJ80h9fdaOm WXH+aj/Ladew+mpWsF5kSdmRKpw0UBLwrwMX6DXRVzWQJnNuw5Rmedasl+S5/UVawzC3 bxCPlOU1ZSLQq4VuCQQIHY2C32Pzl9vaqG6BFSJ/zzvmoUcOhlbmEc4BlpHmT1oJYJFd xyum6vuK6ybx+b0RkAHi4DtoXQukh2na5b4j1aYychNN8O2uqyBajCLb+QV989+5ICCD 2FjhQK+t88/6llt3rF1v53Udw8dyP8juSQw23V/e1vq1N/qFJ4Qf4tneWkUNP6ImQTKe 5zhw== X-Gm-Message-State: ALoCoQlDevhK4L0zrgehra/H261Ow0TCEx6Sk1W2iHzMeA0RcUz5v4SfSbQJtwVufR3xm2Yi+JMh MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr108755vcb.22.1394849307981; Fri, 14 Mar 2014 19:08:27 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Fri, 14 Mar 2014 19:08:27 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <53238F2E.5010105@cisco.com> Date: Fri, 14 Mar 2014 19:08:27 -0700 Message-ID: From: Tim Bray To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1133757684925804f49ba931 Archived-At: http://mailarchive.ietf.org/arch/msg/json/8F-NUFjnIkJK5C1rwYebcsmGqv8 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:08:37 -0000 --001a1133757684925804f49ba931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 5:30 PM, Phillip Hallam-Baker wro= te: > > =E2=80=8B=E2=80=8B > I think RFC 6962 could be improved substantially with some greater > adherence to some structure. > =E2=80=8BCould you be specific? I just glanced at 6962 and it=E2=80=99s no= t obvious. =E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B > > Like many JSON Web services, message data is split between the message > contents and the URL. > > More importantly, I would like to kill all the parts of the document that > specify the TLS data format (using a schema) and replace them with JSON > structures. But that isn't going to be possible without a better way to > define structures. > > I don't think it is just a JSON issue though. While implementing TRANS I > added support for the TLV format to the parser. I have not yet added it t= o > any of the encoder or decoder libraries though. > > It is pretty clear that the proposers of CT are only interested in > addressing notary services for the certificate application and so they ar= e > obsessed with size and compactness. Which is fine. But I certainly don't > wish to carry that data encoding into any other notary application. So > being able to write a schema that allows the data structures to be render= ed > in the legacy TLS encoding and in JSON becomes quite important. > > > -- > Website: http://hallambaker.com/ > --001a1133757684925804f49ba931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Fri, Mar 14, 2014 at 5:30 PM, Phillip Hallam-Baker <hallam@gmail.com>= ; wrote:

=E2=80=8B=E2=80=8B
I think RFC 69= 62 could be improved substantially with some greater adherence to some stru= cture.

=E2=80=8BCould you be specific? =C2=A0I just glanc= ed at 6962 and it=E2=80=99s not obvious. =E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

Like many JSON Web services, message data is split betw= een the message contents and the URL.

More importantly, I would like to kill all the parts of= the document that specify the TLS data format (using a schema) and replace= them with JSON structures. But that isn't going to be possible without= a better way to define structures.

I don't think it is just a JSON issue though. While= implementing TRANS I added support for the TLV format to the parser. I hav= e not yet added it to any of the encoder or decoder libraries though.

It is pretty clear that the proposers of CT are only in= terested in addressing notary services for the certificate application and = so they are obsessed with size and compactness. Which is fine. But I certai= nly don't wish to carry that data encoding into any other notary applic= ation. So being able to write a schema that allows the data structures to b= e rendered in the legacy TLS encoding and in JSON becomes quite important.<= /div>
=C2=A0

--
Website: http://hallambaker.com/

--001a1133757684925804f49ba931-- From nobody Fri Mar 14 19:23:47 2014 Return-Path: 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 E437F1A0264 for ; Fri, 14 Mar 2014 19:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 xe9Ib7nam6EH for ; Fri, 14 Mar 2014 19:23:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7B31A0269 for ; Fri, 14 Mar 2014 19:23:44 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2F2NXx4012973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Mar 2014 19:23:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Fri, 14 Mar 2014 19:23:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> To: Tim Bray X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/V8hz8VSw8UUVjNN3P6hgUjiNGWk Cc: Phillip Hallam-Baker , IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:23:46 -0000 On Mar 14, 2014, at 6:59 PM, Tim Bray wrote: > Actually, I think it is relevant. If someone were to show an example = of an RFC where a hypothetical nomenclature/schema spec would have made = the RFC better, that would be a really good argument in the current = charter discussion. Phill's proposal is to change the protocol from using ASN.1 to JSON. = That's a discussion for the other WG, not here. --Paul Hoffman= From nobody Fri Mar 14 19:36:23 2014 Return-Path: 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 198B71A0271 for ; Fri, 14 Mar 2014 19:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 z-HGDnVeowpN for ; Fri, 14 Mar 2014 19:36:20 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id AC80D1A0274 for ; Fri, 14 Mar 2014 19:36:18 -0700 (PDT) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9563038F85; Fri, 14 Mar 2014 19:36:11 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , "'Tatu Saloranta'" References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> In-Reply-To: <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> Date: Fri, 14 Mar 2014 19:34:23 -0700 Message-ID: <008b01cf3ff7$142c8e10$3c85aa30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01CF3FBC.67CF8AD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEqnQ8EEvzQtZ7rey/gYepvhD2GLAKRxiKzAYVBhPYBriReLQI7Hj43A1aD63gCNhEeXgIzXFVYAsB+nrgA4vfrogHWBWTFAvv4ST2baQZn0A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/json/BWXkxq8ihtyqUJrKOU-EcD0oDL4 Cc: 'Nico Williams' , 'Matt Miller' , json@ietf.org Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:36:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008C_01CF3FBC.67CF8AD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: json [mailto:json-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Friday, March 14, 2014 4:02 PM To: Tatu Saloranta Cc: Nico Williams; json@ietf.org; Matt Miller Subject: Re: [Json] serializing sequences of JSON values =20 =20 On 14.03.2014, at 20:30, Tatu Saloranta wrote: On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams = wrote: The most interoperable form of JSON text sequence would be this: encoders MUST not use newlines in their JSON text encodings and MUST follow each JSON text with a newline. =20 And presumably this would include all linefeeds that JSON specification = supports? (\r, \n and \r\n). =20 =20 I hope not. =20 \r newlines no longer exist in the real world. \r\n on the other hand is just a special case of \n, a sane parser can = then just key on \n. =20 But I have seen \r\r\n on more than one occasion in the real world =20 Gr=C3=BC=C3=9Fe, Carsten=20 ------=_NextPart_000_008C_01CF3FBC.67CF8AD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= = json [mailto:json-bounces@ietf.org] On Behalf Of Carsten = Bormann
Sent: Friday, March 14, 2014 4:02 PM
To: = Tatu Saloranta
Cc: Nico Williams; json@ietf.org; Matt = Miller
Subject: Re: [Json] serializing sequences of JSON = values

 

 


On 14.03.2014, at 20:30, Tatu = Saloranta <tsaloranta@gmail.com> = wrote:

On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams <nico@cryptonector.com> = wrote:

The most = interoperable form of JSON text sequence would be this:
encoders MUST = not use newlines in their JSON text encodings and MUST
follow each = JSON text with a newline.

 

And presumably this would include all linefeeds that = JSON specification supports? (\r, \n and = \r\n).

 

 

I hope = not.

 

\r newlines no longer exist in the real = world.

\r\n on the other = hand is just a special case of \n, a sane parser can then just key on = \n.

 

But I have seen \r\r\n on more than one occasion in the real = world

 

Gr=C3=BC=C3=9Fe, = Carsten 

------=_NextPart_000_008C_01CF3FBC.67CF8AD0-- From nobody Fri Mar 14 19:43:46 2014 Return-Path: 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 406EF1A026E for ; Fri, 14 Mar 2014 19:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] 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 FHXlYR0sZsZ1 for ; Fri, 14 Mar 2014 19:43:40 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1841A0230 for ; Fri, 14 Mar 2014 19:43:40 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ma3so3404001pbc.27 for ; Fri, 14 Mar 2014 19:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qn1jOn+o6fDOMX8LUXAsXqR5kDGReE+oQsA0X0r51Do=; b=DYnG9acIDCJAb5MyKJtW0yDOe0Pou7E0J5sn2Va9scDZQ09fdCj5Eue0c7BAER6DlN IAx/h+S1ZzaCVHTI0Wvaxb8sSraj4UjND3OzMFp39SI57SArQKkTF9g4FZ70b12S8TNg l3/P4sNNegxFbytNFqf2XQY9EDgF6nKFvDCbJiNEv6PdmKLbp1zI+Xj+S23zF9z3oL1V wS8ZinaX95pbLq67Wph9AmgTzlEeY9FoGD/mk72fp9XJ9SPUWdf+KDc36r2vB6t/VEv7 vGOMQSJwfrgPvedL8SqqjGz/BW9ZNyF2rC8FMHQfnnt8D1Seqx3AORQ7i0sK6e/qv3Kx L0ig== X-Received: by 10.68.131.202 with SMTP id oo10mr12550742pbb.35.1394851413396; Fri, 14 Mar 2014 19:43:33 -0700 (PDT) Received: from [10.32.198.240] (pw126253067027.6.panda-world.ne.jp. [126.253.67.27]) by mx.google.com with ESMTPSA id yk4sm21091124pbc.16.2014.03.14.19.43.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 19:43:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B1464D4A-C9DA-4F57-B254-C44E86CEAFE8 Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Sat, 15 Mar 2014 11:43:29 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <53238F21.2030508@cisco.com> To: Phillip Hallam-Baker Archived-At: http://mailarchive.ietf.org/arch/msg/json/oN1ZAykWpV1wtRJX7RZ_13RMdXY Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:43:42 -0000 --Apple-Mail-B1464D4A-C9DA-4F57-B254-C44E86CEAFE8 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable +1=20 =3Dnat via iPhone Mar 15, 2014 9:18=1B$B!"=1B(BPhillip Hallam-Baker =1B$B$N= %a%C%;!<%8=1B(B: >=20 >=20 >=20 >> On Fri, Mar 14, 2014 at 7:22 PM, Matt Miller wrote: >> The chairs are seeking comment on whether we should adopt I-JSON >> (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our >> charter. Remember that adopting this draft does not mean it is done; >> changes can happen based on the consensus of the WG. >>=20 >> Note that the current draft does *not* have the new MIME type nor the >> reserved field name that was heavily debated in London; that could be >> added later if there is WG consensus to do so. >>=20 >> Please speak up whether or not you believe our charter should be amended >> to include this work item. >=20 > +1 >=20 > =20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --Apple-Mail-B1464D4A-C9DA-4F57-B254-C44E86CEAFE8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 

=3Dnat via iPhone

Mar 15, 2014 9:18=E3=80=81Phillip Hallam-Baker <hallam@gmail.com> =E3=81=AE=E3=83=A1=E3=83=83=E3= =82=BB=E3=83=BC=E3=82=B8:




On Fri, Mar 14, 2014 at 7:22 PM, Matt Miller <mamille2@cisco.com> wrote:
The chairs are seeking comment on whether we s= hould adopt I-JSON
(http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our<= br> charter. Remember that adopting this draft does not mean it is done;
changes can happen based on the consensus of the WG.

Note that the current draft does *not* have the new MIME type nor the
reserved field name that was heavily debated in London; that could be
added later if there is WG consensus to do so.

Please speak up whether or not you believe our charter should be amended
= to include this work item.

+1
=
 
--
Website: http://hallambaker.com/
____________________= ___________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman= /listinfo/json
= --Apple-Mail-B1464D4A-C9DA-4F57-B254-C44E86CEAFE8-- From nobody Fri Mar 14 19:56:05 2014 Return-Path: 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 82D121A026E for ; Fri, 14 Mar 2014 19:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 QyObn3WT8XYZ for ; Fri, 14 Mar 2014 19:56:02 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A76001A0236 for ; Fri, 14 Mar 2014 19:56:01 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id y1so2273875lam.6 for ; Fri, 14 Mar 2014 19:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Be4TQvt4tDFZJicwdzFRbjikDifY2IvSrcHQCfGZ5rU=; b=OXtt4hKrR3xH3lvKk+D/FFP0xOGKMoSnH1N4M0mRGRMPP6nWeTgl6kc6fPBDXvph2T tyz4vzGY3ASX0cw1uE2Fk451DnAYXGBENXmFz5smikV24bM1xV+O1xxMtopwCgssJ+o1 a6KbG2NkwPSa4zR9m6UAwQ8uzrLwKEicwLMmgGb/VjjS/QrDg5ynlidafFmPjql/k4pH Ag6IlK/5I9lfVAR4frCR8HXkiLkWDvnF8sRtFE3WuQiyV7/LlQ0yVqiTjY22L0DSX6WM qWCqAnEc4aqETeQhTpZBbnpAgvGh6GFpGOyu9QRO/ziTgXg40tSlTng3SwpPhRWFfcMt 08xw== MIME-Version: 1.0 X-Received: by 10.153.7.200 with SMTP id de8mr7928218lad.19.1394852154064; Fri, 14 Mar 2014 19:55:54 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 14 Mar 2014 19:55:53 -0700 (PDT) In-Reply-To: <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> Date: Fri, 14 Mar 2014 22:55:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1137e9862847b904f49c537c Archived-At: http://mailarchive.ietf.org/arch/msg/json/K2s0YnPGsXCnAnOdA2hlJvWbMeQ Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 02:56:03 -0000 --001a1137e9862847b904f49c537c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 9:58 PM, Paul Hoffman wrote: > On Mar 14, 2014, at 5:30 PM, Phillip Hallam-Baker > wrote: > > > I think RFC 6962 could be improved substantially with some greater > adherence to some structure. > > Could you maybe take that discussion to the trans working group? It is not > relevant to this WG. Thanks! > > --Paul Hoffman Tim asked for an example of a JSON specification that would be improved by a schema. I gave him one. -- Website: http://hallambaker.com/ --001a1137e9862847b904f49c537c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 14, 2014 at 9:58 PM, Paul Hoffman <paul.hoffman@vpnc.org&g= t; wrote:
On Mar 14, 2014, at 5:30 PM,= Phillip Hallam-Baker <hallam@gmail.= com> wrote:

> I think RFC 6962 could be improved substantially with some greater adh= erence to some structure.

Could you maybe take that discussion to the trans working group? It i= s not relevant to this WG. Thanks!

--Paul Hoffman
=A0
Tim asked for = an example of a JSON specification that would be improved by a schema. I ga= ve him one.=A0


--
Website: http://hallambaker.com/
--001a1137e9862847b904f49c537c-- From nobody Fri Mar 14 20:02:21 2014 Return-Path: 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 8FC701A0236 for ; Fri, 14 Mar 2014 20:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 fnHfJpoz9_a1 for ; Fri, 14 Mar 2014 20:02:18 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (unknown [69.163.253.176]) by ietfa.amsl.com (Postfix) with ESMTP id A4F851A0230 for ; Fri, 14 Mar 2014 20:02:18 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 96ECE6B0078 for ; Fri, 14 Mar 2014 20:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=F3XYz/FHou9YPYM/OAVd G3BvemA=; b=eE5YDgsbiHNsaQfiQoI0kMThQCI8M9papBav+rgWNXemrVGDVU/1 MUK4oCF7ISvoE056wOKFPZLXl1lsms7UiOJ08v0sAmOv13h2gJRs1UWhrnQ8uxRk jl+6ziBWi0hBRcHJYvGDyRLce0OvFssEMM8OgEfnY8fisNiL9PWbbpY= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 4BB4B6B0059 for ; Fri, 14 Mar 2014 20:02:11 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id w62so2834726wes.0 for ; Fri, 14 Mar 2014 20:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+oDDqyLnYJZ0ZYsKm8WYNMc08v4+NGY4YKfbKjkQip8=; b=Xyf4tVnYb3ws4Czo1cs1N3Ru1BIltLKwCypBeX/oCnQo5vZjQtK9QDKNkoQT9aUCsk aQuTiHAxNrpxSl/pLyMTSeNeqAytHjeewKS0yG+X373wvthJqFD5pQlDXzz8UoIHuuYl QxpGdfT6C0HZApWzwsT2E/ZW0OrOZZ1hRYvgy2KNvmoLqQa2ThR7+boYBHF2EUNwvYXB nuXz7PjEdTwbtTDqnqmjb3RY8KyEmGTYUVkMfS6JNlBu2x5IWBpMQDBWmGrIcG/4LPWZ E72CueWc3l/jji6YFSPcQyrpBu3LR/p6gz/Ib3Rkyi4fIPpfQsFTmT/aaZrZj6Nnkdtj dIfw== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr935946wib.42.1394852529962; Fri, 14 Mar 2014 20:02:09 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Fri, 14 Mar 2014 20:02:09 -0700 (PDT) In-Reply-To: References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> Date: Fri, 14 Mar 2014 22:02:09 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Cg8uMySLCv0eSYND2-eg4tg2ITs Cc: Phillip Hallam-Baker , Tim Bray , IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:02:19 -0000 On Fri, Mar 14, 2014 at 9:23 PM, Paul Hoffman wrote: > On Mar 14, 2014, at 6:59 PM, Tim Bray wrote: >> Actually, I think it is relevant. If someone were to show an example of an RFC where a hypothetical nomenclature/schema spec would have made the RFC better, that would be a really good argument in the current charter discussion. > > Phill's proposal is to change the protocol from using ASN.1 to JSON. That's a discussion for the other WG, not here. That's not Phil's proposal. Look carefully! Search for "array" and "object" in the RFC. (I also wondered wth Phil was talking about when I glanced at that RFC.) Nico -- From nobody Fri Mar 14 20:27:24 2014 Return-Path: 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 AB64D1A0268 for ; Fri, 14 Mar 2014 20:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 1PaoXCSTOB1V for ; Fri, 14 Mar 2014 20:27:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 44B7C1A0230 for ; Fri, 14 Mar 2014 20:27:21 -0700 (PDT) Received: (qmail 24739 invoked from network); 15 Mar 2014 03:27:12 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 15 Mar 2014 03:27:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5323c890.xn--btvx9d.k1403; i=johnl@user.iecc.com; bh=xWluVU1RHZ7yY6HBuX36Vs2M9Q6UTd1frKhKS3ftAfU=; b=OP6KvczNzIleJG/EfjIe8MtbB28H94S0JF34fWOFTD80eDOYCm26FKHLbggCeNIGkIKuiLDwpfL4cx+X5ofsKLPFlL1YrLaEmHINOQ0OP+1tbRtz8pCSm3G+HtDVTfbmIy2teM49NSPjavymDdy+R2p8AYNszwMHX/ycg93bVNypak6YMKOvm/dc3IxxRyWtFW21l3YhNL81h5tSJ9CqhEAi8y24xQrBtcx2hz2hBipdzOB8qGWwPAmFg4AzDXN2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5323c890.xn--btvx9d.k1403; bh=xWluVU1RHZ7yY6HBuX36Vs2M9Q6UTd1frKhKS3ftAfU=; b=FF9591iu7fHyU5nzTgJICI/NSHI2jJ2wPnHT/FsvO3orfXEgqwkxd2UvX8rFdUz0DLTLLDR4fuxKfP8CX4BK9MTIeoH+lyx5We4RvVpxhnT2WI/UPd+qctTUxHY8Vdxvpe8GyQHerEoBvUtME/uvIcNFs6ODTCpVmyhU2QLIE0i6uEzeEo+D9LPNPB5JOMcVXj1gnuE6AUmYS94HFvRZA2jh/JeS082rOCPez34vqLvsbr8j1fnz1nnB99rMhfZD Date: 15 Mar 2014 03:26:50 -0000 Message-ID: <20140315032650.89676.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/R7QqK7AnsDVoqpZ6Jw4qxGAJ18k Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:27:22 -0000 >>> Please speak up whether or not you believe our charter should be amended >>> to include this work item. Yes. R's, John From nobody Fri Mar 14 23:12:58 2014 Return-Path: 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 CF8961A0051 for ; Fri, 14 Mar 2014 23:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 MWD-zvv8RuUN for ; Fri, 14 Mar 2014 23:12:55 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E24C21A0035 for ; Fri, 14 Mar 2014 23:12:54 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s2F6Cek5022685; Sat, 15 Mar 2014 15:12:40 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7126_7a7c_d026f948_ac08_11e3_83c9_001e6722eec2; Sat, 15 Mar 2014 15:12:40 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AC10ABF4CC; Sat, 15 Mar 2014 15:12:39 +0900 (JST) Message-ID: <5323EF4E.3040603@it.aoyama.ac.jp> Date: Sat, 15 Mar 2014 15:12:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matt Miller , IETF JSON WG References: <53238F21.2030508@cisco.com> In-Reply-To: <53238F21.2030508@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/D0IcJUuqUXLAPlxB7MqVAsWFFII Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 06:12:57 -0000 On 2014/03/15 08:22, Matt Miller wrote: > The chairs are seeking comment on whether we should adopt I-JSON > (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our > charter. Remember that adopting this draft does not mean it is done; > changes can happen based on the consensus of the WG. > Please speak up whether or not you believe our charter should be amended > to include this work item. Okay with me. > Note that the current draft does *not* have the new MIME type nor the > reserved field name that was heavily debated in London; that could be > added later if there is WG consensus to do so. It's great that these are gone, and they shouldn't come back. Regards, Martin. From nobody Sat Mar 15 03:44:47 2014 Return-Path: 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 710F01A00EA for ; Sat, 15 Mar 2014 03:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 d6oaRsBzP5nD for ; Sat, 15 Mar 2014 03:44:41 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9E1A00E8 for ; Sat, 15 Mar 2014 03:44:40 -0700 (PDT) Received: from newyork.local.box ([80.187.100.248]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0LtWwK-1X5q9l0Fm8-010wBd for ; Sat, 15 Mar 2014 11:44:33 +0100 Message-ID: <53242F10.2020607@drees.name> Date: Sat, 15 Mar 2014 11:44:32 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: json@ietf.org References: <53238F21.2030508@cisco.com> In-Reply-To: <53238F21.2030508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fmcOQ9KrCPxrZyUS0quV4u86bvj0lzBXvPhkEnsUyGoyvJZmjnL hCGN2Bn3GMzF9cMQaE1hqkTQHFnpJViJ8VP6MAMe6sgmJ/nH7kkDyl6ar+y3BOACUT7SY1V m0sstPk7/x4+ZwVoA7/293X1mtG02JL2oMt8/CYrWCnPkdw/Wx7d/ezZU7JYiC5m0hYjTEk Qsk7njo/nmudA3U5TyP1A== Archived-At: http://mailarchive.ietf.org/arch/msg/json/3qsAzHOhr794z5W9s-5wDhV8jII Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 10:44:42 -0000 On 2014-03-15 00:22 +01:00, Matt Miller wrote: > The chairs are seeking comment on whether we should adopt I-JSON > (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our > charter. Remember that adopting this draft does not mean it is done; > changes can happen based on the consensus of the WG. Yes, please do so. > Note that the current draft does *not* have the new MIME type nor the > reserved field name that was heavily debated in London; that could be > added later if there is WG consensus to do so. A gentle "Please do not come back" from my side. > Please speak up whether or not you believe our charter should be amended > to include this work item. > > > --Paul Hoffman and Matt Miller "All the best, Stefan" From nobody Sat Mar 15 03:57:59 2014 Return-Path: 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 789B81A00F4 for ; Sat, 15 Mar 2014 03:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 VmHkgCc77DSY for ; Sat, 15 Mar 2014 03:57:55 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5251A00EF for ; Sat, 15 Mar 2014 03:57:55 -0700 (PDT) Received: from newyork.local.box ([80.187.100.89]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0M09dQ-1XGtVP2976-00uJro for ; Sat, 15 Mar 2014 11:57:47 +0100 Message-ID: <5324322B.1030001@drees.name> Date: Sat, 15 Mar 2014 11:57:47 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: json@ietf.org References: <53238F2E.5010105@cisco.com> In-Reply-To: <53238F2E.5010105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9zafMcFNRw1saIQp2l4Gsf8gqbjM45gLkL9NwRQIfm+EsagQFCK sVeAwF3E65/7X58nKPbO4JdNYzvgxUh2KN0+1y2mL9v+x6N4MN017Dt4L2ww+HQoHbVbaNH P59PN0AJZZ2kUc3tZZuPp+oj+s1rjGF4GXkJLUYvyCZ3FFTlGXhqW/6w4GRKhzqf3qsqXlg svqXuB1IO3/93MaLTwJFw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/P9SHXk0QD_iG0XRb1S_ozCO9W_0 Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 10:57:56 -0000 On 2014-03-15 00:22 +01:00, Matt Miller wrote: > The chairs are seeking comment on whether or not the WG wants to adopt > one or more nomenclature / schema / description documents in the WG > charter. A few such documents have been brought to the WG, but our > initial take is that the WG doesn't want to make any of them WG > documents. They could proceed towards becoming RFCs without any > interaction from the WG, depending on the wishes of the ADs and/or the > Independent Stream Editor. Once a nomenclature document is an RFC, other > RFCs could use it to describe the JSON in those later RFCs. > > Please speak up whether or not you believe our charter should be amended > to include a work item that would adopt one or more nomenclature / > schema / description documents. +0 on opening up for inclusion. I think discussion / inspection of additional examples (besides RFC 6962) would help guide us to a well-informed consensus in that regard. > > --Paul Hoffman and Matt Miller "All the best, Stefan" From nobody Sat Mar 15 05:56:13 2014 Return-Path: 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 50DC11A012F for ; Sat, 15 Mar 2014 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 YXxjA6A797R3 for ; Sat, 15 Mar 2014 05:56:07 -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 BFC981A012E for ; Sat, 15 Mar 2014 05:56:06 -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.5/8.14.5) with ESMTP id s2FCtldG024214; Sat, 15 Mar 2014 13:55:47 +0100 (CET) Received: from [192.168.217.105] (p54890704.dip0.t-ipconnect.de [84.137.7.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5FF6E3A5; Sat, 15 Mar 2014 13:55:46 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <5324322B.1030001@drees.name> Date: Sat, 15 Mar 2014 13:55:43 +0100 X-Mao-Original-Outgoing-Id: 416580943.313289-6ae989b1de1bd6bc795d503e3a1cae7c Content-Transfer-Encoding: quoted-printable Message-Id: References: <53238F2E.5010105@cisco.com> <5324322B.1030001@drees.name> To: stefan@drees.name X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/fEwuzh1ajAbCfhVNBflYjDAVjgU Cc: json@ietf.org Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 12:56:08 -0000 On 15 Mar 2014, at 11:57, Stefan Drees wrote: > additional examples (besides RFC 6962)=20 How about the ALTO schema language: http://tools.ietf.org/html/draft-ietf-alto-protocol-27#section-8.2 This is interesting, as its expressivity has been designed (limited) for = the specification style at hand. I haven=92t checked this, but it might have worked for the style used in = RFC 7071, too. Gr=FC=DFe, Carsten From nobody Sat Mar 15 06:22:03 2014 Return-Path: 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 F00E51A0130 for ; Sat, 15 Mar 2014 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WANT=2.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 vqWt9ZPi5-iD for ; Sat, 15 Mar 2014 06:21:59 -0700 (PDT) Received: from mail.pantor.com (smtp1.pantor.com [62.109.60.237]) by ietfa.amsl.com (Postfix) with ESMTP id B5E091A0117 for ; Sat, 15 Mar 2014 06:21:58 -0700 (PDT) Received: from mail.pantor.com ([10.10.10.243]) by mail.pantor.com (8.13.8/8.13.8) with ESMTP id s2FDLola021013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Mar 2014 14:21:50 +0100 Received: from 89-253-89-32.customers.ownit.se ([89.253.89.32]:65186 helo=[192.168.1.9]) by mail.pantor.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WOoX2-0005XO-1v; Sat, 15 Mar 2014 14:21:44 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: David Rosenborg In-Reply-To: Date: Sat, 15 Mar 2014 14:21:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09AF77C3-BDC7-42E2-B637-6A030BFEB7AF@pantor.com> References: <53238F2E.5010105@cisco.com> <5324322B.1030001@drees.name> To: Carsten Bormann X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/RjQymFle4VquZGEMFCCBZPebuZs Cc: stefan@drees.name, json@ietf.org Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 13:22:01 -0000 Hi, For schema language inspiration you might wan't to have a look at = http://blinkprotocol.org/s/BlinkSpec-beta4.pdf. Specifically section 7 = covers the overall schema grammar. Obviously this is outside of IETF but I believe that the schema language = has some merits for describing JSON-based protocols. There is a JSON = mapping available here: = http://blinkprotocol.org/s/BlinkJsonSpec-beta4.pdf Disclaimer: I'm on the team developing the open source Blink protocol so = you could opt to regard this as off topic or simply as a shameless plug = ... Kind regards, David Rosenborg On 2014-03-15, at 13:55 , Carsten Bormann wrote: > On 15 Mar 2014, at 11:57, Stefan Drees wrote: >=20 >> additional examples (besides RFC 6962)=20 >=20 > How about the ALTO schema language: >=20 > http://tools.ietf.org/html/draft-ietf-alto-protocol-27#section-8.2 >=20 > This is interesting, as its expressivity has been designed (limited) = for the specification style at hand. >=20 > I haven=92t checked this, but it might have worked for the style used = in RFC 7071, too. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Sat Mar 15 06:46:23 2014 Return-Path: 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 DF8071A0146 for ; Sat, 15 Mar 2014 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 UZR-PhVfNGMw for ; Sat, 15 Mar 2014 06:46:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA4E1A0142 for ; Sat, 15 Mar 2014 06:46:18 -0700 (PDT) Received: from netb ([89.204.139.147]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M4CB5-1XGVlL1i0R-00rrWs; Sat, 15 Mar 2014 14:46:10 +0100 From: Bjoern Hoehrmann To: Matt Miller Date: Sat, 15 Mar 2014 14:46:11 +0100 Message-ID: References: <53238F21.2030508@cisco.com> In-Reply-To: <53238F21.2030508@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:bds0sQ9/uTa/2Ov1cV4TidsbAnELdHdFlDc+tRc4qlwmyFvtel9 /fsC7iMkyfLtHsqiJG28fDpl7Vy+uENVYUbmgsRqOrVikx2Cvqx4drbmSruTSrxrkxqpNeO WplBY5fzEurteYoRA2VUO/f1D4if1rDxgXUAEeEY6v8OFZVLAfFAv+gBr4zuQOYC6sQuKJk oCIg6TUXDrWisWfI1440A== Archived-At: http://mailarchive.ietf.org/arch/msg/json/aWMg8y-lDexAeygtK5payBDLcnE Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 13:46:21 -0000 * Matt Miller wrote: >The chairs are seeking comment on whether we should adopt I-JSON >(http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our >charter. Remember that adopting this draft does not mean it is done; >changes can happen based on the consensus of the WG. No, not without changing the nature of the document considerably. These are just best practises and not a separate format with its own name. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sat Mar 15 06:48:35 2014 Return-Path: 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 7706B1A0146 for ; Sat, 15 Mar 2014 06:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 o08ViInsDXtn for ; Sat, 15 Mar 2014 06:48:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF4A1A0142 for ; Sat, 15 Mar 2014 06:48:31 -0700 (PDT) Received: from netb ([89.204.139.147]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LeBPM-1Wuryb48Ro-00prcY; Sat, 15 Mar 2014 14:48:22 +0100 From: Bjoern Hoehrmann To: Matt Miller Date: Sat, 15 Mar 2014 14:48:16 +0100 Message-ID: <4em8i99ijbnaig72kub8ks43k83vp9e4al@hive.bjoern.hoehrmann.de> References: <53238F2E.5010105@cisco.com> In-Reply-To: <53238F2E.5010105@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3WRCBjvZ6y/bLRJuq22UauHQNAMSVPFjuASa0KwkD5oZUAHg3u2 zNyxwgYrWM4x3/Lz+6k3xLEffdV5WhA/Es9y0+ffJ3OVmtUzfPRAziN/sB66DQx/4XPiFaE uCAyg3tmR9oj4OlCWQC2+F/X2x0xQRbD5LNaeo5SHdxnK5hAU9e139Ks08t1HodOvr8veyO 8VUZQxvJvuSJb13zJl+Ow== Archived-At: http://mailarchive.ietf.org/arch/msg/json/ghbcmKKe6wKU_YiCHlOI5VQHLq0 Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 13:48:33 -0000 * Matt Miller wrote: >Please speak up whether or not you believe our charter should be amended >to include a work item that would adopt one or more nomenclature / >schema / description documents. There are various efforts in the area and they do not seem to need an IETF WG at this moment. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sat Mar 15 07:06:47 2014 Return-Path: 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 52E551A0150 for ; Sat, 15 Mar 2014 07:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] 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 ECaiREmTZl9q for ; Sat, 15 Mar 2014 07:06:42 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AD1321A014D for ; Sat, 15 Mar 2014 07:06:41 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so2586646lbd.29 for ; Sat, 15 Mar 2014 07:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kN2JDhbwSeioqb+1n5rLsRLSn/l32EgTsOEKP5dEncg=; b=P3Tu/sfzqZ/anTz/41P/YAj0B0zi986cKMw+oAKJUIsJfLwbBm7yLn73f7JBQ7h9Cm XA8m+/mDCN6/K497EtSSOpLuQNvZvDocTcb2cWmPy7atlnvIfWyoeL+ptQEcbQRJT6zG 38uxZgQb4dlxeLUZV0I8/WXS8EF+6RdftMo76W+QBSWXzzsbOQo4z8OJjJv+DTsuCsgL GjWJzcyB5XPy+yVA6LlCBxuGBCvJGvir9E+NRvY6gK4s10lOK8nQ6HSgYMH3MojjjrDL lj4n3Ro1cRi8anwZHim5S+EGZr/oovsSpJZ6t3752fdqXXOlZYYJ7ao6jsMRP2it2C9+ 142A== MIME-Version: 1.0 X-Received: by 10.112.45.108 with SMTP id l12mr9342466lbm.21.1394892393900; Sat, 15 Mar 2014 07:06:33 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sat, 15 Mar 2014 07:06:33 -0700 (PDT) Date: Sat, 15 Mar 2014 10:06:33 -0400 Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=001a1134bfc8a3705c04f4a5b12d Archived-At: http://mailarchive.ietf.org/arch/msg/json/mchdjFecE2fDyO-3wQZnvikJTek Subject: [Json] Modularity and composition X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 14:06:45 -0000 --001a1134bfc8a3705c04f4a5b12d Content-Type: text/plain; charset=ISO-8859-1 I strongly support removing the namespace parameter for I-JSON. I understand what is being attempted there but it does not work in XML so I see no reason to repeat it. Here is what I think works instead. I don't think this should become part of the I-JSON draft but it would be useful to describe it as an example of one approach to JSON modularity. The key feature that JSON has which XML does not is that a JSON tag may be any valid UNICODE string. That means that we can put a URI in it. Now what makes more sense to you: { "tag1" : "you don't know what this is about yet", "jsonns" : "urn:iana:protocols:foo:v1" "tag2" : "more tags at the same lexical level as the namespace" } or { "urn:iana:protocols:foo:v1" { "tag1" : "The enclosing tag shows what this is all about", "tag2" : "More tags within the defined space" } } What I really like about this approach is that it is clear that what is being included is a separate data object that should be handed off to a separate handler. One of the more awesome features of the .NET platform is that it allows service applets to register code to handle parts of the HTTP URL namespace. So you can register a handler for "http://example.com:8000/.well-known/foo". But the URL space is an administrator space. Not a protocol space. The command type should be specified in the protocol messages not the transport binding. Having the protocol commands passed in HTTP headers makes no more sense than putting them in TLS extensions. This lexical approach would make it possible to do similar tricks within a handler for JSON based Web services. Let us imagine that we decide to package up our request and response data as follows: { "urn:iana:protocols:foo:v1:GET-Request": { ... ...}} or maybe the URI stem is implicit: { "GET-Request": { ... ...}} Note that all the information relevant to the protocol is now in one place. The part where the wheels came off the tomato for XML namespace was when we tried XML Digital Signature. That led to canonicalization which let to bizarre transformational approaches. Yuk! The approach I suggest here works really well with signed or encrypted data objects. The only catch is that you have to understand that Digital Signatures sign a list of octets and not an object. So this approach is doomed to fail: { "Signed-Data": { "tag": "Never gonna work reliably"}} To get the scheme to work we have to Base64 the signed data so that the sender. [At ths pont the and ey on my MacBoo have broen so the rest mght be dffcult to read and wll stop.] -- Website: http://hallambaker.com/ --001a1134bfc8a3705c04f4a5b12d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I strongly support removing the namespace parameter f= or I-JSON. I understand what is being attempted there but it does not work = in XML so I see no reason to repeat it. Here is what I think works instead.= I don't think this should become part of the I-JSON draft but it would= be useful to describe it as an example of one approach to JSON modularity.=


The key feature that JSON has which XML = does not is that a JSON tag may be any valid UNICODE string. That means tha= t we can put a URI in it.

Now what makes more sens= e to you:

{ "tag1" : "you don't know what this= is about yet",
=A0 =A0"jsonns" : "urn:iana:p= rotocols:foo:v1"
=A0 "tag2" : "more tags at t= he same lexical level as the namespace" }

or

{ =A0"urn:iana:protoco= ls:foo:v1" {
=A0"tag1" : "The enclosing = tag shows what this is all about",
=A0 "tag2" : &q= uot;More tags within the defined space" } }

What I really like about this approach is that it is c= lear that what is being included is a separate data object that should be h= anded off to a separate handler.=A0

One of the more awesome features of the .NET platform is that it= allows service applets to register code to handle parts of the HTTP URL na= mespace. So you can register a handler for "http://example.com:8000/.well-k= nown/foo".

But the URL space is an administrator space. Not a prot= ocol space. The command type should be specified in the protocol messages n= ot the transport binding. Having the protocol commands passed in HTTP heade= rs makes no more sense than putting them in TLS extensions.


This lexical approach would make it poss= ible to do similar tricks within a handler for JSON based Web services. Let= us imagine that we decide to package up our request and response data as f= ollows:

{ "urn:iana:protocols:foo:v1:GET-Request": { = ... ...}}

or maybe the URI stem is implicit:=A0

{ "GET-Request": { ... ...}}

Note that all the information relevant to the protocol is no= w in one place.=A0


The part where t= he wheels came off the tomato for XML namespace was when we tried XML Digit= al Signature. That led to canonicalization which let to bizarre transformat= ional approaches. Yuk!

The approach I suggest here works really well with sign= ed or encrypted data objects. The only catch is that you have to understand= that Digital Signatures sign a list of octets and not an object. So this a= pproach is doomed to fail:

{ "Signed-Data": =A0{ "tag": "= Never gonna work reliably"}}

To get the schem= e to=A0work=A0we have to Base64 the=A0signed=A0data so that the sender.


[At ths pont the =A0and =A0ey on my MacBoo ha= ve broen so the rest mght be dffcult to read and =A0wll stop.]



--
Website: http://hallambaker.com/
--001a1134bfc8a3705c04f4a5b12d-- From nobody Sat Mar 15 07:36:08 2014 Return-Path: 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 5348F1A0204 for ; Sat, 15 Mar 2014 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 KAQXa9ieZCgT for ; Sat, 15 Mar 2014 07:36:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DA4F21A0146 for ; Sat, 15 Mar 2014 07:36:04 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WOpgn-0005ga-8R; Sat, 15 Mar 2014 10:35:53 -0400 Date: Sat, 15 Mar 2014 10:35:53 -0400 From: John Cowan To: Bjoern Hoehrmann Message-ID: <20140315143553.GC30147@mercury.ccil.org> References: <53238F21.2030508@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/Vm6NcH4BjLya6h3YZRsYTTmE3L8 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 14:36:07 -0000 Bjoern Hoehrmann scripsit: > No, not without changing the nature of the document considerably. These > are just best practises and not a separate format with its own name. The idea, I think, is that if the receiver sees the new name it can make more stringent assumptions about the input. Indeed, given a name, certain receivers can say they will *only* accept I-JSON. It is analogous to the "strict" declaration in JavaScript (or Perl, for that matter). -- John Cowan http://www.ccil.org/~cowan You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! `Tis a Jute.... (Finnegans Wake 16.5) From nobody Sat Mar 15 07:46:05 2014 Return-Path: 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 A2C211A0204 for ; Sat, 15 Mar 2014 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 GGvuxhDse0dj for ; Sat, 15 Mar 2014 07:46:01 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E91A0146 for ; Sat, 15 Mar 2014 07:46:01 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ec20so2489375lab.25 for ; Sat, 15 Mar 2014 07:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fZrNrSeTYEZAe6OE2E+Exj1Kk58tgbLZ0baQdRs7us8=; b=GUWQ0y83nC/7yYnfz6+Um0w0cEm79aRobJcemoF9xW4D1H+k3GGphfiCulCl81Q+/t MpFAgJbAcaioqdmJ3ou++3qaMX+A7Y73SNp/aR8yKqW+TxZx0NVY9l5CXVhCg4fO9ZCl Jt0dMjj7Qtuv3SCHo95ob7sC0OeB5G+uYLUArHmDbdZL6p6FeX11Lr8VtzG9NZjzgve9 A2ZhX57Tw4scUTautJvjFRvqL+wuhpYFb0RO4y2Y9lc+2INh+cb4N3fBADYz+/25UB/d 6OiPrjYLHon/DVGOVrcnKbvlPjELcoOxUInmHJngloFXHEgKkusTXGRC1C58XVHUTclr ZQpg== MIME-Version: 1.0 X-Received: by 10.112.13.101 with SMTP id g5mr1353386lbc.39.1394894753606; Sat, 15 Mar 2014 07:45:53 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sat, 15 Mar 2014 07:45:53 -0700 (PDT) In-Reply-To: <4em8i99ijbnaig72kub8ks43k83vp9e4al@hive.bjoern.hoehrmann.de> References: <53238F2E.5010105@cisco.com> <4em8i99ijbnaig72kub8ks43k83vp9e4al@hive.bjoern.hoehrmann.de> Date: Sat, 15 Mar 2014 10:45:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a11c3a6fc49b39904f4a63ea0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/UzfFrPQsqGo40slg_V4nAM18uUs Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 14:46:03 -0000 --001a11c3a6fc49b39904f4a63ea0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 15, 2014 at 9:48 AM, Bjoern Hoehrmann wrote: > * Matt Miller wrote: > >Please speak up whether or not you believe our charter should be amended > >to include a work item that would adopt one or more nomenclature / > >schema / description documents. > > There are various efforts in the area and they do not seem to need an > IETF WG at this moment. > I would like to have consistency if possible. I would also like to avoid doing what happened with XML where the first six months of every WG I was part of spent six months at the start discussing how to use XML. And I would really like to avoid what happened with SAML where we had to redo the spec because the approach taken to modularity turned out not to work. -- Website: http://hallambaker.com/ --001a11c3a6fc49b39904f4a63ea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 15, 2014 at 9:48 AM, Bjoern Hoehrmann <derhoermi@gmx.n= et> wrote:
* Matt Miller wrote:
>Please speak up whether or not you believe our charter should be amende= d
>to include a work item that would adopt one or more nomenclature /
>schema / description documents.

There are various efforts in the area and they do not seem to need an=
IETF WG at this moment.

I would like to= have consistency if possible.

I would also like t= o avoid doing what happened with XML where the first six months of every WG= I was part of spent six months at the start discussing how to use XML.=A0<= /div>

And I would really like to avoid what happened with SAM= L where we had to redo the spec because the approach taken to modularity tu= rned out not to work.=A0


-- Website: http://hallambaker.com/
--001a11c3a6fc49b39904f4a63ea0-- From nobody Sat Mar 15 08:14:43 2014 Return-Path: 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 C4B0E1A0289 for ; Sat, 15 Mar 2014 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 mAAnIFGL4ndp for ; Sat, 15 Mar 2014 08:14:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 262B51A0146 for ; Sat, 15 Mar 2014 08:14:39 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2FFETmm033273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Mar 2014 08:14:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sat, 15 Mar 2014 08:14:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/4V_kcNyK27_amTAbrmUlPgzqiaU Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 15:14:41 -0000 On Mar 14, 2014, at 8:02 PM, Nico Williams = wrote: > On Fri, Mar 14, 2014 at 9:23 PM, Paul Hoffman = wrote: >> On Mar 14, 2014, at 6:59 PM, Tim Bray wrote: >>> Actually, I think it is relevant. If someone were to show an = example of an RFC where a hypothetical nomenclature/schema spec would = have made the RFC better, that would be a really good argument in the = current charter discussion. >>=20 >> Phill's proposal is to change the protocol from using ASN.1 to JSON. = That's a discussion for the other WG, not here. >=20 > That's not Phil's proposal. Look carefully! Search for "array" and > "object" in the RFC. >=20 > (I also wondered wth Phil was talking about when I glanced at that = RFC.) Wow, I totally missed that too. My apologies to Phill for cutting him = off on the discussion of CT logs. --Paul Hoffman= From nobody Sat Mar 15 08:18:22 2014 Return-Path: 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 428AA1A028D for ; Sat, 15 Mar 2014 08:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 ky5krab1yS5V for ; Sat, 15 Mar 2014 08:18:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8283F1A0289 for ; Sat, 15 Mar 2014 08:18:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2FFIAr3033449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Mar 2014 08:18:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sat, 15 Mar 2014 08:18:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <724C698D-7E06-452E-A11F-31DA794C3A28@vpnc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/7z0ap7b9Yf2NoCEQE2Sc4Dc9DLM Cc: JSON WG Subject: Re: [Json] Modularity and composition X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 15:18:21 -0000 On Mar 15, 2014, at 7:06 AM, Phillip Hallam-Baker = wrote: > I strongly support removing the namespace parameter for I-JSON. Please note that the consensus call was for the -01 draft, which has no = namespace. If the WG adopts the work, it would start with the -01 draft, = and the call indicated. --Paul Hoffman= From nobody Sat Mar 15 09:17:18 2014 Return-Path: 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 606121A00F3 for ; Sat, 15 Mar 2014 09:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 wctjEx0VKKX3 for ; Sat, 15 Mar 2014 09:17:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE241A00C3 for ; Sat, 15 Mar 2014 09:17:14 -0700 (PDT) Received: from netb ([89.204.139.147]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LjuR3-1X0ezF3LcP-00bpkT; Sat, 15 Mar 2014 17:16:47 +0100 From: Bjoern Hoehrmann To: John Cowan Date: Sat, 15 Mar 2014 17:16:43 +0100 Message-ID: <72u8i9dj6ih7o95cibq44o8kuq8k2dm40l@hive.bjoern.hoehrmann.de> References: <53238F21.2030508@cisco.com> <20140315143553.GC30147@mercury.ccil.org> In-Reply-To: <20140315143553.GC30147@mercury.ccil.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:BbZEfBSMn73AE2x+cjYr94rtsXaGI+38KP9jI//lCmnuax3cw0V BCyljkSpsGzmc8EayuQLoKnkb+rsqtiIagE2IL8jWBzVO1MYuIu1fUxe+p4OLmMXbP2Qy5l oZMFdKSMIZJrKHUYH3vr77kGEbmiYFmuI9Bs2FHENVcwIsQzpS33EzId8kSEc37ghGcUs2k mbAbuA7xUFs53aGtBMl2Q== Archived-At: http://mailarchive.ietf.org/arch/msg/json/bDO2PpmyWSNIHaky-0Plp5re6ns Cc: Matt Miller , IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:17:17 -0000 * John Cowan wrote: >Bjoern Hoehrmann scripsit: > >> No, not without changing the nature of the document considerably. These >> are just best practises and not a separate format with its own name. > >The idea, I think, is that if the receiver sees the new name it can make >more stringent assumptions about the input. Indeed, given a name, certain >receivers can say they will *only* accept I-JSON. It is analogous to the >"strict" declaration in JavaScript (or Perl, for that matter). For human-readable documentation purposes it is entirely sufficient to say "follows RFC XXXX conventions" and implementations can just assume the conventions are being followed until they detect otherwise (which "I-JSON" implementations are required to do as currently proposed). -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sat Mar 15 09:24:23 2014 Return-Path: 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 EF5FB1A00EB for ; Sat, 15 Mar 2014 09:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0FyJY8PNsuap for ; Sat, 15 Mar 2014 09:24:20 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1675C1A00EC for ; Sat, 15 Mar 2014 09:24:20 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so4067436veb.15 for ; Sat, 15 Mar 2014 09:24:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KrISOxfsED429KwN/B+0fix2ER+f0bLRnhcMnLcefUc=; b=ES8nPmvYVmvQQ3LFWCgULCPNMUjdWzLZpJP22Ekcsqz+2tfOTQL2X+uan2SOcqCjYI 0x9vGV8fJDIXQbCbP0TCPtgucCQY+i4zbl7M5++7S7zFuqeqifUEO2Bz90V40JZPWJPo 7eGjg0uFY2yajZUXHFPJbNlCuMRYmKM++PhvfIsoomuyP0bxv7qT0mlmeknJTPVn7wo+ O94LnwyEINtdVzHC5tsMIxHznMdkgcNB6w6XHeVNA+UvlFrze0S7cyAZahgH67+oNIYE yDj7gxEUX+5n9Y+sq6fqMzF+NYwhrMH0RusyraG2dqvnmIAcWSxLLMKBu0eac4zoxG4E lSXw== X-Gm-Message-State: ALoCoQn5WSt4M4mSBkVSxWY+/jt/cRBZRGCmUM02Q8QsTrH9UaZaDPEfH46rO2vq0IUQeM49mYbp MIME-Version: 1.0 X-Received: by 10.52.241.106 with SMTP id wh10mr9950395vdc.16.1394900652635; Sat, 15 Mar 2014 09:24:12 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Sat, 15 Mar 2014 09:24:12 -0700 (PDT) X-Originating-IP: [24.84.235.32] Received: by 10.220.98.73 with HTTP; Sat, 15 Mar 2014 09:24:12 -0700 (PDT) In-Reply-To: <72u8i9dj6ih7o95cibq44o8kuq8k2dm40l@hive.bjoern.hoehrmann.de> References: <53238F21.2030508@cisco.com> <20140315143553.GC30147@mercury.ccil.org> <72u8i9dj6ih7o95cibq44o8kuq8k2dm40l@hive.bjoern.hoehrmann.de> Date: Sat, 15 Mar 2014 09:24:12 -0700 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a1133eb38e5d02e04f4a79def Archived-At: http://mailarchive.ietf.org/arch/msg/json/JhTZcGa7NbKcHEMi9ZAjs8nvKIg Cc: Matt Miller , John Cowan , json@ietf.org Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:24:22 -0000 --001a1133eb38e5d02e04f4a79def Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 15, 2014 9:17 AM, "Bjoern Hoehrmann" wrote: > > For human-readable documentation purposes it is entirely sufficient to > say "follows RFC XXXX conventions" and What is XXXX? implementations can just assume > the conventions are being followed until they detect otherwise (which > "I-JSON" implementations are required to do as currently proposed). > -- > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://= bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern= sworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w= ebsitedev.de/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --001a1133eb38e5d02e04f4a79def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 15, 2014 9:17 AM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote:

>
> For human-readable documentation purposes it is entirely sufficient to=
> say "follows RFC XXXX conventions" and

What is XXXX?

implementations can just assume
> the conventions are being followed until they detect otherwise (which<= br> > "I-JSON" implementations are required to do as currently pro= posed).
> --
> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.iet= f.org/mailman/listinfo/json

--001a1133eb38e5d02e04f4a79def-- From nobody Sat Mar 15 09:34:38 2014 Return-Path: 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 D359B1A00C3 for ; Sat, 15 Mar 2014 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XgLa5i6pPoR9 for ; Sat, 15 Mar 2014 09:34:35 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE11A00B1 for ; Sat, 15 Mar 2014 09:34:34 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so667804wib.9 for ; Sat, 15 Mar 2014 09:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KoSdlq0Sij+GWf1/P5v4fnOd3dmwALZAP+CPc5e/wM8=; b=Apf9hSXEMH/9WqeQHePpMpWfRqHJlOVwbMRskxBrb4gKM0C99Y2WTnjZLUwDDclJ2k fpzFOjykEeUgg+7jvFQ5hxl2mouCNMO8iFJspZ6XBS4GYpo3zdI/jKMDoXjwto8WD16f C0cdkmizx71fHPiOkaA78REBa5JJJWsNcg8nyoeqLpwebAjp6jhk9K8GW4HCUbg5I4iI j/oM1/L9B8cxY6Kx3Jenx/uDmboEvBtoyqyFgkEWqBQ1OgiyEU/b4cZ+2cMGrH0cPC8B mPaxZEejdQ3EVYDroxxZJ3hL1RpKu1CyudkcLjAqLtDxBgRotkqFBq89Q+qwJQzAUprY xoAA== MIME-Version: 1.0 X-Received: by 10.180.126.38 with SMTP id mv6mr2967563wib.46.1394901267442; Sat, 15 Mar 2014 09:34:27 -0700 (PDT) Received: by 10.227.245.10 with HTTP; Sat, 15 Mar 2014 09:34:27 -0700 (PDT) In-Reply-To: <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> References: <5FC8412F-30E5-4F80-AB63-6715B1053098@vpnc.org> <58a4b20f768b484c94a850c4eba71ec5@BL2PR02MB307.namprd02.prod.outlook.com> <53222FFC.8070204@cisco.com> <5322714F.6080508@it.aoyama.ac.jp> <3DE14AC0-BF6F-4BFB-AF47-53BD3513BA05@tzi.org> Date: Sat, 15 Mar 2014 16:34:27 +0000 Message-ID: From: Tatu Saloranta To: Carsten Bormann Content-Type: multipart/alternative; boundary=e89a8f839ccb8af1df04f4a7c248 Archived-At: http://mailarchive.ietf.org/arch/msg/json/HGUVn8PCjinMDv5Bcat1QeuwtmA Cc: Nico Williams , "json@ietf.org" , Matt Miller Subject: Re: [Json] serializing sequences of JSON values X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:34:37 -0000 --e89a8f839ccb8af1df04f4a7c248 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 14, 2014 at 11:01 PM, Carsten Bormann wrote: > > > On 14.03.2014, at 20:30, Tatu Saloranta wrote: > > On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams wrote: > >> The most interoperable form of JSON text sequence would be this: >> encoders MUST not use newlines in their JSON text encodings and MUST >> follow each JSON text with a newline. >> > > And presumably this would include all linefeeds that JSON specification > supports? (\r, \n and \r\n). > > > > I hope not. > > \r newlines no longer exist in the real world. > \r\n on the other hand is just a special case of \n, a sane parser can > then just key on \n. > I don't care deeply one way or another, but since I was assuming "of course those are accepted" (as per XML, or JSON parsers I'm familiar with), this needs to be specified to improve interoperability. -+ Tatu +- --e89a8f839ccb8af1df04f4a7c248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 14, 2014 at 11:01 PM, Carsten Bormann <cabo@tzi.or= g> wrote:


On 14.03.2= 014, at 20:30, Tatu Saloranta <tsaloranta@gmail.com> wrote:

On Fri, Mar 14, 2014 at 4:37 PM, Nico Williams <= span dir=3D"ltr"><nico@cryptonector.com> wrote:
The most interoperable form of JSON text seq= uence would be this:
encoders MUST not use newlines in their JSON text encodings and MUST
follow each JSON text with a newline.

And presumably this= would include all linefeeds that JSON specification supports? (\r, \n and = \r\n).


I hope not.

\r newlines no longer exist in the real world.
\r\n on the = other hand is just a special case of \n, a sane parser can then just key on= \n.

I don't care deeply one way or a= nother, but since I was assuming "of course those are accepted" (= as per XML, or JSON parsers I'm familiar with), this needs to be specif= ied to improve interoperability.

-+ Tatu +-

=A0
--e89a8f839ccb8af1df04f4a7c248-- From nobody Sat Mar 15 09:38:21 2014 Return-Path: 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 E03071A0159 for ; Sat, 15 Mar 2014 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 yytBdIqZJejs for ; Sat, 15 Mar 2014 09:38:13 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id AAF731A0165 for ; Sat, 15 Mar 2014 09:38:09 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WOraw-0001Da-Qg; Sat, 15 Mar 2014 12:37:58 -0400 Date: Sat, 15 Mar 2014 12:37:58 -0400 From: John Cowan To: Tim Bray Message-ID: <20140315163758.GC24343@mercury.ccil.org> References: <53238F21.2030508@cisco.com> <20140315143553.GC30147@mercury.ccil.org> <72u8i9dj6ih7o95cibq44o8kuq8k2dm40l@hive.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/qqGMOFKjsKUS2ufC_-HCQh2VyT8 Cc: json@ietf.org, Bjoern Hoehrmann , Matt Miller Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:38:17 -0000 Tim Bray scripsit: > > For human-readable documentation purposes it is entirely sufficient to > > say "follows RFC XXXX conventions" and > > What is XXXX? The as yet unassigned number for the I-JSON RFC. Bjoern is IIUC arguing against a new MIME type specific to I-JSON. -- If I read "upcoming" in [the newspaper] John Cowan once more, I will be downcoming http://www.ccil.org/~cowan and somebody will be outgoing. cowan@ccil.org From nobody Sat Mar 15 09:50:42 2014 Return-Path: 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 805BC1A016E for ; Sat, 15 Mar 2014 09:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 Z4JCXo_agJNC for ; Sat, 15 Mar 2014 09:50:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 839D81A016D for ; Sat, 15 Mar 2014 09:50:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2FGoRtb035685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 15 Mar 2014 09:50:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sat, 15 Mar 2014 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> To: IETF JSON WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/KiEgwxDyAVM3G26N6bYjKT3Az8Q Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:50:39 -0000 Here's a JSON format that could definitely use a simple JSON description = language of some sort. The draft authors went the ABNF route, and it's = completely unclear where they are going until you look at the examples = and realize how trivial the format really is. http://tools.ietf.org/html/draft-dulaunoy-kaplan-passive-dns-cof --Paul Hoffman= From nobody Sat Mar 15 10:01:36 2014 Return-Path: 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 7B9401A00F9 for ; Sat, 15 Mar 2014 10:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 ex3vHjzpI3UV for ; Sat, 15 Mar 2014 10:01:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0CE1A0156 for ; Sat, 15 Mar 2014 10:01:28 -0700 (PDT) Received: from netb ([89.204.139.147]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mdrph-1WmKcY0BLR-00PccU; Sat, 15 Mar 2014 18:01:17 +0100 From: Bjoern Hoehrmann To: John Cowan Date: Sat, 15 Mar 2014 18:01:16 +0100 Message-ID: <2j19i95f0hkm2aef74l3vaqp3qo6epbua8@hive.bjoern.hoehrmann.de> References: <53238F21.2030508@cisco.com> <20140315143553.GC30147@mercury.ccil.org> <72u8i9dj6ih7o95cibq44o8kuq8k2dm40l@hive.bjoern.hoehrmann.de> <20140315163758.GC24343@mercury.ccil.org> In-Reply-To: <20140315163758.GC24343@mercury.ccil.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9K2iwevM5fI25Pa/xhEl7uYUEeZJvg/FYcUunXPtXmgd9BnQnCi gaq9hWWS23ITB72hV+Ddc6EW9fifYmwczhlawgb5fmAG988cdDcx7+XVKvG7DTHkoqkTg41 Gm8R/Y3trJLM4ue28UhdujORmSOHNbpGa9FlmbvvAfqqH+Q1FQG2uhgs3xkZLewknHlw2ku k9D9axiyQ1/yWamKCSHQg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/CpVmKsAm1qr28-OFXJHeFKBg2nc Cc: Matt Miller , Tim Bray , json@ietf.org Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:01:32 -0000 * John Cowan wrote: >Tim Bray scripsit: > >> > For human-readable documentation purposes it is entirely sufficient to >> > say "follows RFC XXXX conventions" and >> >> What is XXXX? > >The as yet unassigned number for the I-JSON RFC. Bjoern is IIUC arguing >against a new MIME type specific to I-JSON. Yes, and also against inline identifiers and the name "I-JSON" (or any other name) and anything else that makes avoiding the things the JSON RFC says are an interoperability problem appear a format on its own. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Sat Mar 15 10:03:35 2014 Return-Path: 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 46A201A0139 for ; Sat, 15 Mar 2014 10:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 ok5whD1bnijg for ; Sat, 15 Mar 2014 10:03: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 7254C1A00F9 for ; Sat, 15 Mar 2014 10:03: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.5/8.14.5) with ESMTP id s2FH3KcF017877; Sat, 15 Mar 2014 18:03:20 +0100 (CET) Received: from [192.168.217.105] (p548923DB.dip0.t-ipconnect.de [84.137.35.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 271C4410; Sat, 15 Mar 2014 18:03:19 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> Date: Sat, 15 Mar 2014 18:03:17 +0100 X-Mao-Original-Outgoing-Id: 416595797.791958-03ad7fd4002fe2a0569a6b97c4c5995b Content-Transfer-Encoding: quoted-printable Message-Id: <619B38E7-B8FD-4640-97A8-B523AF655B9E@tzi.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/L_FKme0KWfYro7ldIeReBl3_Nq8 Cc: IETF JSON WG Subject: [Json] Do not use ABNF for JSON schemas! X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:03:32 -0000 On 15 Mar 2014, at 17:50, Paul Hoffman wrote: > Here's a JSON format that could definitely use a simple JSON = description language of some sort. The draft authors went the ABNF = route, and it's completely unclear where they are going until you look = at the examples and realize how trivial the format really is. One extremely useful result this WG could have is eliciting an IESG = statement that ABNF representations of JSON schemas are verboten. Gr=FC=DFe, Carsten From nobody Sat Mar 15 10:28:41 2014 Return-Path: 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 7AF331A0161 for ; Sat, 15 Mar 2014 10:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 47lCjslTSAP7 for ; Sat, 15 Mar 2014 10:28:38 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6981A00F9 for ; Sat, 15 Mar 2014 10:28:38 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ec20so2668815lab.29 for ; Sat, 15 Mar 2014 10:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I4cWWEPXh8d8J+VludHWi3wIJFQkrQISTwKrcqYJrEY=; b=cR6SdwjwHIxwyn/ZzzbjjFzPJQHQjzzX0zLvQtJE8ICSpFTK0ALUI7FG5D8+bGvl1f ZgIVH9sJ8Es3ONtuWP10Fy5nC3Sc4HHX/xhqtH1FmJ2B9Q7kEgtZthI16+mR2IhB4ouZ H+29LM7G0hzg1LMI5oLSwtGGoOrny7equfJ8H4ijYv6ROWZ9LUyzrJ8GWVXWA57mYmJo i9Q8JZCzp5IDHYZSN9jhihmXleLE1zT/w0lT7Xdej6Khi5H54ROpHQdmakQVWEog+CQB h/Qm2nU9TrufpRUHUhVZ+pZem4uEg/Woryx38ptBqNnex88HEnR2aY3TbTVQn8vTLu5u bADQ== MIME-Version: 1.0 X-Received: by 10.152.20.1 with SMTP id j1mr53720lae.83.1394904510345; Sat, 15 Mar 2014 10:28:30 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sat, 15 Mar 2014 10:28:30 -0700 (PDT) In-Reply-To: <724C698D-7E06-452E-A11F-31DA794C3A28@vpnc.org> References: <724C698D-7E06-452E-A11F-31DA794C3A28@vpnc.org> Date: Sat, 15 Mar 2014 13:28:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013d1d4cd5b8d004f4a883db Archived-At: http://mailarchive.ietf.org/arch/msg/json/eMTejj6AvT6XXS3h7kvsp2Ep4Pg Cc: JSON WG Subject: Re: [Json] Modularity and composition X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:28:40 -0000 --089e013d1d4cd5b8d004f4a883db Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 15, 2014 at 11:18 AM, Paul Hoffman wrote: > On Mar 15, 2014, at 7:06 AM, Phillip Hallam-Baker > wrote: > > > I strongly support removing the namespace parameter for I-JSON. > > Please note that the consensus call was for the -01 draft, which has no > namespace. If the WG adopts the work, it would start with the -01 draft, > and the call indicated. > And I want it to stay that way. At the moment I-JSON is a strict subset of JSON which is useful. If people add in extensions then the point is lost because people who want the subset may not want the extensions. We can come to agreement on what I-JSON should look like pretty easily. But coming to agreement on how to make JSON modular is a much bigger piece of work and that needs to be considered separately. -- Website: http://hallambaker.com/ --089e013d1d4cd5b8d004f4a883db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 15, 2014 at 11:18 AM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
On Mar 15, 2014, at 7:06 AM,= Phillip Hallam-Baker <hallam@gmail.= com> wrote:

> I strongly support removing the namespace parameter for I-JSON.

Please note that the consensus call was for the -01 draft, which has = no namespace. If the WG adopts the work, it would start with the -01 draft,= and the call indicated.

And I want it = to stay that way.

At the moment I-JSON is a strict subset of JSON which i= s useful. If people add in extensions then the point is lost because people= who want the subset may not want the extensions.=A0

We can come to agreement on what I-JSON should look like pretty = easily. But coming to agreement on how to make JSON modular is a much bigge= r piece of work and that needs to be considered separately.

--
Website: http://hallambake= r.com/
--089e013d1d4cd5b8d004f4a883db-- From nobody Sat Mar 15 10:33:17 2014 Return-Path: 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 5E18A1A0179 for ; Sat, 15 Mar 2014 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 d3sK8S_Zzr1X for ; Sat, 15 Mar 2014 10:33:14 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3511A0166 for ; Sat, 15 Mar 2014 10:33:14 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so2550616lbg.25 for ; Sat, 15 Mar 2014 10:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O5TZ/rQ8Qa5c4oDNpKr+Odo+q3n9Yc5qeNqMJnXqInM=; b=So21Gh5/0O9Vd1wHl4bDyd17yW9VebedD+iV4zRGily0I8Xp/d3Qa5ybXl+1LXWrVA uekCvTlGcnOdd7v5fyoTRAlvETieqyHKIRZtBdRGuNmQgnsEc3DcwfBB8cMLAskPyM2I +Lm0pzv2G//55Bje3BKN1Qug65BmGTDnFcqx84DwaiuEqWPmXKOou/fjzVc2QIVRY5LY ugaa8C4j7VcQbru6yV5bdKDXfQWcz3LkSvHV9u9XezJepMyyFI6PhQk/Jxh6jQekTiCQ w5rxMOWKXdh78xQJY0qpMmsEJp9JkuEu8VGwD9Enf5J86sQ4m6AMjOgalYvcdk9mGQB8 uXOg== MIME-Version: 1.0 X-Received: by 10.112.169.10 with SMTP id aa10mr45482lbc.72.1394904786498; Sat, 15 Mar 2014 10:33:06 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sat, 15 Mar 2014 10:33:06 -0700 (PDT) In-Reply-To: <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> Date: Sat, 15 Mar 2014 13:33:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c385e04b7bde04f4a89460 Archived-At: http://mailarchive.ietf.org/arch/msg/json/X4Uvy11J75mq_kYgK-mlPM_BZ5Q Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:33:16 -0000 --001a11c385e04b7bde04f4a89460 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 15, 2014 at 12:50 PM, Paul Hoffman wrote: > Here's a JSON format that could definitely use a simple JSON description > language of some sort. The draft authors went the ABNF route, and it's > completely unclear where they are going until you look at the examples and > realize how trivial the format really is. > > http://tools.ietf.org/html/draft-dulaunoy-kaplan-passive-dns-cof Yuk. ABNF should be reserved for describing an encoding scheme. I am pretty unhappy with the way it is used in RFC2822 and in HTTP. The designer of each header has complete flexibility to choose whatever whacky encoding scheme they like. Remember that standards are agreements on stuff that does not matter. Whether the tag is encoded one way or the other does not matter. But once a choice is made, the spec should stick to it. -- Website: http://hallambaker.com/ --001a11c385e04b7bde04f4a89460 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 15, 2014 at 12:50 PM, Paul Hoffman &l= t;paul.hoffman@v= pnc.org> wrote:
Here's a JSON format that could definite= ly use a simple JSON description language of some sort. The draft authors w= ent the ABNF route, and it's completely unclear where they are going un= til you look at the examples and realize how trivial the format really is.<= br>
http://tools.ietf.org/html/draft-dulaunoy-kaplan-passiv= e-dns-cof

Yuk.

ABNF should be reserved for describing an encoding scheme. I am pretty unha= ppy with the way it is used in RFC2822 and in HTTP. The designer of each he= ader has complete flexibility to choose whatever whacky encoding scheme the= y like.
=A0
Remember that standards are agreements on stuff tha= t does not matter. Whether the tag is encoded one way or the other does not= matter. But once a choice is made, the spec should stick to it.


--
Website: http://hallambaker.com/
--001a11c385e04b7bde04f4a89460-- From nobody Sat Mar 15 10:59:31 2014 Return-Path: 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 9CC881A017D for ; Sat, 15 Mar 2014 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 OXhJ8EobywdR for ; Sat, 15 Mar 2014 10:54:12 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1EC1A017B for ; Sat, 15 Mar 2014 10:54:12 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id t10so2586732eei.28 for ; Sat, 15 Mar 2014 10:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jsonified.com; s=google; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:content-transfer-encoding:content-disposition; bh=gyOMUbgBFGggqqTJ9dACGO4SEo1i2nG5bwftfGeg0VE=; b=F7efgTDVkXUQdWLuKbhagN9efHwpo41h0KWpsijBPV1NZB+gM50UVfa3zYTkStyv30 /ArRD9atJCq1IU854uhGh/sTolDgTO0qgmGQN8LuGgYkQORCZ+nJS71PoTo7f2lh/TQP Bs9NegYGjLr0bsqIqDp28JdIJ33pGZrnNKJ5A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=gyOMUbgBFGggqqTJ9dACGO4SEo1i2nG5bwftfGeg0VE=; b=SD241zTI2qq1blahwm6yPlSdD1HJxOPbWmzOfXB9QiHVj+CU5EGgh+dBJRDKuC0Eaf B1CJdnWbBTTTxyVgRu5FYWA6hhR9JrvrTo/c1yS3Xvu9eixMGlBKGSTW+k0guqNibFC0 r2W7NjjzCLdMM60Yi3WYziuxip/ON1vBQJi0vZ8XfNYbkrHbe3fJneMQnsLy1QtNfJug EWOB5qHNp0fZsBbx7xB5+tMPzXYMx2nhtJAR3rZBhClmaFmz6g/lhgP6wsQCiAwK+cxr BD8Ta0d5C7hGgtCRYuUM4NaonWtw2E9OXZi27G8PnM2Rez+XuNk8GeEUuc5YFaFXrMF+ s3Hw== X-Gm-Message-State: ALoCoQkm8893sfnuQObozPIFMs0qPla4EqETfPIm/7PrOkQlfok8lugqFCAHikLluzCE40RGBeV+ X-Received: by 10.14.148.134 with SMTP id v6mr45190eej.115.1394906044837; Sat, 15 Mar 2014 10:54:04 -0700 (PDT) Received: from akai.jsonified.com (chello084112019176.2.11.vie.surfer.at. [84.112.19.176]) by mx.google.com with ESMTPSA id 43sm26215426eeh.13.2014.03.15.10.54.03 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 10:54:04 -0700 (PDT) Date: Sat, 15 Mar 2014 18:53:56 +0100 From: Dave Cottlehuber To: IETF JSON WG Message-ID: In-Reply-To: <53238F21.2030508@cisco.com> References: <53238F21.2030508@cisco.com> X-Mailer: Airmail Beta (233) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/json/df-W2UTW4ZfpTSabNzemtmep2_s X-Mailman-Approved-At: Sat, 15 Mar 2014 10:59:29 -0700 Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:54:15 -0000 On 15. M=C3=A4rz 2014 at 00:22:16, Matt Miller (mamille2=40cisco.com) wro= te: > The chairs are seeking comment on whether we should adopt I-JSON > (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our > charter. Remember that adopting this draft does not mean it is done; > changes can happen based on the consensus of the WG. +1 yes please. > Note that the current draft does *not* have the new MIME type nor the > reserved field name that was heavily debated in London; that could be > added later if there is WG consensus to do so. =46WIW I attended the =46riday session in London; my main concern was hav= ing an interoperable approach that *didn=E2=80=99t* require developing an= =C2=A0application/XXX+i-json for each application.=C2=A0 -- =20 Dave Cottlehuber Sent from my PDP11 From nobody Sat Mar 15 11:09:37 2014 Return-Path: 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 58CBC1A0180 for ; Sat, 15 Mar 2014 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ddj7m1riE7X4 for ; Sat, 15 Mar 2014 11:09:32 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id B62FF1A017D for ; Sat, 15 Mar 2014 11:09:32 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id cz12so4065436veb.2 for ; Sat, 15 Mar 2014 11:09:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tjaN37+R3I0yVGxfIQr7pbfCZ0nLDNrMPW2X1kPFpyY=; b=HVF0IEQ3CwmlaBntfb4N6KMlHh2auT9F8pbJ2zrMHdGQ++afhpvxq3EC4kAOCKD7qD Z6EoD89JMFRghxYKWAO5MeJwGVCRynkGjTpVujHnD0jC3uDaMaoY6iD76c4Sc54KL/vB u7n8fEU1BZyqlFu2StS9l1rYPtrtJlwt2lVXJl0ZBXMAU+uSG4MK3+vsf26KaRNbXWCB 6ofZ05kLNy5UZwcXuekH4jsDUlYPyOsQMZQHtA3h2G8ZA46zvHGv+eVOBA/V3EyqpKzo F8nhesbUE0NIZNgvkKfuQJCXYCG5P0NbaNgYeGh98UuyorOu44hgGuw9ZAd+8135hyRg 86hg== X-Gm-Message-State: ALoCoQnpBYsFV9CFW+bmj3Bnqpy2u0UVTAqOWljPwHoMW0OLn7+QiLiQfBLGEamW/Ccu/Clwolup MIME-Version: 1.0 X-Received: by 10.58.38.166 with SMTP id h6mr1513565vek.22.1394906965121; Sat, 15 Mar 2014 11:09:25 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Sat, 15 Mar 2014 11:09:25 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> Date: Sat, 15 Mar 2014 11:09:25 -0700 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013a0d4026e19004f4a91622 Archived-At: http://mailarchive.ietf.org/arch/msg/json/9gUXtY5O2YF3x7FCyM7Vp93SFIs Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 18:09:35 -0000 --089e013a0d4026e19004f4a91622 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That I-D would be greatly improved by tossing the ABNF and just using English, saying what the names of the fields and the allowed values for them are. =E2=80=9CBetter than ABNF=E2=80=9D isn=E2=80=99t what we=E2=80= =99re trying for; =E2=80=9CBetter than reasonably-well-edited English=E2=80=9D is. I still haven=E2=80=99t seen a= n example where a schema language would meet that criterion. Seriously, if nobody can find an example where schema/nomenclature would actually improve a real existing non-hypothetical document, I think it would be silly for the WG to proceed with inventing a solution to a non-problem. Also, that I-D does something else that seems really wrong: Says that the the JSON objects must be expressed on a single line. Hmmm -T On Sat, Mar 15, 2014 at 9:50 AM, Paul Hoffman wrote= : > Here's a JSON format that could definitely use a simple JSON description > language of some sort. The draft authors went the ABNF route, and it's > completely unclear where they are going until you look at the examples an= d > realize how trivial the format really is. > > http://tools.ietf.org/html/draft-dulaunoy-kaplan-passive-dns-cof > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013a0d4026e19004f4a91622 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tha= t I-D would be greatly improved by tossing the ABNF and just using English,= saying what the names of the fields and the allowed values for them are. = =C2=A0=E2=80=9CBetter than ABNF=E2=80=9D isn=E2=80=99t what we=E2=80=99re t= rying for; =E2=80=9CBetter than reasonably-well-edited English=E2=80=9D is.= =C2=A0I still haven=E2=80=99t seen an example where a schema language woul= d meet that criterion.

Seriously, if nobody can find = an example where schema/nomenclature would actually improve a real existing= non-hypothetical document, I think it would be silly for the WG to proceed= with inventing a solution to a non-problem.

Also, that I-D does something = else that seems really wrong: Says that the the JSON objects must be expres= sed on a single line. =C2=A0Hmmm

=C2=A0-T


On Sat, Mar 15, 2014 at= 9:50 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Here's a JSON format that could definite= ly use a simple JSON description language of some sort. The draft authors w= ent the ABNF route, and it's completely unclear where they are going un= til you look at the examples and realize how trivial the format really is.<= br>
http://tools.ietf.org/html/draft-dulaunoy-kaplan-passiv= e-dns-cof

--Paul Hoffman
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e013a0d4026e19004f4a91622-- From nobody Sat Mar 15 11:11:01 2014 Return-Path: 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 EE1881A0186 for ; Sat, 15 Mar 2014 11:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 atwQkNlZ5qMA for ; Sat, 15 Mar 2014 11:10:57 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F21A017D for ; Sat, 15 Mar 2014 11:10:57 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jz11so4004755veb.25 for ; Sat, 15 Mar 2014 11:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DoumYGEJ6l5hkDCnJtf9KSOHHmGdzIRpKA4+ZT41itc=; b=TqDb1vKVNrtZO0Tbdh1cQgLa0L10sgOfMEJTK0k7rvB6PraCGg8mAvP0G4gXc3C4UX arzfg14y0t7ER4cZQLJ0N7ko75FsBqfmp3rj0/xioD4cgh5XtqMozJXcU2YIlwGFpw2E ltumKHOTkMmj6KEf6MrwvFAUV6RveHdB0n9d8Q5+XMJsxQgZ2UP5MqsUdemP35m3Un5n Gms30M0W+m8bVjAaPxlDjAR8luCTUTx4YYmMuKwjvOT6+et+t8rtSCWp66MZl0zstHbL 28J0RA+Qmn+e9GfvgSHEz88IM9N13xodXNUGfrmfA4+LYFgU4HfLPALUguViDUXoNdxW 4m5A== X-Gm-Message-State: ALoCoQlLluVCFLQ/iVwQWD4OtzOJkfL8x+x25QQd68qFZtcQnPl4rBoEmqpzHkRPs3qEelQGyD94 MIME-Version: 1.0 X-Received: by 10.52.113.1 with SMTP id iu1mr105806vdb.35.1394907049589; Sat, 15 Mar 2014 11:10:49 -0700 (PDT) Received: by 10.220.98.73 with HTTP; Sat, 15 Mar 2014 11:10:49 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <619B38E7-B8FD-4640-97A8-B523AF655B9E@tzi.org> References: <53238F2E.5010105@cisco.com> <420F0699-9F27-435E-924C-28966A743EAF@vpnc.org> <890D8059-2280-48D5-820B-2E75852AF334@vpnc.org> <619B38E7-B8FD-4640-97A8-B523AF655B9E@tzi.org> Date: Sat, 15 Mar 2014 11:10:49 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=bcaec547c6232f915404f4a91b5b Archived-At: http://mailarchive.ietf.org/arch/msg/json/jjcSIeIoratzYHT4yrTkM02d9cQ Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Do not use ABNF for JSON schemas! X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 18:10:59 -0000 --bcaec547c6232f915404f4a91b5b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Sat, Mar 15, 2014 at 10:03 AM, Carsten Bormann wrote: > On 15 Mar 2014, at 17:50, Paul Hoffman wrote: > > > Here's a JSON format that could definitely use a simple JSON descriptio= n > language of some sort. The draft authors went the ABNF route, and it's > completely unclear where they are going until you look at the examples an= d > realize how trivial the format really is. > > One extremely useful result this WG could have is eliciting an IESG > statement that ABNF representations of JSON schemas are verboten. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec547c6232f915404f4a91b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1<= /div>


On= Sat, Mar 15, 2014 at 10:03 AM, Carsten Bormann <cabo@tzi.org> wr= ote:
On 15 Mar 2014, at 17:50, Paul Hoffman <<= a href=3D"mailto:paul.hoffman@vpnc.org">paul.hoffman@vpnc.org> wrote= :

> Here's a JSON format that could definitely use a simple JSON descr= iption language of some sort. The draft authors went the ABNF route, and it= 's completely unclear where they are going until you look at the exampl= es and realize how trivial the format really is.

One extremely useful result this WG could have is eliciting an IESG stateme= nt that ABNF representations of JSON schemas are verboten.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--bcaec547c6232f915404f4a91b5b-- From nobody Sat Mar 15 12:41:36 2014 Return-Path: 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 891B01A01BF for ; Sat, 15 Mar 2014 12:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 GtMN0GUJjD8N for ; Sat, 15 Mar 2014 12:41:31 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 54A9B1A01BC for ; Sat, 15 Mar 2014 12:41:31 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WOuSR-0002qw-4f; Sat, 15 Mar 2014 15:41:23 -0400 Date: Sat, 15 Mar 2014 15:41:23 -0400 From: John Cowan To: Nico Williams Message-ID: <20140315194123.GG24343@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/29HKRF0h6V2J8Ofo6msc9I602A0 Cc: "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 19:41:33 -0000 Nico Williams scripsit: > Just submitted. 1) Your terminology of "online parsers" and "incremental parsers" is very confusing. What you call an "online parser", I would call a "streaming parser", because it returns portions of arrays, objects, and possibly even strings as a stream of events. Your "incremental parser" is simply a parser that stops reading when it reaches the end of a JSON text without insisting that there be no additional characters. 2) The sentence "Encoders MUST emit" should refer explicitly to the grammar. Currently the grammar is completely unmoored from the requirements. "Encoders MUST emit JSON text sequences that conform to the ABNF" is sufficient. 3) The sentence "Two contiguous separators do not" is unnecessary, because there are no empty JSON texts. 4) In "Parsers MUST be able", for "to parser" read "to parse". But as in #2, this should simply say "Parsers MUST be able to parse any text conforming to the ABNF" for the same reasons. 5) The recommendation seems entirely unnecessary to me. 6) I still don't see that there is any ambiguity in "truefalse" considered as two JSON-texts. So I would strip "Parsers MAY parse" to just say "sequences where the separators are missing." Note that such sequences don't conform anyway. 7) If you want newline-free JSON-texts to be in serious use, the second MAY should be promoted to a SHOULD. -- "The serene chaos that is Courage, and the phenomenon cowan@ccil.org of Unopened Consciousness have been known to the John Cowan Great World eons longer than Extaboulism." "Why is that?" the woman inquired. "Because I just made that word up", the Master said wisely. --Kehlog Albran, The Profit http://www.ccil.org/~cowan From nobody Sat Mar 15 13:53:16 2014 Return-Path: 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 A54D41A01B9 for ; Sat, 15 Mar 2014 13:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 xjdL0ZQQ6M45 for ; Sat, 15 Mar 2014 13:53:12 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E81FA1A01A0 for ; Sat, 15 Mar 2014 13:53:11 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so2649241lan.26 for ; Sat, 15 Mar 2014 13:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=npM/82OD5Jqx1m268m+SgvC9v7XWrydvUwKcoek4gxI=; b=BInTm8Mn2lNNXICVuNroM2Sa0Ex3yIYFrPZAH7SOtGDyoouCF634LXpQ2FnURGIXal AmUNND7KWF6KRVZlwBHD4v0biyCazom2mhHCUN4GI5h+Jet1EVVfgqD8GCjKLXV+91i8 hhZMb1Yo5B0qgtugJA7xHzuMU/qRdmec/N2vi3yhJsym2mqiJbjFSygNtmqzLT7N3koZ RNKLy/DALGi/9/igXDbV36tGuisGNqZAnIrFaUvau/VscZkmSzwf1FKcyfX1BO0ns+VB wurvDFSW9ORsJHqT4aGZz2TZRk7DvjcE9HYndlFmJkkdMCh9rvytwV+gl6hYXjuf/T1b 5oiw== MIME-Version: 1.0 X-Received: by 10.152.7.8 with SMTP id f8mr122097laa.39.1394916783886; Sat, 15 Mar 2014 13:53:03 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sat, 15 Mar 2014 13:53:03 -0700 (PDT) In-Reply-To: <20140315194123.GG24343@mercury.ccil.org> References: <20140315194123.GG24343@mercury.ccil.org> Date: Sat, 15 Mar 2014 16:53:03 -0400 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=001a11c2a0f46515e104f4ab5faa Archived-At: http://mailarchive.ietf.org/arch/msg/json/lLiY9AshHPfoyS0RZ2lTP3Nedww Cc: Nico Williams , "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 20:53:14 -0000 --001a11c2a0f46515e104f4ab5faa Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 15, 2014 at 3:41 PM, John Cowan wrote: > Nico Williams scripsit: > > > Just submitted. > > 1) Your terminology of "online parsers" and "incremental parsers" > is very confusing. What you call an "online parser", I would call a > "streaming parser", because it returns portions of arrays, objects, and > possibly even strings as a stream of events. Your "incremental parser" > is simply a parser that stops reading when it reaches the end of a JSON > text without insisting that there be no additional characters. > > 2) The sentence "Encoders MUST emit" should refer explicitly to > the grammar. Currently the grammar is completely unmoored from the > requirements. "Encoders MUST emit JSON text sequences that conform to > the ABNF" is sufficient. > > 3) The sentence "Two contiguous separators do not" is unnecessary, > because there are no empty JSON texts. > > 4) In "Parsers MUST be able", for "to parser" read "to parse". But as > in #2, this should simply say "Parsers MUST be able to parse any text > conforming to the ABNF" for the same reasons. > > 5) The recommendation seems entirely unnecessary to me. > > 6) I still don't see that there is any ambiguity in "truefalse" considered > as two JSON-texts. So I would strip "Parsers MAY parse" to just say > "sequences where the separators are missing." Note that such sequences > don't conform anyway. > > 7) If you want newline-free JSON-texts to be in serious use, the second > MAY should be promoted to a SHOULD. I am thinking that the best way to show off JSON sequence would be to update this draft from '96 http://www.w3.org/TR/WD-logfile.html It is a widely used format but it has problems, every entry has to specify entries for precisely the set of data advertised at the start. I am thinking of redoing the spec in JSON using the same tags to identify the data elements. -- Website: http://hallambaker.com/ --001a11c2a0f46515e104f4ab5faa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Mar 15, 2014 at 3:41 PM, John Cowan <<= a href=3D"mailto:cowan@mercury.ccil.org" target=3D"_blank">cowan@mercury.cc= il.org> wrote:
Nico Williams scripsit:

> Just submitted.

1) Your terminology of "online parsers" and "incremental par= sers"
is very confusing. =A0What you call an "online parser", I would c= all a
"streaming parser", because it returns portions of arrays, object= s, and
possibly even strings as a stream of events. =A0Your "incremental pars= er"
is simply a parser that stops reading when it reaches the end of a JSON
text without insisting that there be no additional characters.

2) The sentence "Encoders MUST emit" should refer explicitly to the grammar. =A0Currently the grammar is completely unmoored from the
requirements. =A0"Encoders MUST emit JSON text sequences that conform = to
the ABNF" is sufficient.

3) The sentence "Two contiguous separators do not" is unnecessary= ,
because there are no empty JSON texts.

4) In "Parsers MUST be able", for "to parser" read &quo= t;to parse". =A0But as
in #2, this should simply say "Parsers MUST be able to parse any text<= br> conforming to the ABNF" for the same reasons.

5) The recommendation seems entirely unnecessary to me.

6) I still don't see that there is any ambiguity in "truefalse&quo= t; considered
as two JSON-texts. =A0So I would strip "Parsers MAY parse" to jus= t say
"sequences where the separators are missing." =A0Note that such s= equences
don't conform anyway.

7) If you want newline-free JSON-texts to be in serious use, the second
MAY should be promoted to a SHOULD.

I am th= inking that the best way to show off JSON sequence would be to update this = draft from '96


It is a widely used format but it has problems, every e= ntry has to specify entries for precisely the set of data advertised at the= start.

I am thinking of redoing the spec in JSON = using the same tags to identify the data elements.=A0


--
Website: http://hallambaker.com/
--001a11c2a0f46515e104f4ab5faa-- From nobody Sun Mar 16 00:49:58 2014 Return-Path: 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 0EC931A0054 for ; Sun, 16 Mar 2014 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 chOUfvnhP3a6 for ; Sun, 16 Mar 2014 00:49:54 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (agjbgdcfdbfc.dreamhost.com [69.163.253.152]) by ietfa.amsl.com (Postfix) with ESMTP id B45101A004A for ; Sun, 16 Mar 2014 00:49:54 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 7053B2005D103 for ; Sun, 16 Mar 2014 00:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hqHIjuvmY4dne2oGv8ib 39qVG2E=; b=BkXZEWyA83QQt8gzqHDzQ0TnIAcfcGI46+ib9LuZKri6STBruSBx 0VI+UCMm6/yzAcxUrnUVZosJImvo8RWTv0VY8BBgB3ZGDE6zklmnXAasLrGYgQBG kDwaedUIs7OkHSxWo3xdLFMBPYaZN12MCxuCDS4yY+XTkCqAo2j5El8= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 25A8C2005D102 for ; Sun, 16 Mar 2014 00:49:46 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so1009900wiv.13 for ; Sun, 16 Mar 2014 00:49:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RLwzB5rL/NVyz/Gct8qmsl4M3yqVSWspr2JWzFxsjBc=; b=WLNL/XTIm8TFlrLAXGszseZg1wIPPoTiQ2zdIEotXbAvpWZ+0LzR9CsYogv37I4Dt4 m7/68dlt6pUssvdP/13FotyDeIFb3Sazn8CcsVR1LNUY6IPbcSx+Jak00Idrt3m0Rgz4 05pp+jeQVJsJ/PVns76y2L8aX9Z34giU5WnICZOg5F504HpHiqc02ooETLbPltrZjv9d AFc+ePh84T8o9Z2MWg+fMJkZ6PWOnI5n1cHffc2lvYvrC3rEAmGXolQoN8B9A2O1egNG gFtqQYDRJ2m/6Upc61Dcs9xMO+8zN64TSA1cmCnMoFAiRlAHfYiTRC4Ad1azogeIO2b5 vovg== MIME-Version: 1.0 X-Received: by 10.194.48.100 with SMTP id k4mr540170wjn.49.1394955841504; Sun, 16 Mar 2014 00:44:01 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 16 Mar 2014 00:44:01 -0700 (PDT) In-Reply-To: <20140315194123.GG24343@mercury.ccil.org> References: <20140315194123.GG24343@mercury.ccil.org> Date: Sun, 16 Mar 2014 02:44:01 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/cg5gNdBN7jsu4sTTmBbXbSFTMrg Cc: "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 07:49:56 -0000 On Sat, Mar 15, 2014 at 2:41 PM, John Cowan wrote: > > 1) Your terminology of "online parsers" and "incremental parsers" > is very confusing. What you call an "online parser", I would call a > "streaming parser", because it returns portions of arrays, objects, and > possibly even strings as a stream of events. Your "incremental parser" > is simply a parser that stops reading when it reaches the end of a JSON > text without insisting that there be no additional characters. Oops, in an earlier version (not submitted) I defined these terms, but after someone made a convincing argument to not require that texts not have embedded newlines... I removed it. I didn't remove the remaining references to online/incremental parsers. > 2) The sentence "Encoders MUST emit" should refer explicitly to > the grammar. Currently the grammar is completely unmoored from the > requirements. "Encoders MUST emit JSON text sequences that conform to > the ABNF" is sufficient. True. Also a remnant of an earlier version. I'll fix this too. > 3) The sentence "Two contiguous separators do not" is unnecessary, > because there are no empty JSON texts. I know this. I just figure someone will wonder if I don't say it. > 4) In "Parsers MUST be able", for "to parser" read "to parse". But as > in #2, this should simply say "Parsers MUST be able to parse any text > conforming to the ABNF" for the same reasons. Sure. > 5) The recommendation seems entirely unnecessary to me. Well, it's superfluous if encoders must adhere to the ABNF, that's true. > 6) I still don't see that there is any ambiguity in "truefalse" considered > as two JSON-texts. So I would strip "Parsers MAY parse" to just say > "sequences where the separators are missing." Note that such sequences > don't conform anyway. It's true that 'trusfalse' does not conform to the ABNF, therefore it's not a legal sequence. Removing the options (and recommendation) would suffice. > 7) If you want newline-free JSON-texts to be in serious use, the second > MAY should be promoted to a SHOULD. I no longer do. I wasn't ever sure that was a good idea either. Nico -- From nobody Sun Mar 16 00:53:10 2014 Return-Path: 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 E991D1A0062 for ; Sun, 16 Mar 2014 00:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 iZ9OaIaZsVyH for ; Sun, 16 Mar 2014 00:53:08 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (agjbgdcfdbhb.dreamhost.com [69.163.253.171]) by ietfa.amsl.com (Postfix) with ESMTP id EA73E1A004A for ; Sun, 16 Mar 2014 00:53:07 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 9805C438079 for ; Sun, 16 Mar 2014 00:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hDbwRcmxQ1ClAMq/U/6r U8X6MGw=; b=fNuuSzbbdS0Yrn+MP9kN6it5JtR7wJF/q5LdMvbWyoT894bgmmH/ EfKfZRUPrNGVS89k5XFSMkPTMyBW6l5LPWjmnFq5uhIPleXg7Im+xmJD/M5OXr/a IHHcDwP4ru4PBt2i21pc70B+iJSf8OjmOacU0/9waKrWiCHT8Z0psV4= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 4CA26438072 for ; Sun, 16 Mar 2014 00:53:00 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1015218wiw.6 for ; Sun, 16 Mar 2014 00:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VgYrGjZ39PtXMKekYIX6MQXC7n1SGGQqC4eUOPdvsAw=; b=OBn5D6kO/YMjZlel+VXSsukFb4YMhejrYhAQcpKTsmmkcFZspvtqM/eUfl5Mr2+MON 71+PuvQ2mSr2YYq/k2k3G050hTG3p7OT8VnzgHQtKcxBD2d2POXNFJLM7Ml++gnmMbyE yzvKOAC6A+8iQH1ioJRxGA/Mwndsl0NrME0xC6Hr4c9X1+glc5HY8d9XAL7Y/8ixO7Tf O9oiyXW8XcWVjLQqQ57yMvUzvSvoPwHV8DKIj5hzWIIcRN8aGSy6rZlYs8oWKw35c+BH BeTgGhFArIIyx4th4QZqgvlQL2uWLWh07t6V6od1qJt3a1/EmUVe0JLAR2P7md6Dn6Mb YtKA== MIME-Version: 1.0 X-Received: by 10.194.87.195 with SMTP id ba3mr532944wjb.53.1394956379160; Sun, 16 Mar 2014 00:52:59 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 16 Mar 2014 00:52:59 -0700 (PDT) In-Reply-To: References: <20140315194123.GG24343@mercury.ccil.org> Date: Sun, 16 Mar 2014 02:52:59 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/R9wvA5xJ22D1EJApIxsd0L8JBjM Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 07:53:09 -0000 On Sat, Mar 15, 2014 at 3:53 PM, Phillip Hallam-Baker wrote: > I am thinking that the best way to show off JSON sequence would be to update > this draft from '96 > > http://www.w3.org/TR/WD-logfile.html > > It is a widely used format but it has problems, every entry has to specify > entries for precisely the set of data advertised at the start. > > I am thinking of redoing the spec in JSON using the same tags to identify > the data elements. Speaking of which... what is the best way to longpoll (tail -f) a log file over HTTP? Nico -- From nobody Sun Mar 16 05:01:18 2014 Return-Path: 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 765E11A02DD for ; Sun, 16 Mar 2014 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 RcyLku5lInZI for ; Sun, 16 Mar 2014 05:01:13 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id D78B11A0104 for ; Sun, 16 Mar 2014 05:01:12 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id q8so3010967lbi.0 for ; Sun, 16 Mar 2014 05:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mZthOG5D7MCizEh9DQiTytVgYX7ayQ/J8ZB8pLcwitI=; b=emPgEe7NXfuuY72rY2mxlimkr52XHdhuyUlKa6vThnH32/LFCCPTspyFXwDbjdxJ0T sZg8HEL7fP8D1P0w950l7+J/yFP5dWqkWiZI6eqlNcuStT7nG5RuT5wUhxoyWxWILzX5 GH/24LuYONRmHYut+xYsqtF3bLOGgDa7P1hbPbPRq3WTrk7OMjAdZ3hLTStoaAFQ1ZB0 +o0iPJgO1apQn3TsyKAkdSEucI0UjZKLQrCfly/K23iY8sLyXBQIv1OyZ/GF29l7b5cX KLCw8Fl7hb9vkVqeH7sslfZW2Ivaso6rgVkdZMpaJVkNU5yov70hENoyhVN2tbOf/Y4y hHWA== MIME-Version: 1.0 X-Received: by 10.152.2.225 with SMTP id 1mr965271lax.37.1394971264642; Sun, 16 Mar 2014 05:01:04 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Sun, 16 Mar 2014 05:01:04 -0700 (PDT) In-Reply-To: References: <20140315194123.GG24343@mercury.ccil.org> Date: Sun, 16 Mar 2014 08:01:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e013c61a0b3754704f4b80e2a Archived-At: http://mailarchive.ietf.org/arch/msg/json/-xDx4Ikh8CBTv_LBiPsoRhgzy7Q Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 12:01:15 -0000 --089e013c61a0b3754704f4b80e2a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 16, 2014 at 3:52 AM, Nico Williams wrote: > On Sat, Mar 15, 2014 at 3:53 PM, Phillip Hallam-Baker > wrote: > > I am thinking that the best way to show off JSON sequence would be to > update > > this draft from '96 > > > > http://www.w3.org/TR/WD-logfile.html > > > > It is a widely used format but it has problems, every entry has to > specify > > entries for precisely the set of data advertised at the start. > > > > I am thinking of redoing the spec in JSON using the same tags to identify > > the data elements. > > Speaking of which... what is the best way to longpoll (tail -f) a log > file over HTTP? > Make a HEAD request to find out the Content-Length, then to poll for updates after that point, use the range parameter. But a Web Service to fetch the info would make matters a lot easier. -- Website: http://hallambaker.com/ --089e013c61a0b3754704f4b80e2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 16, 2014 at 3:52 AM, Nico Williams &l= t;nico@cryptonec= tor.com> wrote:
On Sat, Mar 15, 2014 at 3:53= PM, Phillip Hallam-Baker <hallam@gm= ail.com> wrote:
> I am thinking that the best way to show off JSON sequence would be to = update
> this draft from '96
>
> htt= p://www.w3.org/TR/WD-logfile.html
>
> It is a widely used format but it has problems, every entry has to spe= cify
> entries for precisely the set of data advertised at the start.
>
> I am thinking of redoing the spec in JSON using the same tags to ident= ify
> the data elements.

Speaking of which... what is the best way to longpoll (tail -f) a log=
file over HTTP?

Make a HEAD request to = find out the Content-Length, then to poll for updates after that point, use= the range parameter.

But a Web Service to fetch t= he info would make matters a lot easier.
=A0
--
Website: htt= p://hallambaker.com/
--089e013c61a0b3754704f4b80e2a-- From nobody Sun Mar 16 08:23:31 2014 Return-Path: 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 F05831A01C5 for ; Sun, 16 Mar 2014 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 m2myk43BkhTt for ; Sun, 16 Mar 2014 08:23:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 330AD1A01BE for ; Sun, 16 Mar 2014 08:23:28 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2GFNCJu074751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Mar 2014 08:23:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sun, 16 Mar 2014 08:23:11 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4E9283CF-5C7D-43BE-AA0E-8D14739A40A0@vpnc.org> References: <20140315194123.GG24343@mercury.ccil.org> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/GYlhWPrmf27lXnzfvKn5VY4Jmnc Cc: "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:23:29 -0000 On Mar 16, 2014, at 12:44 AM, Nico Williams wrote: >> 3) The sentence "Two contiguous separators do not" is unnecessary, >> because there are no empty JSON texts. > > I know this. I just figure someone will wonder if I don't say it. Exactly right. Thus, please leave it in. --Paul Hoffman From nobody Sun Mar 16 14:44:46 2014 Return-Path: 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 9DC411A031D for ; Sun, 16 Mar 2014 14:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 vMG_2rZzE6kr for ; Sun, 16 Mar 2014 14:44:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 33C231A0139 for ; Sun, 16 Mar 2014 14:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=286; q=dns/txt; s=iport; t=1395006274; x=1396215874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V4ii5j+4z3Vwf1gj7xZf/huMAEDtfXPuxAMzsZa2Vw0=; b=FEwXpb9YTA44WP1QozwcDDuYVDrXQp3ERYYJ9kCMawrJLYP2pF0VeLDj x1Eg489IR/txFjGAGNkhqcACkljpU0CE1TeM6xz3OD4dAkNNE/kp56DYs fTVMnsBiP4iWsFbn5oX1TZxBq54+LVp0AJZsYervaI9Y6XPnFpcFyywm1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFALcaJlOtJXG+/2dsb2JhbABYgwaBEsIDgRgWdIImAQEEOj8QAgEINhAyJQIEAQ0Fh3nSMheOaAeEOAEDmEaSL4Mtgis X-IronPort-AV: E=Sophos;i="4.97,666,1389744000"; d="scan'208";a="310650165" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 16 Mar 2014 21:44:34 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2GLiYgK029820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Mar 2014 21:44:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sun, 16 Mar 2014 16:44:34 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Phillip Hallam-Baker Thread-Topic: [Json] draft-williams-json-text-sequence-00 Thread-Index: AQHPP+mzXp08SxQBSkW/VET2wBJWsJri4RWAgAAUBoCAALhigIAAg8AA Date: Sun, 16 Mar 2014 21:44:33 +0000 Message-ID: References: <20140315194123.GG24343@mercury.ccil.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.120.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/LGWGutQvxPnXSVMVvIjJoSD-T6Q Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 21:44:43 -0000 On 3/16/14, 1:52 AM, "Nico Williams" wrote: >Speaking of which... what is the best way to longpoll (tail -f) a log >file over HTTP? A WebSocket. One WS message containing each JSON object log message. No need for new formats. --=20 Joe Hildebrand From nobody Sun Mar 16 15:30:33 2014 Return-Path: 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 BD7C21A0325 for ; Sun, 16 Mar 2014 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 2QuabFUOdESS for ; Sun, 16 Mar 2014 15:30:32 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id EB1851A01A0 for ; Sun, 16 Mar 2014 15:30:31 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 6208A31805C for ; Sun, 16 Mar 2014 15:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=cEO9lC1BrJdVu5JRIrnJ iSBjWZM=; b=jRJqhKrGFnLFf1ggFg45E1vOpmzxNKJye00VsAMvaGZhZWK/i31z XeiY5HD0Oa1+fi9ce3BEnTI7bpUTl00GYo4CCvPfmDZHkVuVQ9OviOP+PEdB17Rf pBxCQSC04jtJdGEdQ/A0a8Jwsxi7OuEJfIc77CaCaSZbTg5tP0ulpD0= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 16002318059 for ; Sun, 16 Mar 2014 15:30:23 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1433430wiw.0 for ; Sun, 16 Mar 2014 15:30:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MQlCfItCXQDI1IRsrtlGqqlz8vx6H6qN0A93vqhUbg0=; b=P+gNFeCwA0x8V8tVvPAbz01iS3sYdkJJD5lZgM2OpAffjg2BQsG4RUCse90VOdEd6t iayrobj9zcX8KQx/ymIakqH4qrVOL0aC+pEMJk3gdptHMy5pHC8MiHGh6lmiMyzHCwS5 cZtaGkPIcaUzX0m+i4503t9R1XS8hi5EDMPT6oEBfm1G/BBH5rJFpTvQ3JzcQGJkypkV 4rJw6zFeUk89rB7C6jk9ljBO+792OXZzCQW3Pu1fPo9DDOPDUpufpgR7Rjl9TixUEAUR mnYGmdJJj4lzE0I1iX2ZsQEBuu7067wLqgRzEiZxg1im5kImU9ZZTgovaVhm2FigBqFE CswQ== MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr64890wjq.59.1395009022817; Sun, 16 Mar 2014 15:30:22 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 16 Mar 2014 15:30:22 -0700 (PDT) In-Reply-To: References: <20140315194123.GG24343@mercury.ccil.org> Date: Sun, 16 Mar 2014 17:30:22 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/RXrtjHDI2cB5Ue_8k0_5tTQMFGw Cc: John Cowan , Phillip Hallam-Baker , "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 22:30:33 -0000 On Sun, Mar 16, 2014 at 4:44 PM, Joe Hildebrand (jhildebr) wrote: > On 3/16/14, 1:52 AM, "Nico Williams" wrote: >>Speaking of which... what is the best way to longpoll (tail -f) a log >>file over HTTP? > > A WebSocket. One WS message containing each JSON object log message. No > need for new formats. A WS works for some apps, yes. Suppose the log is something like a database replication log... Initially I may want to fetch the whole log, then I may want to tail it, and tailing could be "dumb", sending what's available, when it's available, without having to find JSON text boundaries. Nico -- From nobody Sun Mar 16 17:54:13 2014 Return-Path: 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 343691A0339 for ; Sun, 16 Mar 2014 17:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 SgHzDpVDksZE for ; Sun, 16 Mar 2014 17:54:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 29B241A032B for ; Sun, 16 Mar 2014 17:54:06 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.893.10; Mon, 17 Mar 2014 00:53:57 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0893.001; Mon, 17 Mar 2014 00:53:57 +0000 From: Larry Masinter To: Bjoern Hoehrmann , Matt Miller Thread-Topic: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter Thread-Index: AQHPQFVChMk0qCQ/h0SHqE0YpXG40prkdUow Date: Mon, 17 Mar 2014 00:53:56 +0000 Message-ID: References: <53238F21.2030508@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 0153A8321A x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(24454002)(199002)(189002)(85306002)(90146001)(74706001)(31966008)(74502001)(74876001)(74662001)(95666003)(97186001)(95416001)(81816001)(66066001)(74366001)(83072002)(63696002)(47976001)(50986001)(51856001)(54316002)(47446002)(81542001)(54356001)(33646001)(2656002)(15202345003)(4396001)(47736001)(92566001)(15975445006)(87266001)(59766001)(77982001)(93516002)(69226001)(86362001)(74316001)(94316002)(65816001)(81686001)(85852003)(56816005)(97336001)(53806001)(49866001)(46102001)(80976001)(76482001)(81342001)(79102001)(87936001)(76576001)(80022001)(83322001)(19580395003)(93136001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:DCAFD173.2CBA0FE1.43C32386.D6E6D2C3.200D8; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/T-9QFa8TSp9C0136s_Lcn8APJis Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 00:54:11 -0000 > * Matt Miller wrote: > >.. adopt I-JSON > >(http://tools.ietf.org/html/draft-bray-i-json-01)=20 > No, not without changing the nature of the document considerably. These > are just best practises and not a separate format with its own name. +1, no new name. best practices if you want to be a conservative sender. Possibly validated in spoof-prevention scenarios. From nobody Sun Mar 16 19:38:42 2014 Return-Path: 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 1A5461A0365 for ; Sun, 16 Mar 2014 19:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 4li9Y2xjRyLg for ; Sun, 16 Mar 2014 19:38:39 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 676AF1A0250 for ; Sun, 16 Mar 2014 19:38:39 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s2H2cUdf026295 for ; Sun, 16 Mar 2014 19:38:31 -0700 Received: from vpn-135-70-97-222.vpn.swst.att.com ([135.70.97.222]) by maillennium.att.com (mailgw1) with ESMTP id <20140317023829gw100j0c82e>; Mon, 17 Mar 2014 02:38:30 +0000 X-Originating-IP: [135.70.97.222] Message-ID: <5326601E.3040501@att.com> Date: Sun, 16 Mar 2014 22:38:22 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: IETF JSON WG References: <53238F21.2030508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/gJCN2M5N93FmIoBkyhVCaCp9Qok Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 02:38:41 -0000 On 3/15/14, 9:46 AM, Bjoern Hoehrmann wrote: > * Matt Miller wrote: >> The chairs are seeking comment on whether we should adopt I-JSON >> (http://tools.ietf.org/html/draft-bray-i-json-01) as a WG item in our >> charter. Remember that adopting this draft does not mean it is done; >> changes can happen based on the consensus of the WG. > No, not without changing the nature of the document considerably. These > are just best practises and not a separate format with its own name. Based on the conversation that we had at the WG session in London, I came away convinced that: *) it does need to be a WG item *) we need neither a new media type nor a mandatory internal-tag indicating compliance with i-json, so that stuff needs to be removed from the document *) an optional internal-tag might need some more discussion *) the document should really just reflect a set of restrictions on the json format that can be (optionally?) validated against - Tony Hansen From nobody Sun Mar 16 20:51:40 2014 Return-Path: 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 94B431A02B7 for ; Sun, 16 Mar 2014 20:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 wNanHkHaCCzS for ; Sun, 16 Mar 2014 20:51:37 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (unknown [69.163.253.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE01A02B6 for ; Sun, 16 Mar 2014 20:51:37 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id F2C05350078 for ; Sun, 16 Mar 2014 20:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=cuJk5Qkb6olRM+Bl0WCX KpwBNMo=; b=kHIXPVQ0/ksXIdYxdEFXBsJ7vM6F9Q25JidIDXRowxtYDAnWmL7Z eq6aIdQ9YUSNIF+jHAdVIe7s+gKbZnfx3SXp4Fk4Hhwqak++6cCkeRo8vAHeUQFY XuZc7cGkdUyQx2TUkiulvV6eYuQyL1WSC7+za4gvfJ6ZmkKKKhrE5h4= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id A5881350072 for ; Sun, 16 Mar 2014 20:51:29 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so708354wib.5 for ; Sun, 16 Mar 2014 20:51:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0J1zyt0c19FM7MqRDZF/ub570xtHiaTBQTnBX4Zg7cg=; b=PZ1vqgVzcOblk9Cc2AHX41Oxc+A8lphZe766r7hJ+QeUOfAKx3U78d18XzLYrHKJG+ /Kch2j64G+72a+LRwaI2KxnmjKs80i14Kd6iOj83uacCLXBFhSbJSuYCcGsFSzovDTI+ 39mIslV32TB+izT04t/LQO45F88bXgvEjiQZHN7Y5TI9lFeTM/yG8tfTk6490vS4+MVM zTz3L1t0OTRaLQcTxIhkMY/NCf5kh6SiSNt9jZ+mwOEKVcIbx5iBEfFaFQr9uXwew0jm a4y8U4et3rLyR0QZPuvNEdb/swOhz7UZJZUf0bYZ5E/O8FoNByvQrLx9KFjpzPydms4g vhHA== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr7758745wib.39.1395028288377; Sun, 16 Mar 2014 20:51:28 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Sun, 16 Mar 2014 20:51:28 -0700 (PDT) In-Reply-To: <53238F21.2030508@cisco.com> References: <53238F21.2030508@cisco.com> Date: Sun, 16 Mar 2014 22:51:28 -0500 Message-ID: From: Nico Williams To: Matt Miller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/X97Wgjo0SfWYM4d_aTVzxeq-uC4 Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 03:51:38 -0000 My main complaint is with the recommendation/requirement that JSON texts be objects at the top-level. Instead I would say that if there's reason to need to signal "schema" metadata in-band then a) application should specify how they do that, b) here's a few ways in which they might, and all their pros and cons. Note too that there are many apps where there's no need to signal schema metadata in-band because they always have some way to communicate relevant metadata out of band. Nico -- From nobody Sun Mar 16 22:49:58 2014 Return-Path: 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 ACFF41A0396 for ; Sun, 16 Mar 2014 22:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 RPu3IBy0Yspg for ; Sun, 16 Mar 2014 22:49:48 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id AD9FB1A0395 for ; Sun, 16 Mar 2014 22:49:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,667,1389704400"; d="scan'208";a="192486425" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 17 Mar 2014 16:49:37 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7379"; a="158810522" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcani.tcif.telstra.com.au with ESMTP; 17 Mar 2014 16:49:18 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Mon, 17 Mar 2014 16:49:18 +1100 From: "Manger, James" To: Nico Williams , "json@ietf.org" Date: Mon, 17 Mar 2014 16:47:43 +1100 Thread-Topic: [Json] draft-williams-json-text-sequence-00 Thread-Index: Ac8/6bYRiW8mkPUST9m+Ixv0gMsWsQBtkp0g Message-ID: <255B9BB34FB7D647A506DC292726F6E115404DC02A@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tKcX04_lAtFAuS9SJ2NLsCj-acc Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 05:49:49 -0000 PiBUaXRsZTogICAgICAgICAgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pIFRleHQg U2VxdWVuY2VzDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbGxpYW1zLWpz b24tdGV4dC1zZXF1ZW5jZS0wMA0KDQpOaWNvLA0KDQpEaWQgeW91IHJlYWxseSBtZWFuIHRvIGFs bG93IGNvbW1hcyBhcyBzZXBhcmF0b3JzICglMkMgaW4gQUJORik/DQoNCkkgd291bGQgYmUgdGVt cHRlZCB0byBzYXk6DQoNCiAgQSBKU09OIHNlcXVlbmNlIGlzIGEgY29uY2F0ZW5hdGlvbiBvZiBh bnkgbnVtYmVyIG9mIEpTT04gdmFsdWVzLA0KICByZW1lbWJlcmluZyB0aGF0IGVhY2ggdmFsdWUg KG1hdGNoaW5nIDxKU09OLXRleHQ+IGluIFtSRkM3MTU5XSkNCiAgY2FuIGJlIHByZWNlZGVkIGFu ZCBmb2xsb3dlZCBieSBpbnNpZ25pZmljYW50IHdoaXRlc3BhY2UuDQogIFdoaXRlc3BhY2UgTVVT VCBiZSBwcmVzZW50IGJldHdlZW4gdHdvIEpTT04gdmFsdWVzIHdoZW4gYm90aA0KICB2YWx1ZXMg YXJlIHRydWUsIGZhbHNlLCBudWxsLCBvciBhIG51bWJlci4gV2hpdGVzcGFjZSBiZXR3ZWVuDQog IHZhbHVlcyBpcyBhbGxvd2VkLCBidXQgbm90IHJlcXVpcmVkLCB3aGVuIGVpdGhlciB2YWx1ZSBp cyBhbg0KICBvYmplY3QsIGFycmF5LCBvciBzdHJpbmcuDQoNCiAgQ29uY2F0ZW5hdGluZyBKU09O IHZhbHVlcywgZWFjaCB0ZXJtaW5hdGVkIHdpdGggYSBuZXdsaW5lIChVKzAwMEEpLA0KICBpcyBh IHNpbXBsZSB3YXkgdG8gbWF0Y2ggdGhlIHN5bnRheCBydWxlcy4NCg0KICBBbiBlbXB0eSB0ZXh0 IGFuZCB0ZXh0cyBjb25zaXN0aW5nIG9ubHkgb2Ygd2hpdGVzcGFjZSBhcmUgYm90aCB2YWxpZA0K ICBKU09OIHNlcXVlbmNlcyBvZiB6ZXJvIEpTT04gdmFsdWVzLg0KDQogIFRoZSBtZWRpYSB0eXBl ICJhcHBsaWNhdGlvbi9qc29ucyIgaW5kZW50aWZpZXMgY29udGVudCB0aGF0IGlzDQogIGEgVVRG LTgtZW5jb2RlZCBKU09OIHNlcXVlbmNlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From nobody Mon Mar 17 04:57:15 2014 Return-Path: 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 836171A03F1 for ; Mon, 17 Mar 2014 04:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 9Y3Qdbd2d22f for ; Mon, 17 Mar 2014 04:57:08 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8D21A03D3 for ; Mon, 17 Mar 2014 04:57:08 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ec20so3645832lab.1 for ; Mon, 17 Mar 2014 04:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=souwo3lEAUg5HM0WDvlGLmkYH5WljbesPQYVwJCPpS0=; b=DOykh06qeKprlAFTJhX1qDeA5TO0hp/7WmnWRVKAn0DFYrhrXjgUg2IsKKESHAIqkZ ikXQtP9hhP4jTuQCeCXhz3rapM+um37Q5U4u7zQUu6OiMLKcozMfJiXjo4bKJwRuLWXT 44E5Ek78rLlRNWHuivVkmGD33mksKRbk8ZK3/JXp04P9AySsxGI4EXUv8JkuhU5pLqSq slaPdWjPC2AjyjomIz9giCVcUhgsdowp0wRiNmTiZzHzFyux/7kzmi5Ml5RgPkhVUgmi U6qM5geOx/lb480+mDfzUAFjZacJNJPgn7gE0hv5U9SPhDL7IAJIn3dAVZb2c6X2W6So j6hg== MIME-Version: 1.0 X-Received: by 10.112.143.99 with SMTP id sd3mr15802638lbb.11.1395057419714; Mon, 17 Mar 2014 04:56:59 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 17 Mar 2014 04:56:59 -0700 (PDT) In-Reply-To: References: <53238F21.2030508@cisco.com> Date: Mon, 17 Mar 2014 07:56:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e01160478f184b504f4cc1da6 Archived-At: http://mailarchive.ietf.org/arch/msg/json/l3E57VzuqbmpoOduGtSG6TxbeZA Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 11:57:10 -0000 --089e01160478f184b504f4cc1da6 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams wrote: > My main complaint is with the recommendation/requirement that JSON > texts be objects at the top-level. > > Instead I would say that if there's reason to need to signal "schema" > metadata in-band then a) application should specify how they do that, > b) here's a few ways in which they might, and all their pros and cons. > > Note too that there are many apps where there's no need to signal > schema metadata in-band because they always have some way to > communicate relevant metadata out of band. > > Nico > -- I have no problem with this as a convention in a protocol. But I don't see the need for that restriction in I-JSON. In a protocol design the spec is going to say something like 'the encoding is in the I-JSON subset of JSON'. Then its going to describe the format of the data which for a protocol is almost always gonna be an object per message at the top level. Though it could be an array of objects if multiple requests per message are supported. -- Website: http://hallambaker.com/ --089e01160478f184b504f4cc1da6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams &= lt;nico@cryptone= ctor.com> wrote:
My main complaint is with the recommendation= /requirement that JSON
texts be objects at the top-level.

Instead I would say that if there's reason to need to signal "sche= ma"
metadata in-band then a) application should specify how they do that,
b) here's a few ways in which they might, and all their pros and cons.<= br>
Note too that there are many apps where there's no need to signal
schema metadata in-band because they always have some way to
communicate relevant metadata out of band.

Nico
--

I have no problem with this as a convent= ion in a protocol. But I don't see the need for that restriction in I-J= SON.

In a protocol design the spec is going to say= something like 'the encoding is in the I-JSON subset of JSON'. The= n its going to describe the format of the data which for a protocol is almo= st always gonna be an object per message at the top level. Though it could = be an array of objects if multiple requests per message are supported.



--
Website: http://hallambaker.com/
--089e01160478f184b504f4cc1da6-- From nobody Mon Mar 17 08:21:48 2014 Return-Path: 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 014351A0413 for ; Mon, 17 Mar 2014 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 DDcd_F02HnR9 for ; Mon, 17 Mar 2014 08:21:45 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (agjbgdcfdbef.dreamhost.com [69.163.253.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5051A042E for ; Mon, 17 Mar 2014 08:21:44 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 744F92007F124 for ; Mon, 17 Mar 2014 08:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=GilMqVEAcEtU8nQ9HdLp yFJGe9Y=; b=UomvJZMnZfHn9sJgCa6CrvLEpsohKNVJIXgWrZJWKRzFeiiOSpL3 bTo70OqKBu+kWNakgppSFTRFdp2u2HvkmnRdKa22uE3WNdnj1xqB841Vt/J/FVm2 kNP/A+rRP61sYkwjg64TSW77KvFZFVl0UklxIPkkbclDPGH14F7ctlY= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 299562007F120 for ; Mon, 17 Mar 2014 08:21:36 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so4792388wgh.5 for ; Mon, 17 Mar 2014 08:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kkKFtx2/Eia2P2Apg6sZn93V4cUlcUOaoE2ayW+tcGY=; b=KGofsOY/YXTzyfDeXnUXO6eWpO7T8loeXALII1zg8MO1Oerw+0SKTMpOvsucBd4WS7 8di6Iq3ukw2omseqhUEYw1v0A4eX6eEgWWljr9Wjina/8VzkdhiQkIbIzgZwNDmn34FX 5zrRhbXtLXozfEjGuTNhTFl2u2cNUneXX4oozuDLoUa3KJQ1rS/m1EVdI99fzBdBWJhw jeYxZlkP2jqrlJ0zQos4e4dAGYNzEq7bRe31IZ6gVeZl2sxlSU5En5/S/ABC1tcMUITg 4b+MDmnWvsmfP5UDvWMgiCELsnDf3EWhi2YFNDaqk4dppHtnRqeFnWVQTPdoseoduUnN 4Jiw== MIME-Version: 1.0 X-Received: by 10.194.119.168 with SMTP id kv8mr6522920wjb.41.1395069694915; Mon, 17 Mar 2014 08:21:34 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 17 Mar 2014 08:21:34 -0700 (PDT) In-Reply-To: References: <53238F21.2030508@cisco.com> Date: Mon, 17 Mar 2014 10:21:34 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Pj3UTlFPvOy9Djj2i8U8sy1uCGY Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:21:47 -0000 On Mon, Mar 17, 2014 at 6:56 AM, Phillip Hallam-Baker wrote: > On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams > wrote: >> My main complaint is with the recommendation/requirement that JSON >> texts be objects at the top-level. >> >> Instead I would say that if there's reason to need to signal "schema" >> metadata in-band then a) application should specify how they do that, >> b) here's a few ways in which they might, and all their pros and cons. >> >> Note too that there are many apps where there's no need to signal >> schema metadata in-band because they always have some way to >> communicate relevant metadata out of band. > > > I have no problem with this as a convention in a protocol. But I don't see > the need for that restriction in I-JSON. If the purpose is to signal schema metadata then I'd like to explore other conventions and go for a "you must provide such metadata" statement in order to make yours an I-JSON usage. > In a protocol design the spec is going to say something like 'the encoding > is in the I-JSON subset of JSON'. Then its going to describe the format of > the data which for a protocol is almost always gonna be an object per > message at the top level. Though it could be an array of objects if multiple > requests per message are supported. Right, imagine wrapping an array of objects in an object just to denote schema metadata. What a pain. You're probably streaming the array, so now you gotta add an object around it -- and remove it -also in a streaming manner- on the parser side. Or perhaps you have a sequence of objects to return... should you mark up every one of those objects? While streaming them? More pain. We should consider how this markup happens. Incidentally, we could say that the first text in a JSON text sequence should denote schema metadata for the rest... That would not be so painful. (although it would still interfere with existing usage). Nico -- From nobody Mon Mar 17 08:37:45 2014 Return-Path: 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 491281A041E for ; Mon, 17 Mar 2014 08:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.1 X-Spam-Level: *** X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no 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 a1110mRvii2r for ; Mon, 17 Mar 2014 08:37:42 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (unknown [69.163.253.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1089F1A02FD for ; Mon, 17 Mar 2014 08:37:42 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 4E2CA428082 for ; Mon, 17 Mar 2014 08:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Y7+9GFYLGmMpfDaCVF8u USUEbig=; b=m3+tY8woRTcND8Qg/OWzg2iCYvq5aOghNT3I0WjB+WVve2LHOBQZ E1JLBQ/kIsAZpE/qvBcDaFv+BOtJi+Kx8O2GkvuKU4/sSFc9S4dBa5kZkicpY/wk FS9PO7cLSR7D6NUW58lf8ur6wvld8C1BlfOpX0d1dU8+ODjU6fJ1PQk= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id EF6A0428072 for ; Mon, 17 Mar 2014 08:37:33 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so4687821wgh.28 for ; Mon, 17 Mar 2014 08:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fn+M/sqvRuk36EzuzzXrlzvFYEG7tMTL9/jK52vgD+o=; b=DSm2FNWkrNYPO4IK2wKOK/nIZTlpbQYzMl4alBwQzDMYG644h66Lj7mmAxAiiu2OC4 A5FddEpzlVQ1oru2UL/rM7pgImOjt1oGD6Uv91ZnvjhSYq45OsOMO5F35AWAeLOkJ4bt tdkolC8rRag8kKX9xlQ5e7iywoxto5o2d5hR2m8j/P01F/7lEj1Rn9cWXs8hUf60bbnu un6QQYcmFUCzdFtG+tsxiQA9ekP9NqXZrbS7YJQfEPzpSxRZMUmTD8nTvS4PexwDc/Xh Q4tZxMVTMzAxUv9LeJc2FJvLViQYor13rOOY8gkiJiTV4Oe7WGhlbYsGkAE33nVxlCx4 R0Yg== MIME-Version: 1.0 X-Received: by 10.194.84.240 with SMTP id c16mr34440wjz.95.1395070652688; Mon, 17 Mar 2014 08:37:32 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Mon, 17 Mar 2014 08:37:32 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115404DC02A@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115404DC02A@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 17 Mar 2014 10:37:32 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/rLyqcpjAUwU8marlorgCXT8nuMg Cc: "json@ietf.org" Subject: Re: [Json] draft-williams-json-text-sequence-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:37:43 -0000 On Mon, Mar 17, 2014 at 12:47 AM, Manger, James wrote: >> Title: JavaScript Object Notation (JSON) Text Sequences >> http://tools.ietf.org/html/draft-williams-json-text-sequence-00 > > Nico, > > Did you really mean to allow commas as separators (%2C in ABNF)? No, I hadn't (I'd just argued in response to Phillip that it was a bad idea). However, I'm not as convinced of it as I'd like to be. I think there may indeed be some value in it. Suppose you expect a JSON text to be a very large (possibly never-ending) array... you might parse it as a sequence by skipping the initial '[' and going from there. You'd get streaming parsing of the sequence without streaming parsing of the individual JSON texts. That seems worthwhile as a way of dealing with any cases that might exist of very large arrays. > I would be tempted to say: > > A JSON sequence is a concatenation of any number of JSON values, > remembering that each value (matching in [RFC7159]) > can be preceded and followed by insignificant whitespace. > Whitespace MUST be present between two JSON values when both > values are true, false, null, or a number. Whitespace between > values is allowed, but not required, when either value is an > object, array, or string. I like that, but it's important that the separator always _follow_ each text. Whitespace may also precede a text, sure, but that's not important here. > Concatenating JSON values, each terminated with a newline (U+000A), > is a simple way to match the syntax rules. Yes. > An empty text and texts consisting only of whitespace are both valid > JSON sequences of zero JSON values. s/empty text/empty sequence/, but yes, that's nice. Nico -- From nobody Mon Mar 17 10:49:10 2014 Return-Path: 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 4BE801A042B for ; Mon, 17 Mar 2014 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 wRxm5j_hjvHB for ; Mon, 17 Mar 2014 10:49:05 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 25DCB1A02F8 for ; Mon, 17 Mar 2014 10:49:04 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so3899486lbd.37 for ; Mon, 17 Mar 2014 10:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zjiOi540kcurjmpZZNpRawhrna8BgHVS6XCmcBoNNgA=; b=jPXxwZJ5t0+gt3X9QE0khfEZXbY6v7MjuzJQ/lNyOjvGg14Rx0iWpsCkVEBbZuvIlQ lIdgX2RIFdUJZ8swef/1x1ZZWS7bXV0jii98vwJpXZcYfi6GfxNejuU3Q7CYQKTPgEYW YZU/ifGdB5vTdYGfYwco/Bkdr5nBkJwKAaJniwixfFz0nIz+4XNO8X3K87sswtJLOwsV XIc1pxCQrqvoYlZqAmflxfuSkhbSb9VzuvLGNXobBub1kC/m3iz2o4fqbNl8+BraaGWJ xLRLhQjTHSrdNlrsADpWVJtqhrEOHqDRukAslBRs5t9QtQX+bkjKPGO9BUT7OAnwzU5k +xIw== MIME-Version: 1.0 X-Received: by 10.152.234.107 with SMTP id ud11mr2855818lac.22.1395078536282; Mon, 17 Mar 2014 10:48:56 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 17 Mar 2014 10:48:56 -0700 (PDT) In-Reply-To: References: <53238F21.2030508@cisco.com> Date: Mon, 17 Mar 2014 13:48:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11340f1e96c75204f4d108d7 Archived-At: http://mailarchive.ietf.org/arch/msg/json/YockDUOjsiId2Ucco_YGFrOT7ls Cc: IETF JSON WG Subject: Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:49:08 -0000 --001a11340f1e96c75204f4d108d7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 17, 2014 at 11:21 AM, Nico Williams wrote: > On Mon, Mar 17, 2014 at 6:56 AM, Phillip Hallam-Baker > wrote: > > On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams > > wrote: > >> My main complaint is with the recommendation/requirement that JSON > >> texts be objects at the top-level. > >> > >> Instead I would say that if there's reason to need to signal "schema" > >> metadata in-band then a) application should specify how they do that, > >> b) here's a few ways in which they might, and all their pros and cons. > >> > >> Note too that there are many apps where there's no need to signal > >> schema metadata in-band because they always have some way to > >> communicate relevant metadata out of band. > > > > > > I have no problem with this as a convention in a protocol. But I don't > see > > the need for that restriction in I-JSON. > > If the purpose is to signal schema metadata then I'd like to explore > other conventions and go for a "you must provide such metadata" > statement in order to make yours an I-JSON usage. > > > In a protocol design the spec is going to say something like 'the > encoding > > is in the I-JSON subset of JSON'. Then its going to describe the format > of > > the data which for a protocol is almost always gonna be an object per > > message at the top level. Though it could be an array of objects if > multiple > > requests per message are supported. > > Right, imagine wrapping an array of objects in an object just to > denote schema metadata. What a pain. You're probably streaming the > array, so now you gotta add an object around it -- and remove it -also > in a streaming manner- on the parser side. > > Or perhaps you have a sequence of objects to return... should you mark > up every one of those objects? While streaming them? More pain. > > We should consider how this markup happens. > > Incidentally, we could say that the first text in a JSON text sequence > should denote schema metadata for the rest... That would not be so > painful. (although it would still interfere with existing usage). > > Nico > -- > As a general rule, whenever I see a proposal that depends on the order of JSON objects, I think that either an Array or an Object needs to be introduced. I very much prefer this { "get-request" : { .... request data here .... } } to this: { "jscommand" : "get-request", ... rest of request data follows ... } One of the things I have come to detest in HTTP is that it does not separate protocol headers from content metadata. There really should be a separation between the two so that it is possible to do things like signing the content metadata. -- Website: http://hallambaker.com/ --001a11340f1e96c75204f4d108d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 17, 2014 at 11:21 AM, Nico Williams &= lt;nico@cryptone= ctor.com> wrote:
On Mon, Mar 17, 2014 at 6:56 AM, Philli= p Hallam-Baker <ha= llam@gmail.com> wrote:
> On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>> My main complaint is with the recommendation/requirement that JSON=
>> texts be objects at the top-level.
>>
>> Instead I would say that if there's reason to need to signal &= quot;schema"
>> metadata in-band then a) application should specify how they do th= at,
>> b) here's a few ways in which they might, and all their pros a= nd cons.
>>
>> Note too that there are many apps where there's no need to sig= nal
>> schema metadata in-band because they always have some way to
>> communicate relevant metadata out of band.
>
>
> I have no problem with this as a convention in a protocol. = But I don't see
> the need for that restriction in I-JSON.

If the purpose is to signal schema metadata then I'd like to expl= ore
other conventions and go for a "you must provide such metadata" statement in order to make yours an I-JSON usage.

> In a protocol design the spec is going to say something like 'the = encoding
> is in the I-JSON subset of JSON'. Then its going to describe the f= ormat of
> the data which for a protocol is almost always gonna be an object per<= br> > message at the top level. Though it could be an array of objects if mu= ltiple
> requests per message are supported.

Right, imagine wrapping an array of objects in an object just to
denote schema metadata. =A0What a pain. =A0You're probably streaming th= e
array, so now you gotta add an object around it -- and remove it -also
in a streaming manner- on the parser side.

Or perhaps you have a sequence of objects to return... should you mark
up every one of those objects? =A0While streaming them? =A0More pain.

We should consider how this markup happens.

Incidentally, we could say that the first text in a JSON text sequence
should denote schema metadata for the rest... =A0That would not be so
painful. =A0(although it would still interfere with existing usage).

Nico
--


As a general rule, whenever I= see a proposal that depends on the order of JSON objects, I think that eit= her an Array or an Object needs to be introduced.

I very much prefer this

{ "get-request" = : { =A0.... request data here .... } }


<= div>to this:

{ "jscommand" : "get-r= equest",
=A0 =A0... rest of request data follows ...
=A0 =A0}


One of the things I have come to detest in= HTTP is that it does not separate protocol headers from content metadata. = There really should be a separation between the two so that it is possible = to do things like signing the content metadata.


--
Website: http://hallambaker.com/
--001a11340f1e96c75204f4d108d7-- From nobody Mon Mar 17 15:18:03 2014 Return-Path: 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 0D9871A063D for ; Mon, 17 Mar 2014 15:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yaTwFZjMbhj3 for ; Mon, 17 Mar 2014 15:18:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 996B61A0642 for ; Mon, 17 Mar 2014 15:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1656; q=dns/txt; s=iport; t=1395094673; x=1396304273; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=e0BJqe/L7+RgYxs/pjpj++v4kJPxik24JwvaWsuvNRE=; b=NuoOUBjLaPClyJ4BtEbcnPpSRNIhYTFrRdAAOH7R0p0kBXQ8f/ovsi9Q ZdyF58Nsc0oRlucmb7oiad0L8F/14XIdBOmzChtsYokkvpfPvOPQ8M/0M R/ItH6R7cPBd3hYEHIGjLlqEqELl/9BIb7DIIkBny0IedfpaFA8GR+H7Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKNzJ1OtJXG+/2dsb2JhbABagwaBEsM+FnSCSYEYNAJMDQgBAYd1oWeyBReOFIUTBIkaOI50kjCDTIIM X-IronPort-AV: E=Sophos;i="4.97,673,1389744000"; d="scan'208";a="310929890" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 17 Mar 2014 22:17:52 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2HMHqQp013143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 22:17:52 GMT Received: from che-vpn-cluster-2-161.cisco.com (10.86.242.161) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Mar 2014 17:17:51 -0500 Message-ID: <53277484.70305@cisco.com> Date: Mon, 17 Mar 2014 16:17:40 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.86.242.161] Archived-At: http://mailarchive.ietf.org/arch/msg/json/KCN6KBTkUzmp793rNM8KS1tYOTo Subject: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 22:18:02 -0000 Greetings again. We earlier asked a couple of questions to gauge what the new proposed WG charter ought to contain. That feedback has been valuable, but has drilled into implementation specifics before a new charter was actually agreed on! We have been chastised by our AD about this, and for good reason. We think we already have enough input from the London meeting and the list over the past few days to make the following proposal for a new charter: ========================== Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard, and was later published in RFC 7159. The WG will work on an restricted profile of JSON designed to maximize interoperability. The work will start from draft-bray-i-json-01. The WG will work on a format for a streamable sequence of JSON texts. The work will start from draft-williams-json-text-sequence-00. Milestones: IETF Last Call for restricted profile: June 2014 IETF Last Call for text sequences: June 2014 ========================== We note that there is no noticeable consensus around adding work on a single nomenclature / schema. There appears to be some interest in the WG coming up with some wording that says "the WG is not going to pick one yet, and we think that ABNF is certainly the wrong one". If someone wants to write up a draft with this kind of wording, we don't need to have it as a charter item: it could just be a message from the WG to the IESG, and they can ask us more if they want. --Paul Hoffman and Matt Miller From nobody Tue Mar 18 00:06:25 2014 Return-Path: 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 878F61A066C for ; Tue, 18 Mar 2014 00:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 vTOeb25JCKTt for ; Tue, 18 Mar 2014 00:06:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC441A0666 for ; Tue, 18 Mar 2014 00:06:19 -0700 (PDT) Received: from [192.168.2.117] ([93.217.98.154]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LmKag-1WyJu626Mc-00ZwdP; Tue, 18 Mar 2014 08:06:08 +0100 Message-ID: <5327F05E.7060905@gmx.de> Date: Tue, 18 Mar 2014 08:06:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matt Miller , IETF JSON WG References: <53277484.70305@cisco.com> In-Reply-To: <53277484.70305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bd6blAWG5mWLNb6qs2jbUCbMMS77/Yo3GV6fM+JVmt31dxhTwL+ a6+B3K6PphejO/02ggkrApp4gsD8NXGYTS8liiONdA+LsAB9xoCZ1nH4R7CeEUSCmx/kTvV DQWzFORgIW/bjJOwQNL2NFWmVpkMsc273JrFUQfK4s4u1pjSC/hb2WzBr6aA5UB2Vl5HBI3 C79WS8slYmuKUzRIj3XMw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/FBnECYvN9Hmjcl6EXsuD1eU71Ic Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:06:21 -0000 On 2014-03-17 23:17, Matt Miller wrote: > Greetings again. We earlier asked a couple of questions to gauge what > the new proposed WG charter ought to contain. That feedback has been > valuable, but has drilled into implementation specifics before a new > charter was actually agreed on! We have been chastised by our AD about > this, and for good reason. We think we already have enough input from > the London meeting and the list over the past few days to make the > following proposal for a new charter: > ... What happened to the proposal to add James Snell's json-merge draft to the list of WG items? Best regards, Julian From nobody Tue Mar 18 08:15:15 2014 Return-Path: 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 263091A06E8 for ; Tue, 18 Mar 2014 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 sn4WvzmiD9MG for ; Tue, 18 Mar 2014 08:14:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 73B481A06DA for ; Tue, 18 Mar 2014 08:14:43 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2IFETYo078284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 08:14:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5327F05E.7060905@gmx.de> Date: Tue, 18 Mar 2014 08:14:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Uu9EA9qmIE3B-xjyHJeO840QhE0 Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:14:59 -0000 On Mar 18, 2014, at 12:06 AM, Julian Reschke = wrote: > On 2014-03-17 23:17, Matt Miller wrote: >> Greetings again. We earlier asked a couple of questions to gauge = what >> the new proposed WG charter ought to contain. That feedback has been >> valuable, but has drilled into implementation specifics before a new >> charter was actually agreed on! We have been chastised by our AD = about >> this, and for good reason. We think we already have enough input = from >> the London meeting and the list over the past few days to make the >> following proposal for a new charter: >> ... >=20 > What happened to the proposal to add James Snell's json-merge draft to = the list of WG items? I don't remember that discussion. draft-ietf-appsawg-json-merge-patch = should still be part of AppsAWG; it just needs someone to take over the = work. --Paul Hoffman= From nobody Tue Mar 18 08:23:57 2014 Return-Path: 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 54FCE1A044F for ; Tue, 18 Mar 2014 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 TxOod_uEDVOq for ; Tue, 18 Mar 2014 08:23:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FD1A04E7 for ; Tue, 18 Mar 2014 08:23:53 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LqV4f-1X3xZn0cSn-00e478; Tue, 18 Mar 2014 16:23:42 +0100 Message-ID: <532864FC.8040700@gmx.de> Date: Tue, 18 Mar 2014 16:23:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sWXFF2XD/5J/00IokVhvy3HXlLOXskxIiyXu6syg2Iaqm71esBN NR2q2igpoY5p18ia3qa3TYOPrnokZxuiOVQPJy9fzBGircpeiw11AnwYytw+gLDuPhfoijG eTc8SZnwnYa1OvzEn9x/aZPmDTXVhpQqvq0JFEtqrS6fUUIhFBhrpCLneLkPjskpMt+0MOW 3DXQAGH8K5llmx31LoROw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/z6ZmBxWyRqX2f-8TEbG4cC3RtE0 Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:23:55 -0000 On 2014-03-18 16:14, Paul Hoffman wrote: > > On Mar 18, 2014, at 12:06 AM, Julian Reschke wrote: > >> On 2014-03-17 23:17, Matt Miller wrote: >>> Greetings again. We earlier asked a couple of questions to gauge what >>> the new proposed WG charter ought to contain. That feedback has been >>> valuable, but has drilled into implementation specifics before a new >>> charter was actually agreed on! We have been chastised by our AD about >>> this, and for good reason. We think we already have enough input from >>> the London meeting and the list over the past few days to make the >>> following proposal for a new charter: >>> ... >> >> What happened to the proposal to add James Snell's json-merge draft to the list of WG items? > > I don't remember that discussion. draft-ietf-appsawg-json-merge-patch should still be part of AppsAWG; it just needs someone to take over the work. > > --Paul Hoffman We talked about that after the WG meeting, didn't we? From nobody Tue Mar 18 08:27:58 2014 Return-Path: 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 BAF551A03BC for ; Tue, 18 Mar 2014 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 1tYxN1NQG_PK for ; Tue, 18 Mar 2014 08:27:51 -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 EA7791A0147 for ; Tue, 18 Mar 2014 08:27:50 -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.5/8.14.5) with ESMTP id s2IFRao0008792; Tue, 18 Mar 2014 16:27:36 +0100 (CET) Received: from [192.168.217.105] (p5489361B.dip0.t-ipconnect.de [84.137.54.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4C7632AD; Tue, 18 Mar 2014 16:27:35 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Tue, 18 Mar 2014 16:27:30 +0100 X-Mao-Original-Outgoing-Id: 416849250.746485-0d5206b20b905ccd49cf800c4822378b Content-Transfer-Encoding: quoted-printable Message-Id: References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/4LYKaKqe_Zm5iv9uxoLpiBS_uMY Cc: Julian Reschke , IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:27:53 -0000 On 18 Mar 2014, at 16:14, Paul Hoffman wrote: > I don't remember that discussion. draft-ietf-appsawg-json-merge-patch = should still be part of AppsAWG; it just needs someone to take over the = work. Since I wrote a somewhat detailed review of that draft in December (and = implemented it in the process to understand it better), I have talked to = James about possibly acting as an editor. =20 Gr=FC=DFe, Carsten From nobody Tue Mar 18 08:30:32 2014 Return-Path: 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 102011A03BC for ; Tue, 18 Mar 2014 08:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 mA-rqh8ncWXs for ; Tue, 18 Mar 2014 08:30:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 19AE81A037C for ; Tue, 18 Mar 2014 08:30:31 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2IFUGR1079142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 08:30:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <532864FC.8040700@gmx.de> Date: Tue, 18 Mar 2014 08:30:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/lxiJ7kanDV_7e3wE-YXk5NDeRwk Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:30:32 -0000 On Mar 18, 2014, at 8:23 AM, Julian Reschke = wrote: > On 2014-03-18 16:14, Paul Hoffman wrote: >>=20 >> On Mar 18, 2014, at 12:06 AM, Julian Reschke = wrote: >>=20 >>> On 2014-03-17 23:17, Matt Miller wrote: >>>> Greetings again. We earlier asked a couple of questions to gauge = what >>>> the new proposed WG charter ought to contain. That feedback has = been >>>> valuable, but has drilled into implementation specifics before a = new >>>> charter was actually agreed on! We have been chastised by our AD = about >>>> this, and for good reason. We think we already have enough input = from >>>> the London meeting and the list over the past few days to make the >>>> following proposal for a new charter: >>>> ... >>>=20 >>> What happened to the proposal to add James Snell's json-merge draft = to the list of WG items? >>=20 >> I don't remember that discussion. draft-ietf-appsawg-json-merge-patch = should still be part of AppsAWG; it just needs someone to take over the = work. >>=20 >> --Paul Hoffman >=20 > We talked about that after the WG meeting, didn't we? Errrr, maybe? Your recollection may be better than mine. Having said that, I'm not sure if this draft needs to move from AppsAWG: = it just needs an author to finish the draft. --Paul Hoffman= From nobody Tue Mar 18 08:38:53 2014 Return-Path: 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 0CACB1A042E for ; Tue, 18 Mar 2014 08:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 rRbS6Eiu0ABY for ; Tue, 18 Mar 2014 08:38:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19A1A03BC for ; Tue, 18 Mar 2014 08:38:50 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lpxdr-1X5cZF3xNn-00ffe7; Tue, 18 Mar 2014 16:38:39 +0100 Message-ID: <5328687D.9050509@gmx.de> Date: Tue, 18 Mar 2014 16:38:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Hoffman References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:RPAIoz6+tOu1GBXM6JSc/gYOahxk1gPrzWelX/i9yE9R0jyMDh0 8B6WcL51IS/lZQIjrQIWW8t6d90Oo25wIPef4qqsGUspNG7wQV4oMD7lQyrDdJsKcE11Gfr 2pQyDhWz+Ze5xq/h0AqxbP45bhjAy4AOkJDuKnJuIsHriTpS7BT7qvuCHGtiAZHi8g9KOGb fjPQeZmvKcvxDVz6ne9KA== Archived-At: http://mailarchive.ietf.org/arch/msg/json/NAPV6agPcdUo_R8-4ixQOuqJfjI Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:38:52 -0000 On 2014-03-18 16:30, Paul Hoffman wrote: > On Mar 18, 2014, at 8:23 AM, Julian Reschke wrote: > >> On 2014-03-18 16:14, Paul Hoffman wrote: >>> >>> On Mar 18, 2014, at 12:06 AM, Julian Reschke wrote: >>> >>>> On 2014-03-17 23:17, Matt Miller wrote: >>>>> Greetings again. We earlier asked a couple of questions to gauge what >>>>> the new proposed WG charter ought to contain. That feedback has been >>>>> valuable, but has drilled into implementation specifics before a new >>>>> charter was actually agreed on! We have been chastised by our AD about >>>>> this, and for good reason. We think we already have enough input from >>>>> the London meeting and the list over the past few days to make the >>>>> following proposal for a new charter: >>>>> ... >>>> >>>> What happened to the proposal to add James Snell's json-merge draft to the list of WG items? >>> >>> I don't remember that discussion. draft-ietf-appsawg-json-merge-patch should still be part of AppsAWG; it just needs someone to take over the work. >>> >>> --Paul Hoffman >> >> We talked about that after the WG meeting, didn't we? > > Errrr, maybe? Your recollection may be better than mine. > > Having said that, I'm not sure if this draft needs to move from AppsAWG: it just needs an author to finish the draft. ...and it needs review from people using JSON in protocols -- I *think* this is more likely to happen if if moves over to the JSON WG... From nobody Tue Mar 18 08:39:59 2014 Return-Path: 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 1B7C31A04AF for ; Tue, 18 Mar 2014 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 vXK9h5_HSUIZ for ; Tue, 18 Mar 2014 08:39:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 622EA1A042E for ; Tue, 18 Mar 2014 08:39:56 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.228.17]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3MAG-1XGnic1jTE-00r2B1; Tue, 18 Mar 2014 16:39:46 +0100 From: Bjoern Hoehrmann To: Matt Miller Date: Tue, 18 Mar 2014 16:39:45 +0100 Message-ID: References: <53277484.70305@cisco.com> In-Reply-To: <53277484.70305@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3uX3UhPM71kdCi1zvovWKI0h2wAHkZkvKBfoK5gzW92ZlO+Ik7T YJya6LcOr/qXcnHU/avQh9Hh3iTw4IMFs/U5UakwG83yA1uzj00BiW9A2LCvvB/F4bXTkcw TA7GEWDxHNLq/99EXc9gMOREH2Yb1oMj9kW98bUS9hp5Z5/o3HCv4dpKIwbDpnORCQBEMbT WvkiUZLXfNIUJAt+oxW6A== Archived-At: http://mailarchive.ietf.org/arch/msg/json/xhEpISmkHIyb9Lyo2Ov1P7gcXM8 Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:39:58 -0000 * Matt Miller wrote: >========================== >The WG will work on an restricted profile of JSON designed to maximize >interoperability. The work will start from draft-bray-i-json-01. I think there are already too many JSON specifications; adding more is harmful and should not be part of the Charter. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de Am Badedeich 7 Telefon: +49(0)160/4415681 http://www.bjoernsworld.de 25899 Dagebll PGP Pub. KeyID: 0xA4357E78 http://www.websitedev.de/ From nobody Tue Mar 18 08:41:15 2014 Return-Path: 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 C62451A0404 for ; Tue, 18 Mar 2014 08:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 EzsTE5NILWM2 for ; Tue, 18 Mar 2014 08:41:09 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 523FF1A03BC for ; Tue, 18 Mar 2014 08:41:09 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so7145572veb.24 for ; Tue, 18 Mar 2014 08:41:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7PhxcVX5Ehu7ofRzV/jW8LIyIpWWPAo4AO0gKOe142M=; b=MxZ+BgF95AxxYHae3d0os7Eww+48lsw0p+ZTWTlh9WHX86trOEkMDELBli5dKVtvXZ FuuqG9mVFH/p7mJbvxP4e5f43n/uCRMXDYwHIMkPEkWfUU7bHjdo7j3ia0+0Q2sLAZ4N Hxx+EAaIfWtIERVg1vziZL47tNHNSeI3pwbhCiFfFEd0WCxmk5J5cjYHI3KaOj+pkI7j HQWRmRSielLOF0wUQnGyvRBGy/x1NfYj05AslICVFqZlHvlvZGRtybPQ8hTpBgOHMOGA TV55yYSBPHZ3Rt8T+k/GyMESjM/LYuFc0+gTSyc5mJnEVZ4c6fP+MOg9MYH2lKGlIFFZ U6sg== X-Gm-Message-State: ALoCoQldpAg4M/2aGuZTCCM4paF4X/TKZAf7l+XNkMtrxKyvanMAxks72QLnoKcw2AeMSDF2SveG X-Received: by 10.220.250.203 with SMTP id mp11mr25331659vcb.2.1395157260894; Tue, 18 Mar 2014 08:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 18 Mar 2014 08:40:39 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5328687D.9050509@gmx.de> References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> From: Tim Bray Date: Tue, 18 Mar 2014 08:40:39 -0700 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013d0502f11aa004f4e35c45 Archived-At: http://mailarchive.ietf.org/arch/msg/json/p0WZ_61JdjU0JL2cMbGMT1310Nk Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:41:12 -0000 --089e013d0502f11aa004f4e35c45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It also needs some evidence that there=E2=80=99s actually a real-world need= , and that this isn=E2=80=99t just another solution in search of a problem. I ha= ven=E2=80=99t seen any such evidence yet. On Tue, Mar 18, 2014 at 8:38 AM, Julian Reschke wrot= e: > On 2014-03-18 16:30, Paul Hoffman wrote: > >> On Mar 18, 2014, at 8:23 AM, Julian Reschke >> wrote: >> >> On 2014-03-18 16:14, Paul Hoffman wrote: >>> >>>> >>>> On Mar 18, 2014, at 12:06 AM, Julian Reschke >>>> wrote: >>>> >>>> On 2014-03-17 23:17, Matt Miller wrote: >>>>> >>>>>> Greetings again. We earlier asked a couple of questions to gauge wh= at >>>>>> the new proposed WG charter ought to contain. That feedback has bee= n >>>>>> valuable, but has drilled into implementation specifics before a new >>>>>> charter was actually agreed on! We have been chastised by our AD >>>>>> about >>>>>> this, and for good reason. We think we already have enough input fr= om >>>>>> the London meeting and the list over the past few days to make the >>>>>> following proposal for a new charter: >>>>>> ... >>>>>> >>>>> >>>>> What happened to the proposal to add James Snell's json-merge draft t= o >>>>> the list of WG items? >>>>> >>>> >>>> I don't remember that discussion. draft-ietf-appsawg-json-merge-patch >>>> should still be part of AppsAWG; it just needs someone to take over th= e >>>> work. >>>> >>>> --Paul Hoffman >>>> >>> >>> We talked about that after the WG meeting, didn't we? >>> >> >> Errrr, maybe? Your recollection may be better than mine. >> >> Having said that, I'm not sure if this draft needs to move from AppsAWG: >> it just needs an author to finish the draft. >> > > ...and it needs review from people using JSON in protocols -- I *think* > this is more likely to happen if if moves over to the JSON WG... > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013d0502f11aa004f4e35c45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It = also needs some evidence that there=E2=80=99s actually a real-world need, a= nd that this isn=E2=80=99t just another solution in search of a problem. = =C2=A0I haven=E2=80=99t seen any such evidence yet.


On Tue,= Mar 18, 2014 at 8:38 AM, Julian Reschke <julian.reschke@gmx.de>= ; wrote:
On 2= 014-03-18 16:30, Paul Hoffman wrote:
On Mar 18, 2014, at 8:23 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

On 2014-03-18 16:14, Paul Hoffman wrote:

On Mar 18, 2014, at 12:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:

On 2014-03-17 23:17, Matt Miller wrote:
Greetings again. =C2=A0We earlier asked a couple of questions to gauge what=
the new proposed WG charter ought to contain. =C2=A0That feedback has been<= br> valuable, but has drilled into implementation specifics before a new
charter was actually agreed on! =C2=A0We have been chastised by our AD abou= t
this, and for good reason. =C2=A0We think we already have enough input from=
the London meeting and the list over the past few days to make the
following proposal for a new charter:
...

What happened to the proposal to add James Snell's json-merge draft to = the list of WG items?

I don't remember that discussion. draft-ietf-appsawg-json-merge-= patch should still be part of AppsAWG; it just needs someone to take over t= he work.

--Paul Hoffman

We talked about that after the WG meeting, didn't we?

Errrr, maybe? Your recollection may be better than mine.

Having said that, I'm not sure if this draft needs to move from AppsAWG= : it just needs an author to finish the draft.

...and it needs review from people using JSON in protocols -- I *think* thi= s is more likely to happen if if moves over to the JSON WG...



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e013d0502f11aa004f4e35c45-- From nobody Tue Mar 18 08:46:22 2014 Return-Path: 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 790E81A0421 for ; Tue, 18 Mar 2014 08:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 P8OaX4WoUBVM for ; Tue, 18 Mar 2014 08:46:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD091A041B for ; Tue, 18 Mar 2014 08:46:18 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M51eM-1XKfF82TlO-00zJpm; Tue, 18 Mar 2014 16:46:08 +0100 Message-ID: <53286A3E.3000907@gmx.de> Date: Tue, 18 Mar 2014 16:46:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tim Bray References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:lNJ5T0F9GShSO9nbhmNKU1GdwkE88edeCon91QfenpTiIEi4uI5 bgrJClXX+Y0DLdl02VkbNOOpFBX/DNf8g9atIP8hlHffmrJ0d4ed2kun4TNInfYYyo8TX6C tOLYAHJDWWoYpNZAE90nOeK/qyYthWFHTQbYxgauIL16xZEwX16BiJnF++qEotMLjNncOHu MAy7dRReVR4xRV9mXFH3g== Archived-At: http://mailarchive.ietf.org/arch/msg/json/zeJei6S211FbHAkqXe9zGVB_08I Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:46:20 -0000 On 2014-03-18 16:40, Tim Bray wrote: > It also needs some evidence that there’s actually a real-world need, and > that this isn’t just another solution in search of a problem. I haven’t > seen any such evidence yet. The evidence is that people are abusing application/json for PATCH requests already. The semantics of that is undefined right now. Best regards, Julian From nobody Tue Mar 18 08:53:17 2014 Return-Path: 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 907CD1A0429 for ; Tue, 18 Mar 2014 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.027 X-Spam-Level: X-Spam-Status: No, score=-9.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no 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 YkSSwlj0hF2K for ; Tue, 18 Mar 2014 08:53:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id D6B0E1A0421 for ; Tue, 18 Mar 2014 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1309; q=dns/txt; s=iport; t=1395157985; x=1396367585; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=pWWDZFSWvlVfZPsIuFDO+h1nFYSDvolCrCcSre1wDrQ=; b=fzjN8XOitlGFl9Qmlhp4722FZFjf+GVeSMBMAFZlZZfIkwh8002uYshD xk39LQPPZdWy3FDe9LJ8kWy/xwD7u5rEG2/R05wI7uOVIFBMMQqeaeZMO NohiOMkmh+vK0A6bkzNm7nSmZlog9Ce3zsQeQ+2z4iiD1UQjxAzlm2Gm6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8aAPxqKFOtJXG8/2dsb2JhbABagwY7V4MGpgoEmQ4lfhZ0gh0IAQEBBCMPAUUBEAsYAgIFFgsCAgkDAgECAUUTAQUCAQEXhVuCA61JojgXgSmNBjMHgm8PgToBA4lSjnSSMINMggw X-IronPort-AV: E=Sophos;i="4.97,678,1389744000"; d="scan'208";a="28377575" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 18 Mar 2014 15:53:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2IFr5H3016166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Mar 2014 15:53:05 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 10:53:05 -0500 Message-ID: <53286BE2.3020409@cisco.com> Date: Tue, 18 Mar 2014 09:53:06 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: IETF JSON WG References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> In-Reply-To: <53286A3E.3000907@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/json/K-bdE58IT_pKdkSEdaws2jhfVRM Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:53:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/18/14, 9:46 AM, Julian Reschke wrote: > On 2014-03-18 16:40, Tim Bray wrote: >> It also needs some evidence that there’s actually a real-world >> need, and that this isn’t just another solution in search of a >> problem. I haven’t seen any such evidence yet. > > The evidence is that people are abusing application/json for PATCH > requests already. The semantics of that is undefined right now. > /me doffs hat Teams I have worked with are already making use of json-merge-patch, after abusing application/json in exactly this way. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTKGviAAoJEDWi+S0W7cO1HBgH/03rzFMv1FGs10Cqz+pm+R// UBIRS+8apYIb0UWoXBSzht4/WCllsRmYYKDLpLbd+iU0g9QnPo1vWdm36EpjBnwY ozmNHHlgPrjoIWje2l13yUoQaFoYEb+iZGPLljcItqEnlgpOqdw288DkwuxhLDki kVG8vIlgniTLNhndH3iLAjhdU9r94RaxCkk93kH7J+xSkQKUe+VVtgbfvuIYu7Ar mCxba/+oQE7I3agvRGmfuiGfJ6bFX6DGYoUVH/6+X2ivyjjubEHmC2QfJkRYcwdf gryMiYx8REauUMw6bAJ8o0IPB8ujTqHBxBvKlvO50szsgh/AOCrME57wD8irrGQ= =5KYc -----END PGP SIGNATURE----- From nobody Tue Mar 18 08:53:53 2014 Return-Path: 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 190CC1A06E5 for ; Tue, 18 Mar 2014 08:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 M24LcB_YmWqO for ; Tue, 18 Mar 2014 08:53:50 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id A61E21A06D5 for ; Tue, 18 Mar 2014 08:53:48 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id cz12so7124598veb.21 for ; Tue, 18 Mar 2014 08:53:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Fh5zwDKZNF5PRNVA3pTuqLNUKr3d+nBKjduLdGRr5uI=; b=c7ofyncnb1ik+Td0uVQHpjuTUDoqz0VpJye5yyMxF7CMyWpTaGOU4KhbQCH8dVduTd V+tR2decWwWw5EMKRwiitQI1avppk5TEiI0tHNZ5A4D3bC86PPxxwyFLKU1Rw0evuhaG UyssLdlMWSLUAEq7Wb0EbeO0DwHgLyyeT3nVt1Irk4D0L6a13VTn7f61TY4fPU0JkuhT IW6aFcPCUys8tpSNTdMyvKzD5uNW3cjyWhLQlcNAuFrTZzVSfhi9nkIZYHUlXXkSwo/H S0/AZO8luNPapnRayWdmMptJf2a4Sqw27tDesMeQHyS05MRj39Mqm0G0VoPNvG3nKKeP tBXQ== X-Gm-Message-State: ALoCoQm/9w6NGekDyyFA01z1fPCtTWd8M8jirbGfGNVu1fR+Y3i53Ol3xtHe9YSjyRIJ3b8Z+8Al X-Received: by 10.58.55.170 with SMTP id t10mr4341125vep.29.1395158020244; Tue, 18 Mar 2014 08:53:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 18 Mar 2014 08:53:20 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <53286A3E.3000907@gmx.de> References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> From: Tim Bray Date: Tue, 18 Mar 2014 08:53:20 -0700 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b2e533634122604f4e38ad2 Archived-At: http://mailarchive.ietf.org/arch/msg/json/qFtlut5cYgbJo_hMot3LrI2xxDo Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:53:52 -0000 --047d7b2e533634122604f4e38ad2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Got some examples? I=E2=80=99ve not seen this, and a search for =E2=80=9Cj= son patch=E2=80=9D on stackoverflow.com has some discussions of the draft, but apparently nobody actually doing it. On Tue, Mar 18, 2014 at 8:46 AM, Julian Reschke wrot= e: > On 2014-03-18 16:40, Tim Bray wrote: > >> It also needs some evidence that there=E2=80=99s actually a real-world n= eed, and >> that this isn=E2=80=99t just another solution in search of a problem. I= haven=E2=80=99t >> seen any such evidence yet. >> > > The evidence is that people are abusing application/json for PATCH > requests already. The semantics of that is undefined right now. > > Best regards, Julian > > > > --047d7b2e533634122604f4e38ad2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Got= some examples? =C2=A0I=E2=80=99ve not seen this, and a search for =E2=80= =9Cjson patch=E2=80=9D on stackoverflo= w.com has some discussions of the draft, but apparently nobody actually= doing it.


On Tue,= Mar 18, 2014 at 8:46 AM, Julian Reschke <julian.reschke@gmx.de>= ; wrote:
On 2014-03-18 16:40, Tim Bra= y wrote:
It also needs some evidence that there=E2=80=99s actually a real-world need= , and
that this isn=E2=80=99t just another solution in search of a problem. =C2= =A0I haven=E2=80=99t
seen any such evidence yet.

The evidence is that people are abusing application/json for PATCH requests= already. The semantics of that is undefined right now.

Best regards, Julian




--047d7b2e533634122604f4e38ad2-- From nobody Tue Mar 18 09:03:07 2014 Return-Path: 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 6D82A1A0717 for ; Tue, 18 Mar 2014 09:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 oTIAxiDfH_wS for ; Tue, 18 Mar 2014 09:03:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BBD221A0721 for ; Tue, 18 Mar 2014 09:03:01 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MbJTE-1WiZI719oC-00InKB; Tue, 18 Mar 2014 17:02:51 +0100 Message-ID: <53286E29.90105@gmx.de> Date: Tue, 18 Mar 2014 17:02:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tim Bray References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xBbmVDCSIR+TF10ZyRlaXhUrnqbfe6N56KP4uvejc+zLdcte7gn Q4x1Eg1Pv9eAm8O0KvLeuWRr1nJJqZ/1dwR9gb7cp4l2wJoGHnRmZvECtFIbzKYpXu12SvL ALpmCwoJFvxVSo/eDjaQWRYJdRoFl/cVclee0W6XumblOQEWdTUql+hzOEwq15MNAGaHjcz iIGB9fuVq+pnNdxIrkkgg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/ArHWqEDGO0mn371-Wi_G9lmX1Hw Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:03:04 -0000 On 2014-03-18 16:53, Tim Bray wrote: > Got some examples? I’ve not seen this, and a search for “json patch” on > stackoverflow.com has some discussions of the > draft, but apparently nobody actually doing it. - The SCIM WG was trying to do this until recently. - You may also want to search for "rails json patch" - many rails users started with application/json and PUT for partial updates, and then switched to PATCH, but keeping the media type. This is what prompted Mark to raise . Best regards, Julian From nobody Tue Mar 18 09:20:06 2014 Return-Path: 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 BB4761A06D5 for ; Tue, 18 Mar 2014 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no 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 KBTyZXxXKyJd for ; Tue, 18 Mar 2014 09:19:59 -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 AABB61A0421 for ; Tue, 18 Mar 2014 09:19:58 -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.5/8.14.5) with ESMTP id s2IGJakp017927; Tue, 18 Mar 2014 17:19:36 +0100 (CET) Received: from [192.168.217.105] (p54890DCB.dip0.t-ipconnect.de [84.137.13.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5933031B; Tue, 18 Mar 2014 17:19:36 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <53286BE2.3020409@cisco.com> Date: Tue, 18 Mar 2014 17:19:31 +0100 X-Mao-Original-Outgoing-Id: 416852371.722982-dc24b6f78a84626e5e551e1791197c4e Content-Transfer-Encoding: quoted-printable Message-Id: <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/W1Kqjvm0lkYoGsaPghxGSIShG7k Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:20:00 -0000 On 18 Mar 2014, at 16:53, Matt Miller wrote: > Teams I have worked with are already making use of json-merge-patch, Are they using exactly what=92s in the draft right now (including the = somewhat surprising purge_nulls semantics)? It would help to get some feedback from actual users of this. Gr=FC=DFe, Carsten From nobody Tue Mar 18 09:29:06 2014 Return-Path: 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 80AB31A06E1 for ; Tue, 18 Mar 2014 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ekLiFszXSFPa for ; Tue, 18 Mar 2014 09:29:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E45CC1A06EA for ; Tue, 18 Mar 2014 09:29:02 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LvDpe-1X8X5z31ve-010Ilt; Tue, 18 Mar 2014 17:28:53 +0100 Message-ID: <53287443.2060405@gmx.de> Date: Tue, 18 Mar 2014 17:28:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann , Matt Miller References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> In-Reply-To: <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:E3m2MKgfljAjwvMjdLvlWBXGAi9l1j/6lx1Lr5Pw2drrzLBDJ+j IYb5Hfd8iA7NyXnSqjH93DgwoLFeEGkAkXu7KEhDVAAOGjFWq0277GvJ1BuB5S8eje/zPBE uDugAtZ4evAAOtZMyL56SN+REbu8RKsY8hO6fbDOLbpg+61icnc2A+LzqseNOY8eSAOdY7b AsnRB/H13DtqnI7kkfpNg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/sbI0HCexRRnt0S8v7At_Ua5UGY4 Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:29:05 -0000 On 2014-03-18 17:19, Carsten Bormann wrote: > On 18 Mar 2014, at 16:53, Matt Miller wrote: > >> Teams I have worked with are already making use of json-merge-patch, > > Are they using exactly whats in the draft right now (including the somewhat surprising purge_nulls semantics)? > It would help to get some feedback from actual users of this. > ... q.e.d. :-) From nobody Tue Mar 18 09:45:55 2014 Return-Path: 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 962161A06E8 for ; Tue, 18 Mar 2014 09:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 ixeC-eYWPaSJ for ; Tue, 18 Mar 2014 09:45:50 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 80E841A06D8 for ; Tue, 18 Mar 2014 09:45:50 -0700 (PDT) Received: from [93.197.208.123] by 3capp-webde-bs20 with HTTP; Tue, 18 Mar 2014 17:45:41 +0100 MIME-Version: 1.0 Message-ID: From: "Stefan Drees" To: "Julian Reschke" Content-Type: text/html; charset=UTF-8 Date: Tue, 18 Mar 2014 17:45:41 +0100 Importance: normal Sensitivity: Normal In-Reply-To: <53287443.2060405@gmx.de> References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org>, <53287443.2060405@gmx.de> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:TpB1YUhKMD4o12IyLsrtO23h6vUI+O4NiCfz+KNPp8M VtXNr/iiX2w6io50nqywE2+rADELMtliG/zOSS/PVQAujjRmLl MyFUYxCSyFiZK+aTFJB9iTEPcK/d3jT8wCIzh/KDBOTD/qpjbT ZokM9hehnAWcaBMvc5XuRPeI1EVCGwAZ/EBRTzvbWCviFZNA1Q ApcKWkTXAOH7HchYsYYIpiZKry8a5c+atVZKayAbsw1NtCDsac /V6kGP5Ww7DOjVRfntqn4QAtPm8w12GY3AMqjjRcq4S7pvUUHm GQjkCCHGBs0jFHesBOYOACfC4gM Archived-At: http://mailarchive.ietf.org/arch/msg/json/mYP1DdCFt9_9JvppRbuSN_se254 Cc: IETF JSON WG Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:45:52 -0000
+1 on inclusion of James Snell's "JSON Merge Patch" (draft-ietf-appsawg-json-merge-patch-02) into charter (if possible).
 
Top-postingly-yours,
Stefan.
Gesendet: Dienstag, 18. März 2014 um 17:28 Uhr
Von: "Julian Reschke" <julian.reschke@gmx.de>
An: "Carsten Bormann" <cabo@tzi.org>, "Matt Miller" <mamille2@cisco.com>
Cc: "IETF JSON WG" <json@ietf.org>
Betreff: Re: [Json] Proposed Wording for New WG Charter
On 2014-03-18 17:19, Carsten Bormann wrote:
> On 18 Mar 2014, at 16:53, Matt Miller <mamille2@cisco.com> wrote:
>
>> Teams I have worked with are already making use of json-merge-patch,
>
> Are they using exactly what’s in the draft right now (including the somewhat surprising purge_nulls semantics)?
> It would help to get some feedback from actual users of this.
> ...

q.e.d. :-)

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
From nobody Tue Mar 18 09:46:17 2014 Return-Path: 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 233301A0722 for ; Tue, 18 Mar 2014 09:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.027 X-Spam-Level: X-Spam-Status: No, score=-9.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no 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 eTFjU9ajCiYh for ; Tue, 18 Mar 2014 09:46:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14C1A0724 for ; Tue, 18 Mar 2014 09:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1425; q=dns/txt; s=iport; t=1395161164; x=1396370764; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=rjk21e/M/Bjk++wZKfr3AP/cT5i/FXBNzitRnALzym4=; b=gbsPQ7onRNq9RvVZhp8JZOJbacJfyiTlPNA2vELYy+PMyQsBG4uB/i6M 2AqyV4LVB5yAHwpqUSDnMJYuuSGc+9b4BXR7y7TIbUlm4/Z0W+Ccmozg0 vRR2I5EY2LL3NPm1q3AvtuYcuQBf5HyQFCqY6EiWl0ee+uwVFrIHqCeUC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcaAKB3KFOtJXG+/2dsb2JhbABagwY7V6kRBJkOJYEBFnSCHQgBAQEEMgFFARALGAkWDwkDAgECAUUTAQUCAQGFcoID0BgXji8zB4J+gToBA4lSjnSSMINMggw X-IronPort-AV: E=Sophos;i="4.97,678,1389744000"; d="scan'208";a="28394741" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-8.cisco.com with ESMTP; 18 Mar 2014 16:46:03 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2IGk30T006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Mar 2014 16:46:03 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 11:46:03 -0500 Message-ID: <5328784C.9090507@cisco.com> Date: Tue, 18 Mar 2014 10:46:04 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: IETF JSON WG References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> In-Reply-To: <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/json/KM_T0V2S4UWwW52H_viCwlz5_H0 Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:46:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/18/14, 10:19 AM, Carsten Bormann wrote: > On 18 Mar 2014, at 16:53, Matt Miller wrote: > >> Teams I have worked with are already making use of >> json-merge-patch, > > Are they using exactly whats in the draft right now (including the > somewhat surprising purge_nulls semantics)? It would help to get > some feedback from actual users of this. > > Gre, Carsten > /me urges this to be the last time we talk about json-merge-patch details on this list and not apps-discuss@ (-: /me continues with no hat I tried to get them to post something, but I think all of their points have already been noted on the the relevant list. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTKHhMAAoJEDWi+S0W7cO18NQH/iqbDjuwKSSwtuXR7X2fl6Hz mh7WazUdXEKpSTerLZ7YVG2YIXk/ODW/UCnp1n28fAkjbsCBXoT6tGhKgqkAgSC9 lXfgk09tePQa1liuTXrIs+Du8Aw7VYdZu4AdGVRCVOdHEtLBBJg+hh+fEfhOYjtQ STe+YxLkY1Jfod/sM1gYuQbR8WAunN2YGt1n4WWgvoLoXHB4YZ/XUjX220yHynq+ 14Fkw9wHimqrbZC1mNJ960ugYt3uv6upPLSAsDwa5LmyKVqdG9lOmnLPoCY9wGk1 9pUsCYRlKi2K+3pDdUh0XEjtlLgIymn/dqSYxDeoptRz/FLw0quQTsFKGCftJ6M= =UB1F -----END PGP SIGNATURE----- From nobody Tue Mar 18 09:48:08 2014 Return-Path: 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 8DB991A0722 for ; Tue, 18 Mar 2014 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.027 X-Spam-Level: X-Spam-Status: No, score=-14.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 AU4LZKCtU1e1 for ; Tue, 18 Mar 2014 09:48:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 894721A06FC for ; Tue, 18 Mar 2014 09:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1000; q=dns/txt; s=iport; t=1395161275; x=1396370875; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=V+y7qMOLF0ORVx6rnuMl2w5hhimK6HJ2HYf2V+ROJdA=; b=Oa8i/VjjQmfIP4BtCnFTv8rllk4KUF/ko+PCNipp2gX2Ul/i8ZpYfUbk /fDva2HAlS4dvYIRpx3uOSLXFfmIIdjnhpP6s1UAg18vr+KVskFwpq8ls xGSQsIs4eqFEF3LY8NFWpIQgOJiIkJokttTAvgTi5+4CNnqGDsWv+6DEA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYaACN4KFOtJXG9/2dsb2JhbABagwY7V6kRBJkOJYEBFnSCHQgBAQEEeAEQCxgJFg8JAwIBAgFFEwEFAgEBhXKCA9AaF44vMweCfoE6AQOJUo50kjCDTIIM X-IronPort-AV: E=Sophos;i="4.97,678,1389744000"; d="scan'208";a="310932647" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 18 Mar 2014 16:47:55 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2IGltfS008680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Mar 2014 16:47:55 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 11:47:54 -0500 Message-ID: <532878BB.1050708@cisco.com> Date: Tue, 18 Mar 2014 10:47:55 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: IETF JSON WG References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org>, <53287443.2060405@gmx.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/json/8j69PtqF4LL3IvPIuuN_gdgImsQ Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:48:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/18/14, 10:45 AM, Stefan Drees wrote: > +1 on inclusion of James Snell's "JSON Merge Patch" > (draft-ietf-appsawg-json-merge-patch-02) into charter (if > possible). > Please note this document is already a work item in progress for APPSAWG. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTKHi7AAoJEDWi+S0W7cO1HN4H/RjaJJNpQt5kQo9fnnbBFkp4 ygkqxnNcRSC5E3G0II9RyuKSvQBEwjF+Dl+w/te9Hqo22v8HSA9i207r5pZ7uuJJ Qw8z/kaYUsGKUZFi2i3Lwch87d9AekN+c/ea1ivjJkpqcNc8CQmxFRXyX1DhTSCB dFORYoCx5qL9C5is7UBKQpNEyHY9mZfNCrAq2zqQVItHS4u6iuVOR/H86Fhm1Udy T7lWOa2Tv/n5z8AgdmE9b4s8l7Xe/Qmah6hVCMeNbSffQSoqaJ2i/26pFQ9GvYjX Yk7KH8HzfpQvLjJtzX1bIyTIjTOQAO2V9a0tIVGFmBZfia5WC45QKXfFMJ+aAc8= =lPrj -----END PGP SIGNATURE----- From nobody Tue Mar 18 10:05:44 2014 Return-Path: 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 3ECC51A0717 for ; Tue, 18 Mar 2014 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 b3LXIzbAGyWy for ; Tue, 18 Mar 2014 10:05:35 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (agjbgdcfdbed.dreamhost.com [69.163.253.143]) by ietfa.amsl.com (Postfix) with ESMTP id E1E561A0720 for ; Tue, 18 Mar 2014 10:04:57 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id B0B532005D10B for ; Tue, 18 Mar 2014 10:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/9bjR0scAy/PPHCj7xafPyEvdhk=; b=voZ8nTLcecq wSwKrKLLE5XG6o7KtqGi1kd51WOPjajY5yDRoQ+osna8j1AoaJOXvpadYW/2S5iV TQ4GyVdl04LQVvnWmPgnUGeV66RghjDEy+fSDwwt6Vo7lsTHrGtLlNLxxqrlJ5Ep yhlTpbZ6wqPezuNSNTkUxnZ0WgRn4zBI= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 651BC2005D107 for ; Tue, 18 Mar 2014 10:04:49 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so6217032wes.27 for ; Tue, 18 Mar 2014 10:04:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d2aaKweKRez/ZqOrTykL7zqcKMLSIko1kjMke0wSUk0=; b=EyTdlnoYOB1xuOtNfw9qG37ERjOPgZR/di+4Tz6ohFtTzwMpsayZcup0VtLY5iIM8e QOwCd/jBxeiOKP4O7ncVJJcLQ4hx+yyHyvvHhA8hA/XbgI08kf/J9UwNaNj+6DN1T8oY KV6qYxtenJcRqi1QP7f4/jueEM5HlwT8GOjkAkNcMVkDDOacZN5lv60P/WNtq6gx87u+ ChWKAY8VAXmtmEmykZnnidIt3wX43k10BWc50IyPBFE6ljfN6g1w0p5vKHSVZIDhHKQZ HuQexTZJBzCs7qwFNFSyC2xDuuNOjjHOpYPEaqHKnqPRTOJmpoQFixUixrYBUQMgSsUL KV7g== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr15706696wib.39.1395162288129; Tue, 18 Mar 2014 10:04:48 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Tue, 18 Mar 2014 10:04:48 -0700 (PDT) In-Reply-To: <53287443.2060405@gmx.de> References: <53277484.70305@cisco.com> <5327F05E.7060905@gmx.de> <532864FC.8040700@gmx.de> <5328687D.9050509@gmx.de> <53286A3E.3000907@gmx.de> <53286BE2.3020409@cisco.com> <82F6EE3B-B659-460C-AD1C-7303D4F53333@tzi.org> <53287443.2060405@gmx.de> Date: Tue, 18 Mar 2014 12:04:48 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/z3U-KQ2rRWKGTlvq0lH8MyDMEkw Cc: Carsten Bormann , IETF JSON WG , Matt Miller Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:05:40 -0000 On Tue, Mar 18, 2014 at 11:28 AM, Julian Reschke wr= ote: > On 2014-03-18 17:19, Carsten Bormann wrote: >> >> On 18 Mar 2014, at 16:53, Matt Miller wrote: >> >>> Teams I have worked with are already making use of json-merge-patch, >> >> >> Are they using exactly what=E2=80=99s in the draft right now (including = the >> somewhat surprising purge_nulls semantics)? >> It would help to get some feedback from actual users of this. >> ... I had the same question. That's not the only problem. Suppose I have a 100KB JSON text and I want to make a minor change. But there's no way with the proposed JSON merge to say "add this item to that array" without listing all the values that should remain, so this merge spec isn't very patch-y. > q.e.d. :-) Well played! I'm now +1 on accepting this. One Rails app I work with has a schema for PUT that allows for patching, effectively, but its patch syntax is very specific to that application (although it may come from a gem for all I know; I'll try to find out). I'm not remotely sold on the currently proposed JSON merge spec, but at least one -possibly various- JSON PATCH mechanisms is needed. Nico -- From nobody Wed Mar 19 12:22:52 2014 Return-Path: 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 A04B91A07B9 for ; Wed, 19 Mar 2014 12:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 F6RjESTOHVqz for ; Wed, 19 Mar 2014 12:22:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2EE1A07E5 for ; Wed, 19 Mar 2014 12:22:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B26B67FC394; Wed, 19 Mar 2014 12:22:35 -0700 (PDT) To: tbray@textuality.com, barryleiba@computer.org, presnick@qti.qualcomm.com, mamille2@cisco.com, paul.hoffman@vpnc.org From: RFC Errata System Message-Id: <20140319192235.B26B67FC394@rfc-editor.org> Date: Wed, 19 Mar 2014 12:22:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/json/HpE75CzHkSgK9NKAUZy0GuFtmBw Cc: naesten@gmail.com, rfc-editor@rfc-editor.org, json@ietf.org Subject: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 19:22:49 -0000 The following errata report has been submitted for RFC7159, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7159&eid=3922 -------------------------------------- Type: Editorial Reported by: Samuel Bronson Section: GLOBAL Original Text ------------- Corrected Text -------------- See RFC 7158. Notes ----- This RFC has no actual changes relative to RFC 7158: https://tools.ietf.org/rfcdiff?url1=rfc7158&url2=rfc7159 shows the ONLY changes being to the year or due to the new RFC number. This RFC might as well be replaced in its entirety by "See RFC 7158." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : March 2014 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Mar 19 13:00:03 2014 Return-Path: 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 DB1DA1A07E5 for ; Wed, 19 Mar 2014 13:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 Kwwt4glWWvN8 for ; Wed, 19 Mar 2014 13:00:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A13F41A07E2 for ; Wed, 19 Mar 2014 12:59:28 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JJxFm2038487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 12:59:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140319192235.B26B67FC394@rfc-editor.org> Date: Wed, 19 Mar 2014 12:59:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> References: <20140319192235.B26B67FC394@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/rKuhMSDjsuM2HTVhdzJVeWmuDg4 Cc: Pete Resnick , json@ietf.org, naesten@gmail.com, Tim Bray , mamille2@cisco.com, Barry Leiba Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 20:00:02 -0000 Please reject this errata report. There was a conscious decision made by = the RFC Editor to issue the new RFC; the fact that the reporter doesn't = like that decision does not warrant an errata. --Paul Hoffman, JSON WG co-chair= From nobody Wed Mar 19 13:24:07 2014 Return-Path: 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 C6F271A0753 for ; Wed, 19 Mar 2014 13:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 Ljlxbr_53NSr for ; Wed, 19 Mar 2014 13:24:06 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CD4921A0489 for ; Wed, 19 Mar 2014 13:24:05 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id e16so10522262qcx.34 for ; Wed, 19 Mar 2014 13:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oPnRb64Zs7ODXpHPC6kIJ3FGoU7XqZ+kGYYL08CSJBU=; b=njlSxfjhNmJdP2wz1PVOyype5N2vK8UOvk/PVs+su4EAkbfnCJlRgS//iOKPKU7j4W ms0ltUI0s2HX2KiFISEzOaUNtNiAjVd1LsRY+9aiiaZaRXSOaUdNIN5V5nXACfvd6xVh ebw/9dv+RpnlF/hWVLCxh4fo4tNcaWPS+KprL/ylOZot23U1Ml6vD5wo47gJLgkziPbb exB4p1hZ3tT5juRk6RIKyL6UAv7deaYfZ9ZUAvraVs6mERw37CmPjtAczwPMTM2AIIrq DzwMDcGkJQXdjZAd2h/+xZwblyEmwKSIE3tMG4eMbInNMDJxB3NcKETzSEUfVh7jG+ec 527Q== MIME-Version: 1.0 X-Received: by 10.229.112.5 with SMTP id u5mr45847307qcp.3.1395260636953; Wed, 19 Mar 2014 13:23:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.42.136 with HTTP; Wed, 19 Mar 2014 13:23:56 -0700 (PDT) In-Reply-To: <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> References: <20140319192235.B26B67FC394@rfc-editor.org> <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> Date: Wed, 19 Mar 2014 16:23:56 -0400 X-Google-Sender-Auth: ETg1pLq5ZfCI_QHqJ7cGgplytUA Message-ID: From: Barry Leiba To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11330a74a29cd804f4fb6e37 Archived-At: http://mailarchive.ietf.org/arch/msg/json/KnjmM0oZ83j6nqslAz2rRD8gP9M Cc: Pete Resnick , "json@ietf.org" , "naesten@gmail.com" , Tim Bray , "mamille2@cisco.com" , RFC Errata System Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 20:24:07 -0000 --001a11330a74a29cd804f4fb6e37 Content-Type: text/plain; charset=ISO-8859-1 I'd sat this shouldn't be marked "Rejected", but should instead be removed from the errata system. What does the RFC Editor think? Barry On Wednesday, March 19, 2014, Paul Hoffman wrote: > Please reject this errata report. There was a conscious decision made by > the RFC Editor to issue the new RFC; the fact that the reporter doesn't > like that decision does not warrant an errata. > > --Paul Hoffman, JSON WG co-chair --001a11330a74a29cd804f4fb6e37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd sat this shouldn't be marked "Rejected", but should i= nstead be removed from the errata system. =A0What does the RFC Editor think= ?

Barry

On Wednesday, March 19, 2014, Paul Hoffma= n <paul.hoffman@vpnc.org>= ; wrote:
Please reject this errata report. There was = a conscious decision made by the RFC Editor to issue the new RFC; the fact = that the reporter doesn't like that decision does not warrant an errata= .

--Paul Hoffman, JSON WG co-chair
--001a11330a74a29cd804f4fb6e37-- From nobody Wed Mar 19 13:29:02 2014 Return-Path: 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 F1B111A07BE for ; Wed, 19 Mar 2014 13:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 66LI_xZjkNTx for ; Wed, 19 Mar 2014 13:28:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 692E51A048A for ; Wed, 19 Mar 2014 13:28:59 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2JKSmFA039620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 13:28:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Wed, 19 Mar 2014 13:28:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140319192235.B26B67FC394@rfc-editor.org> <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> To: Barry Leiba X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/oTaDlbVulYtUHM0--dWqVEqnYlU Cc: Pete Resnick , "json@ietf.org" , "naesten@gmail.com" , Tim Bray , "mamille2@cisco.com" , RFC Errata System Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 20:29:01 -0000 On Mar 19, 2014, at 1:23 PM, Barry Leiba = wrote: > I'd sat this shouldn't be marked "Rejected", but should instead be = removed from the errata system. What does the RFC Editor think? I forgot that was an option; agree (if it's possible). --Paul Hoffman= From nobody Wed Mar 19 16:46:07 2014 Return-Path: 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 5E5971A0815 for ; Wed, 19 Mar 2014 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_12LTRDOM=0.1, IP_NOT_FRIENDLY=0.334] autolearn=no 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 S_FxKWfMZ_G7 for ; Wed, 19 Mar 2014 16:46:03 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (agjbgdcfdbfh.dreamhost.com [69.163.253.157]) by ietfa.amsl.com (Postfix) with ESMTP id 99DA51A0813 for ; Wed, 19 Mar 2014 16:46:01 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 009EF598058 for ; Wed, 19 Mar 2014 16:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=ECOFRs6AehhdLW+PKH/OZtirOsc=; b=Hl6wbwXLkRP 06dc1R+owi4puidJ8pRF8NZmMH8S45ntVN/h9svhcJmCyym1p/loFNoVzdXKXIsV 2Cw3HmkQKMEPEAynsJTnSiR5BO9geD67Ki+11/w7wc9UcFi4zleu6ea0averV/DO 1aiua545SGter1M9bOu3VhDFeK2x3yhc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id B204F598055 for ; Wed, 19 Mar 2014 16:45:52 -0700 (PDT) Date: Wed, 19 Mar 2014 18:45:51 -0500 From: Nico Williams To: json@ietf.org Message-ID: <20140319234549.GA3471@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/oq6viR3uoMVszDUOhR_yoQ2ZAFk Subject: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 23:46:05 -0000 First, IMO the WG should in fact adopt a WG item (or more) for MIME types for use with PATCH to patch JSON texts (or entities with JSON representations). This is commonly known as "JSON merge", IIUC. I work with one Rails application that has an ad-hoc JSON merge like schema for representing updates (PUTs) to resources -- this schema is very specific to the application in question, therefore not reusable. I can imagine a Ruby gem that handles a JSON merge PATCH in a completely general and reusable way. And not just Ruby, of course. Second, I believe the JSON merge proposals I've seen to date are no good. The goal of any Internet JSON merge schema should be to: Concisely and generally express "edits" to a JSON text, efficiently allowing: - replacement of any values - prepend/insert/replace/append to arrays - addition/removal of names from objects - setting null values to object names no matter how deeply (subject to a max) or shallowly nested these values be in the original, while being easy to produce and apply. Note: it helps to use If-Match to make sure that the resource being PATCHed has not been modified since it was fetched. This allows one to express edits with confidence. I have two proposals: one based on augmenting a subset of the original JSON text, the other based a sequence of paths and edit instructions for the values found at those paths. Proposal #1: Patch as augmented subset of the original Follow these steps to produce a patch: - Start with the resource's JSON representation. - Remove all interior object name/value pairs that are not on the way to any value to be added/replaced/removed/otherwise edited. - Remove all interior array elements that are not on the way to any value to be added/replaced/removed UNLESS the element is in an array to be edited (more on this below). - Insert before each remaining array element its index. - To replace any value with a scalar, just write the new value where the old one appeared. - To append to any array, just append -1 and the new value to it (after the above removals and additions). - For any array you want to do more to than append -> wrap the array in an object with any of these named values: o "delete": [] o "prepend": [] o "insert": [, ]>] o "set": [, ]>] o "new": [] o "edits": [] To disambiguate these objects from objects that could legitimately appear in the resource the following named value MUST also be present: o "": true Replacements to be performed first, then deletions, then insertions, then prepends, then "edits". Edits are what would have appeared had there been no need to wrap the array in order to do delete, prepend, replace, or insert elements. - To add name/value pairs to objects, just add them. - If you want to delete values from objects -> wrap the object in an object with any of these names: o "delete": [] o "edits": Edits are what would have appeared had there been no need to wrap the object to delete name/value pairs. To disambiguate these names the following named value MUST also be present: o "": true Values to be added/set appear as they should appear in the resource as patched. Patch application is straightforward, obvious. Example resource: { "a": [ { "b": 1, "c": 2 }, { "d": { "e": [ 2, {} ] } } ], "z": [ true, false, null, null, "hello" ] } Example edits: - Delete that empty object (path a[0].d.e[1] in jq-speak) { "a": [ 1, { "d": { "e": { "delete": [ 1 ], "urn:ietf.org:TBD": true } } } ] } - Replace the array [ 2, {} ] (path a[0].d.e in jq-speak) with the value 0: { "a": [ 1, { "d": { "e": 0 } } ] } - Append true to the array [ 2, {} ] (path a[0].d.e in jq-speak): { "a": [ 1, { "d": { "e": [ true ] } } ] } - Delete the 1, prepend "foo", append "bar" to that same array: { "a": [ 1, { "d": { "e": { "delete": [ 0 ], "prepend": [ "foo" ], "edits": [ "bar" ], "urn:ietf.org:TBD": true } } } ] } - Add a sibling name to "b" and "c": { "a": [ 0, { "f": "hello" } ] } - Delete "b": { "a": [ 0, { "delete": [ "b" ], "urn:ietf.org:TBD": true } ] } - Replace the "z" array with [1, 2, 3]: { "z": { "new": [ 1, 2, 3, ], "urn:ietf.org:TBD": true } } Proposal #2: Use sequence of [, ] - Write the path to each value to be edited as an array of path elements (strings for object names, numbers for array elements). - To replace any value with a scalar value (non-array, non-object), just write the path to the value and the new value as the instruction. - To add a value to an object just write the path to the object, append the new value's name to the path, and the instruction will be the new value. - To add (append) a value to an array, write the path to the array, append a -1 to the path, and the instruction will be the new value. - Edit instructions for arrays (other than appending to, or replacing the whole array with a scalar value) are any objects like: o "delete": [] or true (if path names an array element) o "add": [s to append] o "insert": [, ] pairs>] o "set": [, ] pairs>] o "prepend": [s to prepend] o "add": [s to append] o "new": [] No magic URN name is needed in this case. - To add an object - Edit instructions for objects (other than replacement with a scalar value) are objects with name/value pairs like: o "delete": [] o "merge": [] No magic URN name is needed in this case. The totality of the patch, then, is an array of [ , ] elements. Any given path could be referenced multiple times in one patch. Proposal #2 is pretty self-explanatory. Examples left as an exercise for the reader. Nico -- From nobody Wed Mar 19 16:57:18 2014 Return-Path: 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 CB7151A0817 for ; Wed, 19 Mar 2014 16:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 YKg72hoRil76 for ; Wed, 19 Mar 2014 16:57:12 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC71A0811 for ; Wed, 19 Mar 2014 16:57:12 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.54.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB72B22E200; Wed, 19 Mar 2014 19:56:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <20140319234549.GA3471@localhost> Date: Thu, 20 Mar 2014 10:56:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> References: <20140319234549.GA3471@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/kO3XZJieNt12Zqe3sd1VzjorgiM Cc: json@ietf.org Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 23:57:16 -0000 Hi Nico, = http://mailarchive.ietf.org/arch/msg/apps-discuss/mvUVvUt41tFTrPSOCfv7sfbl= TUM Cheers, On 20 Mar 2014, at 10:45 am, Nico Williams = wrote: > First, IMO the WG should in fact adopt a WG item (or more) for MIME > types for use with PATCH to patch JSON texts (or entities with JSON > representations). This is commonly known as "JSON merge", IIUC. >=20 > I work with one Rails application that has an ad-hoc JSON merge like > schema for representing updates (PUTs) to resources -- this schema is > very specific to the application in question, therefore not reusable. >=20 > I can imagine a Ruby gem that handles a JSON merge PATCH in a = completely > general and reusable way. And not just Ruby, of course. >=20 > Second, I believe the JSON merge proposals I've seen to date are no > good. >=20 > The goal of any Internet JSON merge schema should be to: >=20 > Concisely and generally express "edits" to a JSON text, efficiently > allowing: >=20 > - replacement of any values > - prepend/insert/replace/append to arrays > - addition/removal of names from objects > - setting null values to object names >=20 > no matter how deeply (subject to a max) or shallowly nested these > values be in the original, while being easy to produce and apply. >=20 > Note: it helps to use If-Match to make sure that the resource being > PATCHed has not been modified since it was fetched. This allows one = to > express edits with confidence. >=20 > I have two proposals: one based on augmenting a subset of the original > JSON text, the other based a sequence of paths and edit instructions = for > the values found at those paths. >=20 >=20 > Proposal #1: Patch as augmented subset of the original >=20 > Follow these steps to produce a patch: >=20 > - Start with the resource's JSON representation. >=20 > - Remove all interior object name/value pairs that are not on the way > to any value to be added/replaced/removed/otherwise edited. >=20 > - Remove all interior array elements that are not on the way to any > value to be added/replaced/removed UNLESS the element is in an array > to be edited (more on this below). >=20 > - Insert before each remaining array element its index. >=20 > - To replace any value with a scalar, just write the new value where > the old one appeared. >=20 > - To append to any array, just append -1 and the new value to it = (after > the above removals and additions). >=20 > - For any array you want to do more to than append -> wrap the array = in > an object with any of these named values: >=20 > o "delete": [] > o "prepend": [] > o "insert": [, ]>] > o "set": [, ]>] > o "new": [] > o "edits": [] >=20 > To disambiguate these objects from objects that could legitimately > appear in the resource the following named value MUST also be > present: >=20 > o "": true >=20 > Replacements to be performed first, then deletions, then insertions, > then prepends, then "edits". Edits are what would have appeared > had there been no need to wrap the array in order to do delete, > prepend, replace, or insert elements. >=20 > - To add name/value pairs to objects, just add them. >=20 > - If you want to delete values from objects -> wrap the object in an > object with any of these names: >=20 > o "delete": [] > o "edits": >=20 > Edits are what would have appeared had there been no need to wrap = the > object to delete name/value pairs. >=20 > To disambiguate these names the following named value MUST also be > present: >=20 > o "": true >=20 > Values to be added/set appear as they should appear in the resource as > patched. >=20 > Patch application is straightforward, obvious. >=20 > Example resource: >=20 > { > "a": [ { "b": 1, "c": 2 }, { "d": { "e": [ 2, {} ] } } ], > "z": [ true, false, null, null, "hello" ] > } >=20 > Example edits: >=20 > - Delete that empty object (path a[0].d.e[1] in jq-speak) >=20 > { "a": [ 1, { "d": { "e": { "delete": [ 1 ], > "urn:ietf.org:TBD": true } } } ] } >=20 > - Replace the array [ 2, {} ] (path a[0].d.e in jq-speak) with the > value 0: >=20 > { "a": [ 1, { "d": { "e": 0 } } ] } >=20 > - Append true to the array [ 2, {} ] (path a[0].d.e in jq-speak): >=20 > { "a": [ 1, { "d": { "e": [ true ] } } ] } >=20 > - Delete the 1, prepend "foo", append "bar" to that same array: >=20 > { "a": [ 1, { "d": { "e": { "delete": [ 0 ], > "prepend": [ "foo" ], > "edits": [ "bar" ], > "urn:ietf.org:TBD": true } } } ] } >=20 > - Add a sibling name to "b" and "c": >=20 > { "a": [ 0, { "f": "hello" } ] } >=20 > - Delete "b": >=20 > { "a": [ 0, { "delete": [ "b" ], "urn:ietf.org:TBD": true } ] } >=20 > - Replace the "z" array with [1, 2, 3]: >=20 > { "z": { "new": [ 1, 2, 3, ], "urn:ietf.org:TBD": true } } >=20 > Proposal #2: Use sequence of [, ] >=20 > - Write the path to each value to be edited as an array of path > elements (strings for object names, numbers for array elements). >=20 > - To replace any value with a scalar value (non-array, non-object), > just write the path to the value and the new value as the > instruction. >=20 > - To add a value to an object just write the path to the object, = append > the new value's name to the path, and the instruction will be the = new > value. >=20 > - To add (append) a value to an array, write the path to the array, > append a -1 to the path, and the instruction will be the new value. >=20 > - Edit instructions for arrays (other than appending to, or replacing > the whole array with a scalar value) are any objects like: >=20 > o "delete": [] or true (if path names an array > element) >=20 > o "add": [s to append] >=20 > o "insert": [, ] pairs>] > o "set": [, ] pairs>] > o "prepend": [s to prepend] > o "add": [s to append] > o "new": [] >=20 > No magic URN name is needed in this case. >=20 > - To add an object >=20 > - Edit instructions for objects (other than replacement with a scalar > value) are objects with name/value pairs like: >=20 > o "delete": [] > o "merge": [ corresponding ones of the object being edited>] >=20 > No magic URN name is needed in this case. >=20 > The totality of the patch, then, is an array of > [ , ] elements. >=20 > Any given path could be referenced multiple times in one patch. >=20 > Proposal #2 is pretty self-explanatory. Examples left as an exercise > for the reader. >=20 > Nico > --=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From nobody Wed Mar 19 17:01:30 2014 Return-Path: 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 E5BB21A0821 for ; Wed, 19 Mar 2014 17:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 U5i9nna8kwAe for ; Wed, 19 Mar 2014 17:01:26 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (agjbgdcfdbgc.dreamhost.com [69.163.253.162]) by ietfa.amsl.com (Postfix) with ESMTP id 640721A0811 for ; Wed, 19 Mar 2014 17:01:26 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id BD95D584064 for ; Wed, 19 Mar 2014 17:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=e1V3MCXc1kI/Uqz04HCl VbTC7fU=; b=BNG+cOMoEpm2nl83FUBmiljLC3ojZRlDt3K8HlIBb+vEgScakHSF dQAyDYlcPo8t3/lPtpegY1hlXZcvUYXhokhlsO0bOMOgjVomNBAluR2sxvMvk7gy JvA1bnP5WAr5CpfsbeUOGsV/2G/KQExraedpBEdDLZQwUTfUa58tADE= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 71E27584056 for ; Wed, 19 Mar 2014 17:01:17 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so159239wiw.6 for ; Wed, 19 Mar 2014 17:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QWpOqUyYzEhFpW+sXLfwH5PdDLO0T9r/qtfUfNVBEHw=; b=TCYp7dhFcYoqxMfpOk6paaLE8Ug+VdTPfd3vZPC14SOawnDUR/9eI+T0lSDoQSTGff aCi2/rjYnZxl26AeHub/qVn13Gaak9Tr58dZ00lxPkozKDPkNksUD1GGQIW98rD+ZEMq cyubc1OKv8KBsFNl2RzESbY5vOl5xqEncq8kjnFWencHDS0Vi/w9rRKaUu0SSvUGYZsP g5TRayEk+qIN4a+L+LX78qpuX0rVnaq3egz7usPWpFej9yGp2uDpoDzXJ9Gg0imnXo8v OtTgbNFmqJAYelWU1TNh9b1d9+LLtKK/PlgdyLlNeJRr28c1mMX9VK3rlN/Tmh0jJ6dt kI/Q== MIME-Version: 1.0 X-Received: by 10.194.90.107 with SMTP id bv11mr31209069wjb.11.1395273676174; Wed, 19 Mar 2014 17:01:16 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 17:01:16 -0700 (PDT) In-Reply-To: <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> Date: Wed, 19 Mar 2014 19:01:16 -0500 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/hboKT2gJP71831Te5vk4zL0Z0ZQ Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:01:28 -0000 On Wed, Mar 19, 2014 at 6:56 PM, Mark Nottingham wrote: > http://mailarchive.ietf.org/arch/msg/apps-discuss/mvUVvUt41tFTrPSOCfv7sfblTUM I.e., draft-ietf-appsawg-json-merge-patch, which has the same problems mentioned recently on this list (e.g., using null to mean delete). Nico -- From nobody Wed Mar 19 17:05:20 2014 Return-Path: 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 684DD1A0836 for ; Wed, 19 Mar 2014 17:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 FMugxEfBW44W for ; Wed, 19 Mar 2014 17:05:17 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (unknown [69.163.253.172]) by ietfa.amsl.com (Postfix) with ESMTP id C197B1A0843 for ; Wed, 19 Mar 2014 17:05:17 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 1BFFD350090 for ; Wed, 19 Mar 2014 17:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fvsf2VPrjzh+NLI/+71r SvafoWc=; b=EXlZYmjidKspT7yukAPWDtp5Vogry64eIYmVbzsS59pKLtELYKKN hdODsedYAKcgzTCC6rATxarPpvYCenAc5mJOWOiezOClVf3QyZfxum/iBNasot28 eTiQq6YCw+GBvthjQXC2guJBwY3xrg01/3gJuC0Bg3zYE40k2shEGic= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id C385435008F for ; Wed, 19 Mar 2014 17:05:08 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so55244wes.41 for ; Wed, 19 Mar 2014 17:05:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtk94h5CAxjPf2Npe7D7VYDsBlxhfsdBRKfgWfv9zC8=; b=bOZ5ylAabvJL1lrvlrM5CjSHQAn4DBNhDeK+Yr40r/bbOESSN71bIFlnOk70xHKL8k 9K0w/OOyHh5CgTLWK90BFwb0wYl9gZiFXxBTHn1yvGgv1MxHydD+ad73uD62XdWhL2qT sgoDXvQb4Z7SKo81noMtfWR9+UDDfSpi2WJRc6brubnUFq20FSEs8fKYGCrGkRgbV1IX /PY74tJneQ2aLvqUAKUTdTvkKY8K+jJuSvdBWAHXvv4hU2uTckPKu5gs/YE1TeYXygI6 dSpV/i6nTXDqdjmJQt3+AgiR7FQXPqp85sea/vDDODg4J18nwlUNVeoUaZGKpyfA1D7O lONg== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr22209319wib.5.1395273907764; Wed, 19 Mar 2014 17:05:07 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 17:05:07 -0700 (PDT) In-Reply-To: <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> Date: Wed, 19 Mar 2014 19:05:07 -0500 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/vk16_r0K83fTNXlDq7VKpSWalC4 Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:05:18 -0000 I was responding to the question about whether the JSON WG should re-charter to include JSON merge as a work item. I suppose perhaps you're saying that JSON merge is an Apps area work item and should stay in Apps. But I can't quite tell if that's what you meant. Nico -- From nobody Wed Mar 19 17:13:14 2014 Return-Path: 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 DA5501A0830 for ; Wed, 19 Mar 2014 17:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 uS_J08Q4X0KE for ; Wed, 19 Mar 2014 17:13:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 001C51A0821 for ; Wed, 19 Mar 2014 17:13:08 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.54.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A6BFA22E255; Wed, 19 Mar 2014 20:12:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Thu, 20 Mar 2014 11:12:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <86C8BE43-5CA4-4F33-AA49-7028C2CDF59B@mnot.net> References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/lpW8KdFRhAn3J6Z2kkI6Y7TIDTI Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:13:11 -0000 On 20 Mar 2014, at 11:01 am, Nico Williams = wrote: > On Wed, Mar 19, 2014 at 6:56 PM, Mark Nottingham = wrote: >> = http://mailarchive.ietf.org/arch/msg/apps-discuss/mvUVvUt41tFTrPSOCfv7sfbl= TUM >=20 > I.e., draft-ietf-appsawg-json-merge-patch, which has the same problems > mentioned recently on this list (e.g., using null to mean delete). ... and it's looking for an editor. Why not just take it over and gain = consensus there? > I suppose perhaps you're saying that JSON merge is an Apps area work > item and should stay in Apps. But I can't quite tell if that's what > you meant. I don't like venue shopping. json-merge-patch is still technically an = active item in APPSAWG AIUI, so if you don't like it, you should discuss = it over there. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Mar 19 17:21:19 2014 Return-Path: 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 9793A1A0844 for ; Wed, 19 Mar 2014 17:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 k0Q0OGexFM19 for ; Wed, 19 Mar 2014 17:21:16 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (agjbgdcfdbhb.dreamhost.com [69.163.253.171]) by ietfa.amsl.com (Postfix) with ESMTP id 75B861A0843 for ; Wed, 19 Mar 2014 17:21:16 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id DFB4E438079 for ; Wed, 19 Mar 2014 17:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dZvaxSNa7k6l4AXYug95 Um8wzsQ=; b=x8q+56WVE2yTaAqMZihSZNAQ9zAG5Of5/7KayRrt0UsyvLx0D1ls g721CCPGpFVzA52/dizqPMiyLJrn96jGQLZHkg5OgQ55aVYoT3gBZpx+B+6JZACi lBp7qaOine7/lnM49F4iidjru5CxnC0sd9owKD6ZtfPvAqjgu9oauHs= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 910F1438072 for ; Wed, 19 Mar 2014 17:21:07 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so62318wes.27 for ; Wed, 19 Mar 2014 17:21:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LF+F4QkvKBAPsAIiZqMrsd3HOEHYdlOmhgZbKXjRdx4=; b=EJNb4HE5KrHbWnFCiSOpnam7p/6VpsXRpu4SV8oDpyEXL9bBounO3w/sXmg/tt0T4G pIgz+b5K4g/3oZOsbTH6xEV+f7A2VJyYW3Kt8Dxh4O0Doz0nEAX8fXfe/+t6jDH3dwqa qzyVgQOh8BEGZeWFxx1VpHqVmEW6Y99hX0Ypec+Z5M8ehR3DqGQD3Ax9gdbuYraOgF1v tEAdtptVAla+CdqkZqibrhCQn/7JyAXr5iuBqAq7g0B4reUlOBKk+kgJ2+isuiS1E3W/ SuP4WVu9E1EoaRHKmfEUeA/JgtINkMVLGYtWDLhkg+TcR3Com9AsspZ1mqUcVYDvpo4X VT5Q== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr22485568wib.42.1395274866424; Wed, 19 Mar 2014 17:21:06 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 17:21:06 -0700 (PDT) In-Reply-To: <86C8BE43-5CA4-4F33-AA49-7028C2CDF59B@mnot.net> References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> <86C8BE43-5CA4-4F33-AA49-7028C2CDF59B@mnot.net> Date: Wed, 19 Mar 2014 19:21:06 -0500 Message-ID: From: Nico Williams To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/0kAYxskXnY-KYflPvR7cw6wfk-I Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:21:17 -0000 On Wed, Mar 19, 2014 at 7:12 PM, Mark Nottingham wrote: > On 20 Mar 2014, at 11:01 am, Nico Williams wrote: >> On Wed, Mar 19, 2014 at 6:56 PM, Mark Nottingham wrote: >> I suppose perhaps you're saying that JSON merge is an Apps area work >> item and should stay in Apps. But I can't quite tell if that's what >> you meant. > > I don't like venue shopping. json-merge-patch is still technically an active item in APPSAWG AIUI, so if you don't like it, you should discuss it over there. Thanks for clarifying. The question of whether to have it as a JSON WG work item was raised by someone else, and I had no idea that it existed as an Apps area work item. (Yes, I could and should have noticed, but having missed it I wouldn't have been able to read your mind either :) As for venue, I don't care, and since it's an existing work item for Apps, that disposes of the question as far as I'm concerned. Others here might disagree. I might volunteer to take it over if there was consensus for a proposal that I liked. I'll resend my proposals to apps-discuss. Thanks, Nico -- From nobody Wed Mar 19 17:23:44 2014 Return-Path: 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 4E9EF1A0821 for ; Wed, 19 Mar 2014 17:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 56Q9ZFYhIkQ1 for ; Wed, 19 Mar 2014 17:23:40 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EAD631A0848 for ; Wed, 19 Mar 2014 17:23:39 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.54.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 341A322E1FA; Wed, 19 Mar 2014 20:23:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Thu, 20 Mar 2014 11:23:26 +1100 Content-Transfer-Encoding: 7bit Message-Id: <5E56079D-398F-4D24-9B1E-A8141C5FC04B@mnot.net> References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> <86C8BE43-5CA4-4F33-AA49-7028C2CDF59B@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/79O6njUeWZDBpTqM89u4b_B8H-0 Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:23:41 -0000 On 20 Mar 2014, at 11:21 am, Nico Williams wrote: > I might volunteer to take it over if there was consensus for a > proposal that I liked. I'll resend my proposals to apps-discuss. Cool -- I'd like to see *something* in that area progress. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Mar 19 17:35:33 2014 Return-Path: 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 25F0F1A0831 for ; Wed, 19 Mar 2014 17:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 NSKe_Pz6zGZO for ; Wed, 19 Mar 2014 17:35:28 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id C07281A0833 for ; Wed, 19 Mar 2014 17:35:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,690,1389704400"; d="scan'208";a="202824955" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 Mar 2014 11:35:06 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7382"; a="261937622" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Mar 2014 11:35:06 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 20 Mar 2014 11:35:06 +1100 From: "Manger, James" To: Nico Williams , "json@ietf.org" Date: Thu, 20 Mar 2014 11:35:05 +1100 Thread-Topic: [Json] JSON merge alternatives Thread-Index: Ac9DzWMzeAxeC3EtScm9zkauyIhg8QAAHcZw Message-ID: <255B9BB34FB7D647A506DC292726F6E115406DAAF6@WSMSG3153V.srv.dir.telstra.com> References: <20140319234549.GA3471@localhost> In-Reply-To: <20140319234549.GA3471@localhost> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/PzZlV9mCCfkuKtfKonataZcBef4 Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:35:31 -0000 UkZDIDY5MDIgIkphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKSBQYXRjaCIgbG9va3Mg cXVpdGUgY2xvc2UgdG8gcHJvcG9zYWwgMi4NCk1lZGlhIHR5cGU6IGFwcGxpY2F0aW9uL2pzb24t cGF0Y2granNvbg0KT3BlcmF0aW9uczogYWRkLCByZW1vdmUsIHJlcGxhY2UsIG1vdmUsIGNvcHks IHRlc3QNCg0KDQpkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1tZXJnZS1wYXRjaCAiSlNPTiBNZXJn ZSBQYXRjaCIgaXMgYSBzaW1wbGVyIHN1YnNldCBvZiBwcm9wb3NhbCAxLiBJdCBpcyBkZXNpZ25l ZCB0byB3b3JrIHdlbGwgd2l0aCBKU09OIG9iamVjdHMsIGFuZCBvYmplY3RzIG5lc3RlZCBpbiBv YmplY3RzIGV0Yy4gSXRzIG1haW4gbGltaXRhdGlvbiAoY29tcGFyZWQgdG8gcHJvcG9zYWwgMSkg aXMgdGhhdCBpdCBkb2Vzbid0IHN1cHBvcnQgaW5zZXJ0L3JlcGxhY2UgZm9yIGluZGl2aWR1YWwg YXJyYXkgZWxlbWVudHMuDQoNCg0KQWRkaW5nIGEgIm1lcmdlIiBvcGVyYXRpb24gdG8gUkZDIDY5 MDIgd291bGQgYmUgYW5vdGhlciB3YXkgdG8gZ2V0IHRoZSBiZXN0IG9mIGJvdGggdGhlc2UgYXBw cm9hY2hlcy4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGpzb24gW21haWx0bzpqc29uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBOaWNvIFdpbGxpYW1zDQpTZW50OiBUaHVyc2RheSwgMjAgTWFyY2ggMjAxNCAxMDo0NiBB TQ0KVG86IGpzb25AaWV0Zi5vcmcNClN1YmplY3Q6IFtKc29uXSBKU09OIG1lcmdlIGFsdGVybmF0 aXZlcw0KDQpGaXJzdCwgSU1PIHRoZSBXRyBzaG91bGQgaW4gZmFjdCBhZG9wdCBhIFdHIGl0ZW0g KG9yIG1vcmUpIGZvciBNSU1FDQp0eXBlcyBmb3IgdXNlIHdpdGggUEFUQ0ggdG8gcGF0Y2ggSlNP TiB0ZXh0cyAob3IgZW50aXRpZXMgd2l0aCBKU09ODQpyZXByZXNlbnRhdGlvbnMpLiAgVGhpcyBp cyBjb21tb25seSBrbm93biBhcyAiSlNPTiBtZXJnZSIsIElJVUMuDQoNCkkgd29yayB3aXRoIG9u ZSBSYWlscyBhcHBsaWNhdGlvbiB0aGF0IGhhcyBhbiBhZC1ob2MgSlNPTiBtZXJnZSBsaWtlDQpz Y2hlbWEgZm9yIHJlcHJlc2VudGluZyB1cGRhdGVzIChQVVRzKSB0byByZXNvdXJjZXMgLS0gdGhp cyBzY2hlbWEgaXMNCnZlcnkgc3BlY2lmaWMgdG8gdGhlIGFwcGxpY2F0aW9uIGluIHF1ZXN0aW9u LCB0aGVyZWZvcmUgbm90IHJldXNhYmxlLg0KDQpJIGNhbiBpbWFnaW5lIGEgUnVieSBnZW0gdGhh dCBoYW5kbGVzIGEgSlNPTiBtZXJnZSBQQVRDSCBpbiBhIGNvbXBsZXRlbHkNCmdlbmVyYWwgYW5k IHJldXNhYmxlIHdheS4gIEFuZCBub3QganVzdCBSdWJ5LCBvZiBjb3Vyc2UuDQoNClNlY29uZCwg SSBiZWxpZXZlIHRoZSBKU09OIG1lcmdlIHByb3Bvc2FscyBJJ3ZlIHNlZW4gdG8gZGF0ZSBhcmUg bm8NCmdvb2QuDQoNClRoZSBnb2FsIG9mIGFueSBJbnRlcm5ldCBKU09OIG1lcmdlIHNjaGVtYSBz aG91bGQgYmUgdG86DQoNCiAgIENvbmNpc2VseSBhbmQgZ2VuZXJhbGx5IGV4cHJlc3MgImVkaXRz IiB0byBhIEpTT04gdGV4dCwgZWZmaWNpZW50bHkNCiAgIGFsbG93aW5nOg0KDQogICAgLSByZXBs YWNlbWVudCBvZiBhbnkgdmFsdWVzDQogICAgLSBwcmVwZW5kL2luc2VydC9yZXBsYWNlL2FwcGVu ZCB0byBhcnJheXMNCiAgICAtIGFkZGl0aW9uL3JlbW92YWwgb2YgbmFtZXMgZnJvbSBvYmplY3Rz DQogICAgLSBzZXR0aW5nIG51bGwgdmFsdWVzIHRvIG9iamVjdCBuYW1lcw0KDQogICBubyBtYXR0 ZXIgaG93IGRlZXBseSAoc3ViamVjdCB0byBhIG1heCkgb3Igc2hhbGxvd2x5IG5lc3RlZCB0aGVz ZQ0KICAgdmFsdWVzIGJlIGluIHRoZSBvcmlnaW5hbCwgd2hpbGUgYmVpbmcgZWFzeSB0byBwcm9k dWNlIGFuZCBhcHBseS4NCiAgIA0KTm90ZTogaXQgaGVscHMgdG8gdXNlIElmLU1hdGNoIHRvIG1h a2Ugc3VyZSB0aGF0IHRoZSByZXNvdXJjZSBiZWluZw0KUEFUQ0hlZCBoYXMgbm90IGJlZW4gbW9k aWZpZWQgc2luY2UgaXQgd2FzIGZldGNoZWQuICBUaGlzIGFsbG93cyBvbmUgdG8NCmV4cHJlc3Mg ZWRpdHMgd2l0aCBjb25maWRlbmNlLg0KDQpJIGhhdmUgdHdvIHByb3Bvc2Fsczogb25lIGJhc2Vk IG9uIGF1Z21lbnRpbmcgYSBzdWJzZXQgb2YgdGhlIG9yaWdpbmFsDQpKU09OIHRleHQsIHRoZSBv dGhlciBiYXNlZCBhIHNlcXVlbmNlIG9mIHBhdGhzIGFuZCBlZGl0IGluc3RydWN0aW9ucyBmb3IN CnRoZSB2YWx1ZXMgZm91bmQgYXQgdGhvc2UgcGF0aHMuDQoNCg0KUHJvcG9zYWwgIzE6IFBhdGNo IGFzIGF1Z21lbnRlZCBzdWJzZXQgb2YgdGhlIG9yaWdpbmFsDQoNCkZvbGxvdyB0aGVzZSBzdGVw cyB0byBwcm9kdWNlIGEgcGF0Y2g6DQoNCiAtIFN0YXJ0IHdpdGggdGhlIHJlc291cmNlJ3MgSlNP TiByZXByZXNlbnRhdGlvbi4NCg0KIC0gUmVtb3ZlIGFsbCBpbnRlcmlvciBvYmplY3QgbmFtZS92 YWx1ZSBwYWlycyB0aGF0IGFyZSBub3Qgb24gdGhlIHdheQ0KICAgdG8gYW55IHZhbHVlIHRvIGJl IGFkZGVkL3JlcGxhY2VkL3JlbW92ZWQvb3RoZXJ3aXNlIGVkaXRlZC4NCg0KIC0gUmVtb3ZlIGFs bCBpbnRlcmlvciBhcnJheSBlbGVtZW50cyB0aGF0IGFyZSBub3Qgb24gdGhlIHdheSB0byBhbnkN CiAgIHZhbHVlIHRvIGJlIGFkZGVkL3JlcGxhY2VkL3JlbW92ZWQgVU5MRVNTIHRoZSBlbGVtZW50 IGlzIGluIGFuIGFycmF5DQogICB0byBiZSBlZGl0ZWQgKG1vcmUgb24gdGhpcyBiZWxvdykuDQoN CiAtIEluc2VydCBiZWZvcmUgZWFjaCByZW1haW5pbmcgYXJyYXkgZWxlbWVudCBpdHMgaW5kZXgu DQoNCiAtIFRvIHJlcGxhY2UgYW55IHZhbHVlIHdpdGggYSBzY2FsYXIsIGp1c3Qgd3JpdGUgdGhl IG5ldyB2YWx1ZSB3aGVyZQ0KICAgdGhlIG9sZCBvbmUgYXBwZWFyZWQuDQoNCiAtIFRvIGFwcGVu ZCB0byBhbnkgYXJyYXksIGp1c3QgYXBwZW5kIC0xIGFuZCB0aGUgbmV3IHZhbHVlIHRvIGl0IChh ZnRlcg0KICAgdGhlIGFib3ZlIHJlbW92YWxzIGFuZCBhZGRpdGlvbnMpLg0KDQogLSBGb3IgYW55 IGFycmF5IHlvdSB3YW50IHRvIGRvIG1vcmUgdG8gdGhhbiBhcHBlbmQgLT4gd3JhcCB0aGUgYXJy YXkgaW4NCiAgIGFuIG9iamVjdCB3aXRoIGFueSBvZiB0aGVzZSBuYW1lZCB2YWx1ZXM6DQoNCiAg ICBvICJkZWxldGUiOiAgWzxsaXN0IG9mIGFycmF5IGluZGljZXM+XQ0KICAgIG8gInByZXBlbmQi OiBbPGxpc3Qgb2YgdmFsdWVzIHRvIGFwcGVuZD5dDQogICAgbyAiaW5zZXJ0IjogIFs8bGlzdCBv ZiBbPGluZGV4PiwgPHZhbHVlPl0+XQ0KICAgIG8gInNldCI6ICAgICBbPGxpc3Qgb2YgWzxpbmRl eD4sIDx2YWx1ZT5dPl0NCiAgICBvICJuZXciOiAgICAgWzxsaXN0IG9mIG5ldyBlbGVtZW50cyB0 byByZXBsYWNlIHRoZSBvbGQgb25lJ3Mgd2l0aD5dDQogICAgbyAiZWRpdHMiOiAgIFs8bGlzdCBv ZiBlZGl0cyAoc2VlIGJlbG93KT5dDQoNCiAgIFRvIGRpc2FtYmlndWF0ZSB0aGVzZSBvYmplY3Rz IGZyb20gb2JqZWN0cyB0aGF0IGNvdWxkIGxlZ2l0aW1hdGVseQ0KICAgYXBwZWFyIGluIHRoZSBy ZXNvdXJjZSB0aGUgZm9sbG93aW5nIG5hbWVkIHZhbHVlIE1VU1QgYWxzbyBiZQ0KICAgcHJlc2Vu dDoNCg0KICAgIG8gIjxVUk4gVEJEPiI6IHRydWUNCg0KICAgUmVwbGFjZW1lbnRzIHRvIGJlIHBl cmZvcm1lZCBmaXJzdCwgdGhlbiBkZWxldGlvbnMsIHRoZW4gaW5zZXJ0aW9ucywNCiAgIHRoZW4g cHJlcGVuZHMsIHRoZW4gImVkaXRzIi4gIEVkaXRzIGFyZSB3aGF0IHdvdWxkIGhhdmUgYXBwZWFy ZWQNCiAgIGhhZCB0aGVyZSBiZWVuIG5vIG5lZWQgdG8gd3JhcCB0aGUgYXJyYXkgaW4gb3JkZXIg dG8gZG8gZGVsZXRlLA0KICAgcHJlcGVuZCwgcmVwbGFjZSwgb3IgaW5zZXJ0IGVsZW1lbnRzLg0K DQogLSBUbyBhZGQgbmFtZS92YWx1ZSBwYWlycyB0byBvYmplY3RzLCBqdXN0IGFkZCB0aGVtLg0K DQogLSBJZiB5b3Ugd2FudCB0byBkZWxldGUgdmFsdWVzIGZyb20gb2JqZWN0cyAtPiB3cmFwIHRo ZSBvYmplY3QgaW4gYW4NCiAgIG9iamVjdCB3aXRoIGFueSBvZiB0aGVzZSBuYW1lczoNCg0KICAg IG8gImRlbGV0ZSI6IFs8bGlzdCBvZiBuYW1lIHN0cmluZ3M+XQ0KICAgIG8gImVkaXRzIjogIDxv YmplY3QgY29udGFpbmludCBlZGl0cz4NCg0KICAgRWRpdHMgYXJlIHdoYXQgd291bGQgaGF2ZSBh cHBlYXJlZCBoYWQgdGhlcmUgYmVlbiBubyBuZWVkIHRvIHdyYXAgdGhlDQogICBvYmplY3QgdG8g ZGVsZXRlIG5hbWUvdmFsdWUgcGFpcnMuDQoNCiAgIFRvIGRpc2FtYmlndWF0ZSB0aGVzZSBuYW1l cyB0aGUgZm9sbG93aW5nIG5hbWVkIHZhbHVlIE1VU1QgYWxzbyBiZQ0KICAgcHJlc2VudDoNCg0K ICAgIG8gIjxVUk4gVEJEPiI6IHRydWUNCg0KVmFsdWVzIHRvIGJlIGFkZGVkL3NldCBhcHBlYXIg YXMgdGhleSBzaG91bGQgYXBwZWFyIGluIHRoZSByZXNvdXJjZSBhcw0KcGF0Y2hlZC4NCg0KUGF0 Y2ggYXBwbGljYXRpb24gaXMgc3RyYWlnaHRmb3J3YXJkLCBvYnZpb3VzLg0KDQpFeGFtcGxlIHJl c291cmNlOg0KDQogIHsNCiAgICAiYSI6IFsgeyAiYiI6IDEsICJjIjogMiB9LCB7ICJkIjogeyAi ZSI6IFsgMiwge30gXSB9IH0gXSwNCiAgICAieiI6IFsgdHJ1ZSwgZmFsc2UsIG51bGwsIG51bGws ICJoZWxsbyIgXQ0KICB9DQoNCkV4YW1wbGUgZWRpdHM6DQoNCiAtIERlbGV0ZSB0aGF0IGVtcHR5 IG9iamVjdCAocGF0aCBhWzBdLmQuZVsxXSBpbiBqcS1zcGVhaykNCg0KICAgeyAiYSI6IFsgMSwg eyAiZCI6IHsgImUiOiB7ICJkZWxldGUiOiBbIDEgXSwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAidXJuOmlldGYub3JnOlRCRCI6IHRydWUgfSB9IH0gXSB9DQoNCiAtIFJlcGxhY2Ug dGhlIGFycmF5IFsgMiwge30gXSAocGF0aCBhWzBdLmQuZSBpbiBqcS1zcGVhaykgd2l0aCB0aGUN CiAgIHZhbHVlIDA6DQoNCiAgIHsgImEiOiBbIDEsIHsgImQiOiB7ICJlIjogMCB9IH0gXSB9DQoN CiAtIEFwcGVuZCB0cnVlIHRvIHRoZSBhcnJheSBbIDIsIHt9IF0gKHBhdGggYVswXS5kLmUgaW4g anEtc3BlYWspOg0KDQogICB7ICJhIjogWyAxLCB7ICJkIjogeyAiZSI6IFsgdHJ1ZSBdIH0gfSBd IH0NCg0KIC0gRGVsZXRlIHRoZSAxLCBwcmVwZW5kICJmb28iLCBhcHBlbmQgImJhciIgdG8gdGhh dCBzYW1lIGFycmF5Og0KDQogICB7ICJhIjogWyAxLCB7ICJkIjogeyAiZSI6IHsgImRlbGV0ZSI6 IFsgMCBdLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJwcmVwZW5kIjogWyAiZm9v IiBdLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJlZGl0cyI6IFsgImJhciIgXSwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAidXJuOmlldGYub3JnOlRCRCI6IHRydWUg fSB9IH0gXSB9DQoNCiAtIEFkZCBhIHNpYmxpbmcgbmFtZSB0byAiYiIgYW5kICJjIjoNCg0KICAg eyAiYSI6IFsgMCwgeyAiZiI6ICJoZWxsbyIgfSBdIH0NCg0KIC0gRGVsZXRlICJiIjoNCg0KICAg eyAiYSI6IFsgMCwgeyAiZGVsZXRlIjogWyAiYiIgXSwgInVybjppZXRmLm9yZzpUQkQiOiB0cnVl IH0gXSB9DQoNCiAtIFJlcGxhY2UgdGhlICJ6IiBhcnJheSB3aXRoIFsxLCAyLCAzXToNCg0KICAg eyAieiI6IHsgIm5ldyI6IFsgMSwgMiwgMywgXSwgInVybjppZXRmLm9yZzpUQkQiOiB0cnVlIH0g fQ0KDQpQcm9wb3NhbCAjMjogVXNlIHNlcXVlbmNlIG9mIFs8cGF0aD4sIDxlZGl0IGluc3RydWN0 aW9uPl0NCg0KIC0gV3JpdGUgdGhlIHBhdGggdG8gZWFjaCB2YWx1ZSB0byBiZSBlZGl0ZWQgYXMg YW4gYXJyYXkgb2YgcGF0aA0KICAgZWxlbWVudHMgKHN0cmluZ3MgZm9yIG9iamVjdCBuYW1lcywg bnVtYmVycyBmb3IgYXJyYXkgZWxlbWVudHMpLg0KDQogLSBUbyByZXBsYWNlIGFueSB2YWx1ZSB3 aXRoIGEgc2NhbGFyIHZhbHVlIChub24tYXJyYXksIG5vbi1vYmplY3QpLA0KICAganVzdCB3cml0 ZSB0aGUgcGF0aCB0byB0aGUgdmFsdWUgYW5kIHRoZSBuZXcgdmFsdWUgYXMgdGhlDQogICBpbnN0 cnVjdGlvbi4NCg0KIC0gVG8gYWRkIGEgdmFsdWUgdG8gYW4gb2JqZWN0IGp1c3Qgd3JpdGUgdGhl IHBhdGggdG8gdGhlIG9iamVjdCwgYXBwZW5kDQogICB0aGUgbmV3IHZhbHVlJ3MgbmFtZSB0byB0 aGUgcGF0aCwgYW5kIHRoZSBpbnN0cnVjdGlvbiB3aWxsIGJlIHRoZSBuZXcNCiAgIHZhbHVlLg0K DQogLSBUbyBhZGQgKGFwcGVuZCkgYSB2YWx1ZSB0byBhbiBhcnJheSwgd3JpdGUgdGhlIHBhdGgg dG8gdGhlIGFycmF5LA0KICAgYXBwZW5kIGEgLTEgdG8gdGhlIHBhdGgsIGFuZCB0aGUgaW5zdHJ1 Y3Rpb24gd2lsbCBiZSB0aGUgbmV3IHZhbHVlLg0KDQogLSBFZGl0IGluc3RydWN0aW9ucyBmb3Ig YXJyYXlzIChvdGhlciB0aGFuIGFwcGVuZGluZyB0bywgb3IgcmVwbGFjaW5nDQogICB0aGUgd2hv bGUgYXJyYXkgd2l0aCBhIHNjYWxhciB2YWx1ZSkgYXJlIGFueSBvYmplY3RzIGxpa2U6DQoNCiAg ICBvICJkZWxldGUiOiAgWzxsaXN0IG9mIGluZGljZXM+XSBvciB0cnVlIChpZiBwYXRoIG5hbWVz IGFuIGFycmF5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWxlbWVu dCkNCg0KICAgIG8gImFkZCI6ICAgICBbPGxpc3Qgb2YgPHZhbHVlPnMgdG8gYXBwZW5kXQ0KDQog ICAgbyAiaW5zZXJ0IjogIFs8bGlzdCBvZiBbPGluZGV4PiwgPHZhbHVlPl0gcGFpcnM+XQ0KICAg IG8gInNldCI6ICAgICBbPGxpc3Qgb2YgWzxpbmRleD4sIDx2YWx1ZT5dIHBhaXJzPl0NCiAgICBv ICJwcmVwZW5kIjogWzxsaXN0IG9mIDx2YWx1ZT5zIHRvIHByZXBlbmRdDQogICAgbyAiYWRkIjog ICAgIFs8bGlzdCBvZiA8dmFsdWU+cyB0byBhcHBlbmRdDQogICAgbyAibmV3IjogICAgIFs8bmV3 IGxpc3Qgb2YgdmFsdWVzIHRvIHJlcGxhY2Ugb2xkIG9uZXM+XQ0KDQogICBObyBtYWdpYyBVUk4g bmFtZSBpcyBuZWVkZWQgaW4gdGhpcyBjYXNlLg0KDQogLSBUbyBhZGQgYW4gb2JqZWN0DQoNCiAt IEVkaXQgaW5zdHJ1Y3Rpb25zIGZvciBvYmplY3RzIChvdGhlciB0aGFuIHJlcGxhY2VtZW50IHdp dGggYSBzY2FsYXINCiAgIHZhbHVlKSBhcmUgb2JqZWN0cyB3aXRoIG5hbWUvdmFsdWUgcGFpcnMg bGlrZToNCg0KICAgIG8gImRlbGV0ZSI6IFs8bGlzdCBvZiBuYW1lIHN0cmluZ3M+XQ0KICAgIG8g Im1lcmdlIjogIFs8b2JqZWN0IHdob3NlIG5hbWVkIHZhbHVlIHBhaXJzIHdpbGwgcmVwbGFjZSB0 aGUNCiAgICAgICAgICAgICAgICAgY29ycmVzcG9uZGluZyBvbmVzIG9mIHRoZSBvYmplY3QgYmVp bmcgZWRpdGVkPl0NCg0KICAgTm8gbWFnaWMgVVJOIG5hbWUgaXMgbmVlZGVkIGluIHRoaXMgY2Fz ZS4NCg0KVGhlIHRvdGFsaXR5IG9mIHRoZSBwYXRjaCwgdGhlbiwgaXMgYW4gYXJyYXkgb2YNClsg PHBhdGg+LCA8aW5zdHJ1Y3Rpb24+IF0gZWxlbWVudHMuDQoNCkFueSBnaXZlbiBwYXRoIGNvdWxk IGJlIHJlZmVyZW5jZWQgbXVsdGlwbGUgdGltZXMgaW4gb25lIHBhdGNoLg0KDQpQcm9wb3NhbCAj MiBpcyBwcmV0dHkgc2VsZi1leHBsYW5hdG9yeS4gIEV4YW1wbGVzIGxlZnQgYXMgYW4gZXhlcmNp c2UNCmZvciB0aGUgcmVhZGVyLg0KDQpOaWNvDQotLSANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCmpzb24gbWFpbGluZyBsaXN0DQpqc29uQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCg== From nobody Wed Mar 19 17:42:32 2014 Return-Path: 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 430631A0835 for ; Wed, 19 Mar 2014 17:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793] autolearn=no 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 gOekNDq4D7_Q for ; Wed, 19 Mar 2014 17:42:29 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (unknown [69.163.253.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5899D1A0827 for ; Wed, 19 Mar 2014 17:42:29 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id AD9F040122422 for ; Wed, 19 Mar 2014 17:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Jq59DQ53l0b+Ch97DksDwdMxYkI=; b=NT0nayssxdf YdSoppTBZSKapZmG/1dcqD5o0JsqkAZ7hlSExgHWYSmoOHOyubKE9S6bgWLnoPDT ldiOoB046hYzV+PQOD433KgFrH3cjk2YAIXQ/4Cis+3cm52Xgnqovod2cD58s9fk +Hez18DR6xCYzz2HGO6kR54O3kyrbeF0= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 5D9B8400F8A2A for ; Wed, 19 Mar 2014 17:42:20 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so73180wes.27 for ; Wed, 19 Mar 2014 17:42:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X6iyD1cEsDfbijk75je1gDK/iFBGgpT/+Chb8BKxlUw=; b=b23ehlAaGdR0czKCJzJlyvaUld7oBhAZxGQZ+451U/h3drYj8ygvX9ObzJZIdB0cPf L02DQPpSd5WKsoptGqBkw7StwllVBbH5mzfrTy17bIvAk2BEZONTU2UbhkfcSjk7Z2kv W89Lwe9ZKBKquSDfQCaIwKDZ+gzw9aGjS8vObhEzkTJUFRsBk/t5GmMligsMA7Sb89cF ru4jCfbVSzMx7/I2zS9Wg4Eiy54yj8Dmd40zlAcFBIR56qqtCoOdVUg6it+PAyf+ZA1d MHiwdl7wywDyRX84oGsIuI82W+lAl/4RxAlGZevw3ybU7k4irCqgRswTJFVGLq8/hhgD XfFQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr21781663wiw.39.1395276139379; Wed, 19 Mar 2014 17:42:19 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 17:42:19 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115406DAAF6@WSMSG3153V.srv.dir.telstra.com> References: <20140319234549.GA3471@localhost> <255B9BB34FB7D647A506DC292726F6E115406DAAF6@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 19 Mar 2014 19:42:19 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/TilVskwe1UJHZrR4pfuO8piZR-c Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:42:30 -0000 On Wed, Mar 19, 2014 at 7:35 PM, Manger, James wrote: > RFC 6902 "JavaScript Object Notation (JSON) Patch" looks quite close to p= roposal 2. > Media type: application/json-patch+json > Operations: add, remove, replace, move, copy, test Perfect. Now I don't have to edit any I-Ds for this. > draft-ietf-appsawg-json-merge-patch "JSON Merge Patch" is a simpler subse= t of proposal 1. It is designed to work well with JSON objects, and objects= nested in objects etc. Its main limitation (compared to proposal 1) is tha= t it doesn't support insert/replace for individual array elements. Right. Why not just drop draft-ietf-appsawg-json-merge-patch? > Adding a "merge" operation to RFC 6902 would be another way to get the be= st of both these approaches. Maybe, but I don't need it. Thanks for the pointer to RFC6902! Nico -- From nobody Wed Mar 19 17:55:17 2014 Return-Path: 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 5FB401A0864 for ; Wed, 19 Mar 2014 17:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no 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 MZU2sYbkoT8s for ; Wed, 19 Mar 2014 17:55:15 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id CA94E1A085D for ; Wed, 19 Mar 2014 17:55:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,690,1389704400"; d="scan'208";a="193334126" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 20 Mar 2014 11:55:03 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7382"; a="208412708" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 20 Mar 2014 11:55:03 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 20 Mar 2014 11:55:03 +1100 From: "Manger, James" To: Nico Williams Date: Thu, 20 Mar 2014 11:55:02 +1100 Thread-Topic: [Json] JSON merge alternatives Thread-Index: Ac9D1Udhj4YB2WtfRceojJoCuRIiDAAAPy5Q Message-ID: <255B9BB34FB7D647A506DC292726F6E115406DABA3@WSMSG3153V.srv.dir.telstra.com> References: <20140319234549.GA3471@localhost> <255B9BB34FB7D647A506DC292726F6E115406DAAF6@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/qAZO1YhkJ4vXvVKBdjYgaViZdgE Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 00:55:16 -0000 Pj4gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tbWVyZ2UtcGF0Y2ggIkpTT04gTWVyZ2UgUGF0Y2gi IGlzIGEgc2ltcGxlciBzdWJzZXQgb2YgcHJvcG9zYWwgMS4gSXQgaXMgZGVzaWduZWQgdG8gd29y ayB3ZWxsIHdpdGggSlNPTiBvYmplY3RzLCBhbmQgb2JqZWN0cyBuZXN0ZWQgaW4gb2JqZWN0cyBl dGMuIEl0cyBtYWluIGxpbWl0YXRpb24gKGNvbXBhcmVkIHRvIHByb3Bvc2FsIDEpIGlzIHRoYXQg aXQgZG9lc24ndCBzdXBwb3J0IGluc2VydC9yZXBsYWNlIGZvciBpbmRpdmlkdWFsIGFycmF5IGVs ZW1lbnRzLg0KDQo+IFJpZ2h0LiAgV2h5IG5vdCBqdXN0IGRyb3AgZHJhZnQtaWV0Zi1hcHBzYXdn LWpzb24tbWVyZ2UtcGF0Y2g/DQoNCkJlY2F1c2UgaXQgaXMgY3JlYXRlcyBpbnR1aXRpdmUgYW5k IHN1Y2NpbmN0IHBhdGNoZXMgZm9yIG1hbnkgbW9zdCBjb21tb24gY2FzZXMuDQoNCi0tDQpKYW1l cyBNYW5nZXINCg== From nobody Wed Mar 19 19:35:07 2014 Return-Path: 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 63D461A0648 for ; Wed, 19 Mar 2014 19:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 k5CwQV6gAsBc for ; Wed, 19 Mar 2014 19:35:03 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFB1A063F for ; Wed, 19 Mar 2014 19:35:03 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (unknown [69.163.253.160]) by hapkido.dreamhost.com (Postfix) with ESMTP id 3B78883FD8 for ; Wed, 19 Mar 2014 19:34:26 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D01E021DE6A for ; Wed, 19 Mar 2014 19:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YYZSIHRRPOCuhB94vjIX fycUxqI=; b=jMpJ4NpZv09je4jvd2kZ9EPj1jOAWytNla26PoBzzaui/p2GBeWS HJPphxm5ifjwp8nefqadYyT4sbCLQN0NfDhyoIVXulrGrfMIwblPv9MDu2Kp25HT 0fNmeYkW1ojhr/Bv6gvLS4LKtuWhFo42KGazrpnKS82FFF3eRk0oQtw= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 6D38821DE65 for ; Wed, 19 Mar 2014 19:34:25 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so5546718wib.2 for ; Wed, 19 Mar 2014 19:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7iH51efUP5x9D/PPoJlUIbPN+hbFhZL2/EPOosZufqw=; b=jvQprCP9d8FwYlFjT1lyjQdRULo6xfVsETWrd8F9uLsAd7a1TDMKrk544NgXodSPpF 9yScvEjuMTb9rH9D0A7QmvvgvwlwniBlOBTJcP/vWlLb1WtdWH884j6YXzMOncA5j2fk zXWogedKzAbn0tv97cD1ANep0g+wytNbsHmSIDWtUMU/pAJiVhAI9HPiDhVRvY0NdvEE vcSZvX7cM3jBX6RfyEN6c6ESi/LABfRXF45HKYx15cgZPyWsDkKmQelkmnjnlxMRtQNu 28E/SbpPQXH/g88hDL+SLR5CeH+qtGJa0sIUvccEDtSAFhG/OKI/ResJ1qaGNYi8TE8S SQpw== MIME-Version: 1.0 X-Received: by 10.194.157.41 with SMTP id wj9mr32041001wjb.34.1395282864109; Wed, 19 Mar 2014 19:34:24 -0700 (PDT) Received: by 10.216.199.6 with HTTP; Wed, 19 Mar 2014 19:34:24 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115406DABA3@WSMSG3153V.srv.dir.telstra.com> References: <20140319234549.GA3471@localhost> <255B9BB34FB7D647A506DC292726F6E115406DAAF6@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115406DABA3@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 19 Mar 2014 21:34:24 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Yhr5JgkkfF3waSSZoR7OCp2bmKw Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 02:35:05 -0000 On Wed, Mar 19, 2014 at 7:55 PM, Manger, James wrote: >> Right. Why not just drop draft-ietf-appsawg-json-merge-patch? > > Because it is creates intuitive and succinct patches for many most common cases. Well, sure, but it should be possible to take an original and a patch written in one style and convert to the other style locally, then PATCH using the one style. Having just one JSON PATCH schema is more likely to interop than having two. Of course, the alternative style might still be useful even if it were only useful locally. I'll leave it to someone else, methinks, at least for now. Nico -- From nobody Thu Mar 20 00:23:50 2014 Return-Path: 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 77D1F1A03DF for ; Thu, 20 Mar 2014 00:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ejAR8y9Q9DWS for ; Thu, 20 Mar 2014 00:23:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 09CF51A0069 for ; Thu, 20 Mar 2014 00:23:48 -0700 (PDT) Received: from [192.168.2.117] ([84.187.48.148]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M1iGk-1XEWNj3uOo-00tm0u; Thu, 20 Mar 2014 08:23:34 +0100 Message-ID: <532A9772.7050508@gmx.de> Date: Thu, 20 Mar 2014 08:23:30 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nico Williams , Mark Nottingham References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yFNhXsUMh4caOUl6Ne8gZoAn+hdJhOOTG7qm50F4UDGIP7Hjcy+ V2RdGMTfMRX696DJsKk3r1I9Da3UNTISNnkpCEbX57YyBLVlRZ+ViLpvOrzWjyNDDZmzttL W1DfgjKQVOCOlB2WRjj89SDBPcynmVTo9ZCh9HpMbQKY5oxR1wjFG7H/A8hq7q10FUeePxB iJKg6lzllSAvxh0P/bMvw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/RdEmH6yaRbDQ7QclgHn9k6m0MEU Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:23:49 -0000 On 2014-03-20 01:05, Nico Williams wrote: > I was responding to the question about whether the JSON WG should > re-charter to include JSON merge as a work item. > > I suppose perhaps you're saying that JSON merge is an Apps area work > item and should stay in Apps. But I can't quite tell if that's what > you meant. > > Nico For the record: I believe this work is needed, but that it should happen over here. This WG has the necessary JSON expertise. Best regards, Julian From nobody Thu Mar 20 00:32:15 2014 Return-Path: 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 C1E841A03DF for ; Thu, 20 Mar 2014 00:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 7AJbW_UALZ9I for ; Thu, 20 Mar 2014 00:32:12 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 485BF1A0069 for ; Thu, 20 Mar 2014 00:32:12 -0700 (PDT) Received: from newyork.local.box ([80.187.107.94]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0McFcd-1Wj2JS3lhv-00JYiw; Thu, 20 Mar 2014 08:32:02 +0100 Message-ID: <532A9970.9070606@drees.name> Date: Thu, 20 Mar 2014 08:32:00 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Julian Reschke , Nico Williams , Mark Nottingham References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> <532A9772.7050508@gmx.de> In-Reply-To: <532A9772.7050508@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ImSDYR4MW+hPg1ycD+QLq3h9AoTdI0A9zRjaIoCuUBDi3MQEWUx DX898ZCvNzV5kDcdqBuPZ/vtmv8a9/LYXWcIAhBisoS8Gi6FXWAh2EH6YMTNT/l1OmThHVA lJKILdaJNya1j+ZZy1L+BGXDyVWVJlxy1mxoyLgZUoYUeW+EvWto/giDspbW2i4DvaoiXBK uV3KXx6B+DYQuWw9/HxUw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/R4p_btcs46vyZJs3yiZc3gu1i0o Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:32:14 -0000 On 2014-03-20 08:23 +01:00, Julian Reschke wrote: > On 2014-03-20 01:05, Nico Williams wrote: >> I was responding to the question about whether the JSON WG should >> re-charter to include JSON merge as a work item. >> >> I suppose perhaps you're saying that JSON merge is an Apps area work >> item and should stay in Apps. But I can't quite tell if that's what >> you meant. >> >> Nico > > For the record: I believe this work is needed, but that it should happen > over here. This WG has the necessary JSON expertise. ... +1 for necessary format expertise when fiddling with format differencing All the best, Stefan. From nobody Thu Mar 20 01:48:49 2014 Return-Path: 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 8CDDB1A08B3 for ; Thu, 20 Mar 2014 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 4d1ohD7gCbSv for ; Thu, 20 Mar 2014 01:48:46 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9AF1A068A for ; Thu, 20 Mar 2014 01:48:46 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with SMTP id 9091332E4F0; Thu, 20 Mar 2014 17:48:36 +0900 (JST) Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2dcb_0fc6_6cf4517e_b00c_11e3_9978_001e6722eec2; Thu, 20 Mar 2014 17:48:36 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CC3E5C042B; Thu, 20 Mar 2014 17:48:35 +0900 (JST) Resent-From: "Martin J. =?UTF-8?B?RMODwrxyc3Q=?=" Resent-To: "Matt Miller (mamille2)" , IETF JSON WG , Paul Hoffman Resent-Date: Thu, 20 Mar 2014 17:48:28 +0900 Resent-Message-ID: <532AAB5C.4010707@it.aoyama.ac.jp> Resent-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 X-Mozilla-Keys: redirected Message-ID: <5327C518.4050705@it.aoyama.ac.jp> Date: Tue, 18 Mar 2014 13:01:28 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matt Miller , IETF JSON WG References: <53277484.70305@cisco.com> In-Reply-To: <53277484.70305@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/8nBxikDQB_aim5lxMEV3QbJpMe4 Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:48:48 -0000 Hello Matt, others, On 2014/03/18 07:17, Matt Miller wrote: > Greetings again. We earlier asked a couple of questions to gauge what > the new proposed WG charter ought to contain. That feedback has been > valuable, but has drilled into implementation specifics before a new > charter was actually agreed on! We have been chastised by our AD about > this, and for good reason. We think we already have enough input from > the London meeting and the list over the past few days to make the > following proposal for a new charter: > > ========================== > > Javascript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from the > ECMAScript Programming Language Standard, and was later published in RFC > 7159. "was later published" sounds as if it wasn't published before RFC 7159. I suggest to change this to "is published", which avoids such implications. > The WG will work on an restricted profile of JSON designed to maximize > interoperability. The work will start from draft-bray-i-json-01. Okay. > The WG will work on a format for a streamable sequence of JSON texts. > The work will start from draft-williams-json-text-sequence-00. There have been various discussions about such an idea, and various details of it, on the WG list. However, as far as I'm aware, the question of whether this should be part of the WG's work wasn't brought up, and has not been discussed. I'm therefore quite surprised to see this here, and request that it be retracted and if necessary discussed separately before being included in a charter proposal. As to substance, I strongly oppose the addition of this work item to the WG charter. In my understanding, the need for such a format is marginal at best (*), and putting it on the WG charter would tie up significant resources that can be better used elsewhere. Standardizing such a format would also cause needless confusion in the JSON ecosystem. (#) Regards, Martin. (*) In particular in open exchange on the Internet. (#) I can already hear questions and discussions such as "Should we use an array or a sequence here?" and "What about sequences inside arrays?" and so on. > Milestones: > > IETF Last Call for restricted profile: June 2014 > IETF Last Call for text sequences: June 2014 > > ========================== > > We note that there is no noticeable consensus around adding work on a > single nomenclature / schema. There appears to be some interest in the > WG coming up with some wording that says "the WG is not going to pick > one yet, and we think that ABNF is certainly the wrong one". If someone > wants to write up a draft with this kind of wording, we don't need to > have it as a charter item: it could just be a message from the WG to the > IESG, and they can ask us more if they want. > > > --Paul Hoffman and Matt Miller > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Mar 20 01:49:47 2014 Return-Path: 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 F2C921A08B7 for ; Thu, 20 Mar 2014 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no 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 3IJmMWbbNLEf for ; Thu, 20 Mar 2014 01:49:44 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAA1A08B3 for ; Thu, 20 Mar 2014 01:49:44 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with SMTP id 7CA5332E567 for ; Thu, 20 Mar 2014 17:49:35 +0900 (JST) Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2dc7_0e04_9019aaf0_b00c_11e3_a04d_001e6722eec2; Thu, 20 Mar 2014 17:49:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C7420C042B for ; Thu, 20 Mar 2014 17:49:34 +0900 (JST) Message-ID: <532AAB97.5040404@it.aoyama.ac.jp> Date: Thu, 20 Mar 2014 17:49:27 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "json@ietf.org" References: <532A4493.3030804@it.aoyama.ac.jp> In-Reply-To: <532A4493.3030804@it.aoyama.ac.jp> X-Forwarded-Message-Id: <532A4493.3030804@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/C_NF-uGl3TIHBnQl0gXWCwA208U Subject: [Json] Fwd: Re: [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:49:46 -0000 Forwarded because this didn't go to the JSON list. Martin. -------- Original Message -------- Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) Date: Thu, 20 Mar 2014 10:29:55 +0900 From: "Martin J. D=C3=BCrst" Organization: Aoyama Gakuin University I think it's better as rejected, otherwise, there's a higher chance of a similar one popping up in the future. Regards, Martin. On 2014/03/20 05:23, Barry Leiba wrote: > I'd sat this shouldn't be marked "Rejected", but should instead be remo= ved > from the errata system. What does the RFC Editor think? > > Barry > > On Wednesday, March 19, 2014, Paul Hoffman wrot= e: > >> Please reject this errata report. There was a conscious decision made = by >> the RFC Editor to issue the new RFC; the fact that the reporter doesn'= t >> like that decision does not warrant an errata. >> >> --Paul Hoffman, JSON WG co-chair > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Mar 20 08:07:17 2014 Return-Path: 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 85B001A08C7 for ; Thu, 20 Mar 2014 08:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 sUPfr349xcfI for ; Thu, 20 Mar 2014 08:07:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 39EED1A08B3 for ; Thu, 20 Mar 2014 08:07:06 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2KF6qh1073031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Mar 2014 08:06:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Thu, 20 Mar 2014 08:06:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140319234549.GA3471@localhost> <8489D083-3871-4516-8FD3-32749645DBB4@mnot.net> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/LgOqpSVKZnWyq0PeAiGofflwOAc Cc: "json@ietf.org" Subject: Re: [Json] JSON merge alternatives X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:07:07 -0000 On Mar 19, 2014, at 5:01 PM, Nico Williams = wrote: > On Wed, Mar 19, 2014 at 6:56 PM, Mark Nottingham = wrote: >> = http://mailarchive.ietf.org/arch/msg/apps-discuss/mvUVvUt41tFTrPSOCfv7sfbl= TUM >=20 > I.e., draft-ietf-appsawg-json-merge-patch, which has the same problems > mentioned recently on this list (e.g., using null to mean delete). Then those problems should be discussed more. There was at least one = thread about "null to delete", but I don't think it got enough focus. As others have said: the document is already in another WG, there is no = need to bring it to this WG. If you want to speak about the document, = definitely join the AppsAWG mailing list at = . Also, if you want = to volunteer to edit the document, saying so there would be great. Do note that that WG already has lots of relevant readers: people who = write applications protocols that use JSON. Having both them and JSON = partisans in the discussion would be a good thing. Matt and I are not looking at empire-building and see no reason to take = this document from an active WG just to put it here. One of the great = things about the IETF is that many people participate on (or at least = lazily follow) many mailing lists. --Paul Hoffman= From nobody Thu Mar 20 08:16:07 2014 Return-Path: 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 56BA31A03FD for ; Thu, 20 Mar 2014 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.778 X-Spam-Level: ** X-Spam-Status: No, score=2.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no 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 Um3QTXxuleZX for ; Thu, 20 Mar 2014 08:16:03 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (unknown [69.163.253.184]) by ietfa.amsl.com (Postfix) with ESMTP id D10DE1A069C for ; Thu, 20 Mar 2014 08:15:59 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id F347A318064; Thu, 20 Mar 2014 08:15:50 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=DYWt/VqCa56+STad0yNRyq7peGs=; b=Nu3DryOm2n4 zsE9JaSFFegvYE9Onni5LxjpvxGEfSatxkgLF2T2taMnbDtjPpUXSanzrFfQauiH bNIuDwmaeNOJrgtj2Sk3Ip4ydZ0ZlDwLdL3tf/HGwbzw1T6hhSvEFLOm8Es5F9wu aSZu+HmSrv59b4zP8WMdgqRGoEyt+AMQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 97701318057; Thu, 20 Mar 2014 08:15:50 -0700 (PDT) Date: Thu, 20 Mar 2014 10:15:47 -0500 From: Nico Williams To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20140320151545.GD3471@localhost> References: <53277484.70305@cisco.com> <5327C518.4050705@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5327C518.4050705@it.aoyama.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/kum3SIYeaAtZGvVXJTqvXdz9Ee0 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Proposed Wording for New WG Charter X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 15:16:05 -0000 On Tue, Mar 18, 2014 at 01:01:28PM +0900, "Martin J. D=FCrst" wrote: > >The WG will work on a format for a streamable sequence of JSON texts. > >The work will start from draft-williams-json-text-sequence-00. >=20 > There have been various discussions about such an idea, and various > details of it, on the WG list. However, as far as I'm aware, the > question of whether this should be part of the WG's work wasn't > brought up, and has not been discussed. I'm therefore quite > surprised to see this here, and request that it be retracted and if > necessary discussed separately before being included in a charter > proposal. I'm somewhat surprised as well. I do think the call by the chairs that there was consensus for it is plausible, but it's true that it was never stated that it was being considered as a work item, and that might actually change the consensus. > As to substance, I strongly oppose the addition of this work item to > the WG charter. In my understanding, the need for such a format is > marginal at best (*), and putting it on the WG charter would tie up > significant resources that can be better used elsewhere. > Standardizing such a format would also cause needless confusion in > the JSON ecosystem. (#) >=20 > (*) In particular in open exchange on the Internet. That may be. I don't have apps to point to that use this now over -say- HTTP. I do have apps that use JSON sequences internally and as file formats. I would like to be able to use JSON sequences over HTTP, but wishing ain't getting and for all I know it may never happen. OTOH, I think a number of people have agreed that JSON sequences have useful properties, so there appears to be enough interest. > (#) I can already hear questions and discussions such as "Should we > use an array or a sequence here?" and "What about sequences inside > arrays?" and so on. Re (#): Sequences are of JSON texts, and JSON texts are well-defined enough that it's clear that sequences cannot appear in JSON texts. Full stop. The idea is twofold: to obtain a happy middle between streaming and non-streaming parsing of sequences (arrays if you prefer) of values, and to not require a closing array/sequence token (']') because it may never arrive (e.g., in the case of a logfile). In particular, the ability to construct a streaming JSON sequence parsers out of off-the-shelf non-streaming (but incremental[*]) JSON text parsers is quite convenient given that a) all-streaming-all-the- time text parsing is inconvenient, b) non-streaming parsers abound. Nico [*] Non-streaming parsers that require a fully-formed text be provided as input (e.g., json.loads()), cannot be efficiently used to parse sequences without the encoder having made it easier for the sequence parser to identify the ends of the texts. From nobody Thu Mar 20 14:24:52 2014 Return-Path: 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 4A4861A076D for ; Thu, 20 Mar 2014 14:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 NwI8LZPNKMKq for ; Thu, 20 Mar 2014 14:24:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6B1A08FF for ; Thu, 20 Mar 2014 14:24:50 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2KLO45m086115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Mar 2014 14:24:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Mar 2014 14:24:40 -0700 References: To: IETF JSON WG Message-Id: <05246316-6DEF-4597-89D2-1858F09B637A@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/GenhhQCGNtKxcxxRTJWxYjuk4mc Subject: [Json] Fwd: [89all] London Meeting Survey X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 21:24:51 -0000 If you were in London but didn't see this, please consider filling in = the survey. There are also questions for people who weren't in London = but participated remotely. The IAOC pays a lot of attention to the = results of these surveys. Begin forwarded message: > From: Ray Pelletier > Subject: [89all] London Meeting Survey > Date: March 20, 2014 at 1:58:49 PM PDT > To: <89all@ietf.org> >=20 > All; >=20 > This is a short and anonymous survey about your IETF meeting = experience generally and specifically your experience at IETF 89 in = London. It will be used to make improvements at future meetings where = needed (and possible). Feedback on the survey itself is welcome. >=20 > https://www.surveymonkey.com/s/XG5S9VC >=20 > Thanks for attending the meeting and your participation in this = survey. >=20 > Ray From nobody Fri Mar 21 15:28:37 2014 Return-Path: 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 86A6A1A08D0 for ; Fri, 21 Mar 2014 15:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DCz-A9zyedVZ for ; Fri, 21 Mar 2014 15:28:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DDB1A07E3 for ; Fri, 21 Mar 2014 15:28:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140321222833.3694.81522.idtracker@ietfa.amsl.com> Date: Fri, 21 Mar 2014 15:28:33 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/Jbisy4DjocRkGiHQiNTfj7yzQME Subject: [Json] Milestones changed for json WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 22:28:35 -0000 Changed milestone "Published JSON specification as RFC 7159", set state to active from review, accepting new milestone, set description to "Request publication of JSON specification". URL: http://datatracker.ietf.org/wg/json/charter/ From nobody Tue Mar 25 21:50:21 2014 Return-Path: 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 35B331A00C5 for ; Tue, 25 Mar 2014 21:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FbDF47l7sHZq for ; Tue, 25 Mar 2014 21:50:16 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E79401A00CB for ; Tue, 25 Mar 2014 21:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1395809414; x=1427345414; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wdsd8KCYD26M8wjMBn9XPlZyx8I7/K8sDfoBN0tlKL8=; b=rsTyRXlIkO1WdtRtPzqsgDiLiSFQpPfBAyhEx4BC/JNT/pofKcWozNog XFIk3PJm51k6Dtr1OYbb5dcaMShYE17JNq8xtqL3TAmqPeVU536ZAUwmi WxGrqXXIf7P4HYmCvKovBL6dSIFLqR0GI98iNa0Esnkabk7VLSGEQGlrc Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7388"; a="115603521" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 25 Mar 2014 21:50:13 -0700 X-IronPort-AV: E=Sophos;i="4.97,733,1389772800"; d="scan'208";a="615101404" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Mar 2014 21:50:10 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 21:50:06 -0700 Message-ID: <53325C7C.7070400@qti.qualcomm.com> Date: Tue, 25 Mar 2014 23:50:04 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <20140319192235.B26B67FC394@rfc-editor.org> <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> <532A4493.3030804@it.aoyama.ac.jp> In-Reply-To: <532A4493.3030804@it.aoyama.ac.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/json/4RguOoB20_8X4Orn3U3uk6aL02M Cc: Paul Hoffman , "json@ietf.org" , "naesten@gmail.com" , Tim Bray , "mamille2@cisco.com" , Barry Leiba , RFC Errata System Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 04:50:18 -0000 And if one does, we will similarly remove it. RFC Editor: Please remove erratum 3922. pr On 3/19/14 8:29 PM, "Martin J. Drst" wrote: > I think it's better as rejected, otherwise, there's a higher chance of > a similar one popping up in the future. > > Regards, Martin. > > On 2014/03/20 05:23, Barry Leiba wrote: >> I'd sat this shouldn't be marked "Rejected", but should instead be >> removed >> from the errata system. What does the RFC Editor think? >> >> Barry >> >> On Wednesday, March 19, 2014, Paul Hoffman >> wrote: >> >>> Please reject this errata report. There was a conscious decision >>> made by >>> the RFC Editor to issue the new RFC; the fact that the reporter doesn't >>> like that decision does not warrant an errata. >>> >>> --Paul Hoffman, JSON WG co-chair >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Mar 25 21:55:45 2014 Return-Path: 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 70FF11A00DA for ; Tue, 25 Mar 2014 21:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6LmBpX5ZIK0f for ; Tue, 25 Mar 2014 21:55:42 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3523F1A029B for ; Tue, 25 Mar 2014 21:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1395809677; x=1427345677; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dTTaKwiZaiEK+5IEQMhf26YoeH54CylSTGb93N62AWo=; b=CrE+i7+9hn8o8EpAypXCMmkYJiOeIctGxjuHVsq2KGm5XUSeHAY2HWED uvv2aAoO0M1BjbAycradfG7LWwJ6muHUqF4dgyY1WYYhCDiaWderhENJD Z0XAPFiNwJW5dHAG7MbURta2cOf0ik/IL5qjymU7M2UqTkuBXZfv0o1J1 s=; X-IronPort-AV: E=McAfee;i="5400,1158,7388"; a="24568609" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 25 Mar 2014 21:54:33 -0700 X-IronPort-AV: E=Sophos;i="4.97,733,1389772800"; d="scan'208";a="29033816" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Mar 2014 21:54:32 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 21:54:31 -0700 Message-ID: <53325D86.1000508@qti.qualcomm.com> Date: Tue, 25 Mar 2014 23:54:30 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Larry Masinter References: <20140307171244.B1B8D7FC392@rfc-editor.org> <20E56125-5F9D-412D-B79A-D5B450798292@vpnc.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/json/f2X5ecEHyw4npowV9BEYnjD6VLg Cc: Paul Hoffman , "json@ietf.org" , "vfaronov@gmail.com" , Tim Bray , "mamille2@cisco.com" , Barry Leiba Subject: Re: [Json] [Technical Errata Reported] RFC7159 (3915) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 04:55:43 -0000 On 3/13/14 4:31 PM, Larry Masinter wrote: >> The WG chairs request that you approve this errata. >> > > I think the errata would be more useful if it actually explained the \u2028, \u2029 exception, rather than leaving it in a potentially unstable reference > http://timelessrepo.com/json-isnt-a-javascript-subset > I'm not inclined to use the errata system to document this. I'll approve the erratum, and I'll leave it to i-json or otherwise to document the difference between JSON and JS if necessary. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Mar 26 10:46:44 2014 Return-Path: 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 6F4C71A01BB for ; Wed, 26 Mar 2014 10:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7yhp7ezJ1Ykk for ; Wed, 26 Mar 2014 10:37:19 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3C1A0142 for ; Wed, 26 Mar 2014 10:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 52B9A1E12A2; Wed, 26 Mar 2014 10:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWeU4fYLgVPN; Wed, 26 Mar 2014 10:37:02 -0700 (PDT) Received: from [192.168.1.5] (pool-68-238-162-118.washdc.fios.verizon.net [68.238.162.118]) by c8a.amsl.com (Postfix) with ESMTPSA id 426801DF11E; Wed, 26 Mar 2014 10:37:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Alice Russo In-Reply-To: <53325C7C.7070400@qti.qualcomm.com> Date: Wed, 26 Mar 2014 13:37:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96D41294-3276-488E-85E7-98697B0FC093@amsl.com> References: <20140319192235.B26B67FC394@rfc-editor.org> <0B49E8C8-3E47-48D8-B45A-D4948DCCE002@vpnc.org> <532A4493.3030804@it.aoyama.ac.jp> <53325C7C.7070400@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/json/G7otQyoXCuF2FDS5IGvqSAv-N-I X-Mailman-Approved-At: Wed, 26 Mar 2014 10:46:42 -0700 Cc: Paul Hoffman , json@ietf.org, naesten@gmail.com, Tim Bray , mamille2@cisco.com, =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Barry Leiba , RFC Editor Subject: Re: [Json] [Editorial Errata Reported] RFC7159 (3922) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 17:37:21 -0000 Pete, It's been removed. To answer Barry's question, we're in favor of removing it. Thank you. RFC Editor/ar On Mar 26, 2014, at 12:50 AM, Pete Resnick wrote: > And if one does, we will similarly remove it. >=20 > RFC Editor: Please remove erratum 3922. >=20 > pr >=20 > On 3/19/14 8:29 PM, "Martin J. D=FCrst" wrote: >> I think it's better as rejected, otherwise, there's a higher chance = of a similar one popping up in the future. >>=20 >> Regards, Martin. >>=20 >> On 2014/03/20 05:23, Barry Leiba wrote: >>> I'd sat this shouldn't be marked "Rejected", but should instead be = removed >>> from the errata system. What does the RFC Editor think? >>>=20 >>> Barry >>>=20 >>> On Wednesday, March 19, 2014, Paul Hoffman = wrote: >>>=20 >>>> Please reject this errata report. There was a conscious decision = made by >>>> the RFC Editor to issue the new RFC; the fact that the reporter = doesn't >>>> like that decision does not warrant an errata. >>>>=20 >>>> --Paul Hoffman, JSON WG co-chair >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>>=20 >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 From nobody Wed Mar 26 23:05:41 2014 Return-Path: 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 CA9CF1A0476 for ; Wed, 26 Mar 2014 23:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ljMS9NBP6uvC for ; Wed, 26 Mar 2014 23:05:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFB91A0468 for ; Wed, 26 Mar 2014 23:05:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140327060537.6193.47892.idtracker@ietfa.amsl.com> Date: Wed, 26 Mar 2014 23:05:37 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/Q_209eKT-7Sf8E-itltP54kyMjE Subject: [Json] State changed: charter-ietf-json-01-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 06:05:39 -0000 State changed to Informal IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-json/ From nobody Thu Mar 27 07:44:16 2014 Return-Path: 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 E28F71A06C1 for ; Thu, 27 Mar 2014 07:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 f1buSrantsLX for ; Thu, 27 Mar 2014 07:44:10 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id E571B1A06B2 for ; Thu, 27 Mar 2014 07:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1395931448; x=1427467448; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qt5GmaeRPbOZDvOVm+7FTF00HfR3ZyhR3JO3C7Zq8Tc=; b=BfLlqn9MaGrNv5jI5OyWfXPPSv6NBJuAjbubAZSH5Hm/IwUbqfcj9l2+ uaWKiEqfimy78qgY07GLxFNYqFCGKfX32HJPBSsoodGeAdrgqWnSa/wv7 xyGj+uznNjjoIAdk3eF6iozCAtRUebHFwbZYnxhZFaqYLJW0jSvaSz+1K A=; X-IronPort-AV: E=McAfee;i="5400,1158,7389"; a="61213195" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 27 Mar 2014 07:44:08 -0700 X-IronPort-AV: E=Sophos;i="4.97,743,1389772800"; d="scan'208";a="29121642" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Mar 2014 07:44:07 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc11.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 07:44:07 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 07:44:07 -0700 Message-ID: <53343935.2010404@qti.qualcomm.com> Date: Thu, 27 Mar 2014 09:44:05 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20140327060537.6193.47892.idtracker@ietfa.amsl.com> In-Reply-To: <20140327060537.6193.47892.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/json/ezExgxFgXf9Vf6oat_GR3QFPRwQ Subject: Re: [Json] State changed: charter-ietf-json-01-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:44:14 -0000 The chairs remind me that I should give you a status update, since the messages from the datatracker tool are not entirely crystal clear: On 3/27/14 1:05 AM, IETF Secretariat wrote: > State changed to Informal IESG review. > > URL: http://datatracker.ietf.org/doc/charter-ietf-json/ > In the middle of the night, while taking a break from a record-breaking number of documents on today's telechat, I finally got the new charter text that the chairs sent me put into the tool. It's currently in the "Informal" review state, which means that I am (going to be) discussing it folks in the IESG and sanity checking that we're going in the right direction. Then I will put it on the next telechat (as I said, this week's would have been an absurd one to add an extra to) and hopefully have the re-charter approved. I'll keep you posted. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From stefan.reich.maker.of.eye@googlemail.com Sat Mar 29 10:41:09 2014 Return-Path: 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 D83F61A06B4 for ; Sat, 29 Mar 2014 10:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no 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 FYdSgpbaqzPN for ; Sat, 29 Mar 2014 10:41:07 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4F1A06AF for ; Sat, 29 Mar 2014 10:41:07 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so1767502wib.8 for ; Sat, 29 Mar 2014 10:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QL/imefvCBbZDp+pART4DXV5M9O8iyBoxN1cpWMOrEA=; b=DLKod+j6oUAjiETyW3nLO6iaLT+y/gz33OA5KfDbNpqJLLbcFEk41FSJ5XusfS/yb7 LTp5gDRAulttQArQRdV+S2fhDU+wTRbKDvp/uMCNFFZZa7tNM1lanF2kEmWSd/f+7Hzm gvqRTmJR/EjLXTy9ECB66/rt44G6y9/G/VV3QuM/NtZTTnw7eN/fXWeKyEYINz8dR+cR oyXEO5UAfqnvF6RdiZjOaWs8PwAPgC9B0sfDjq9Fx8NAiPPYMFZBHL7jdj21KDzQYUfm t/4ok5K0uZITH6r7yui75rhEtgiJXu90XLOz5XYvbJO5YaogiZ/xeXy9sqw570mX2pjZ PgXQ== MIME-Version: 1.0 X-Received: by 10.180.205.204 with SMTP id li12mr2681983wic.34.1396114864287; Sat, 29 Mar 2014 10:41:04 -0700 (PDT) Received: by 10.180.36.103 with HTTP; Sat, 29 Mar 2014 10:41:04 -0700 (PDT) Date: Sat, 29 Mar 2014 18:41:04 +0100 Message-ID: From: Stefan Reich To: json@ietf.org Content-Type: multipart/alternative; boundary=001a11c37bea8d3a2504f5c25265 Archived-At: http://mailarchive.ietf.org/arch/msg/json/BMMXIjYy59Fak9bsyN2fquvfFmI Subject: [Json] ANN: JSONMinify v1 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 17:41:47 -0000 --001a11c37bea8d3a2504f5c25265 Content-Type: text/plain; charset=ISO-8859-1 Hello "IETF"! I think you might be an evil organisation. But I am not afraid... not anymore! :-)) Now to everyone, and to the post: There is a new tool, and a new campaign. The campaign is called JSON+C, and the tool is JSONMinify. (The bigger universe behind that is called TinyBrain.) JSONMinify is a Java library *THAT WORKS*(see below) that removes whitespace and comments from JSON/ *JSON+C* documents (JSON+C = JSON with comments). The implementation has *no overhead and near-perfect performance*. JSONMinify *makes it possible to use JSON+C everywhere* regular JSON is expected--with a very cheap conversion. Actually, prepending JSONMinify will even SPEED UP your JSON parser (if it's a slow one). Usage is quite simple: String minified = prophecy.common.JSONMinify.minify(originalJSONString); Note: We'll collect implementations in any other language too - just submit if you have one. Note note: I wrote JSONMinify because the other minifiers (notably, the one at bigaqua.org which still turns out high at Google), sadly, JUST DON'T WORK. Link: http://jsonminify.tinybrain.de Looking for feedback... cheers and have a great summer!! :o)) Stefan --001a11c37bea8d3a2504f5c25265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello "IETF"!

I thin= k you might be an evil organisation. But I am not afraid... not anymore! :-= ))

Now to everyone, and to the post: There is a new tool, and = a new campaign. The campaign is called JSON+C, and the tool is JSONMinify. = (The bigger universe behind that is called TinyBrain.)

JSONMinify is a Java library THAT WORKS (see below) t= hat removes whitespace and comments from JSON/JSON+C documents (JSON= +C =3D JSON with comments). The implementation has no overhead and near-= perfect performance.

JSONMinify makes it possible to use JSON+C everywhere regular=20 JSON is expected—with a very cheap conversion. Actually, prepending= =20 JSONMinify will even SPEED UP your JSON parser (if it's a slow one).

Usage is quite simple:

    String minified =3D prophecy.common.JSONMinify.minify= (originalJSONString);

Note: We'll collect implementations in any other language too - just= submit if you have one.

Note note: I wrote JSONMinify because the other minifiers (notably, the one at big= aqua.org which still turns out high at Google), sadly, JUST DON'T W= ORK.

Link: http://jsonminify.tinybrai= n.de

Looking for feedback... cheers and have a great summer!! :o= ))
Stefan
--001a11c37bea8d3a2504f5c25265-- From nobody Sat Mar 29 10:46:03 2014 Return-Path: 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 D4F601A06B4 for ; Sat, 29 Mar 2014 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4zizA-yCNpy3 for ; Sat, 29 Mar 2014 10:46:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B38AC1A06AF for ; Sat, 29 Mar 2014 10:46:00 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so3442611wes.36 for ; Sat, 29 Mar 2014 10:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PgMKqZjIGe/fgCiYpVTali+OH3RPYLDhidFjhw7Cupk=; b=jQ1XfKprFYPwOlAR+UMfyGtynVqZtzNSeIFsRu3PtQ3DZpDahaPZCKdanjWsEUoNPi C0YxxX6/n7lNxPGwWN+GR2gk+SigZbQFb4qSZKLlaypNYWrhJ6rtkzFvYe4CEc52EN7l mGtvzOtd+yP+aFrEkgIdj8fkVWjSysUiGfnvyZhdF1CwMn8xuyhAOG9ljC35tyNcmm6E TOWHzrpnbt5JnliO65ZJsG4oqXMWaaW5BHrSD6yYE93BFgYJv5WySDoJY/ZnGO5nQ/Ho 0gjFt4uZVNLBrgWKfkU/Hn/et8aedY7eBM/akhnUMo0ZbdnSI4vCekQfcO75ZDh2vJB5 bO4w== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr2648867wic.17.1396115157712; Sat, 29 Mar 2014 10:45:57 -0700 (PDT) Received: by 10.180.36.103 with HTTP; Sat, 29 Mar 2014 10:45:57 -0700 (PDT) Date: Sat, 29 Mar 2014 18:45:57 +0100 Message-ID: From: Stefan Reich To: json@ietf.org Content-Type: multipart/alternative; boundary=001a11c34a620a866e04f5c264b0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/z98YcmERIS6-3PgW_pcICoUBO8Y Subject: [Json] Follow-up question: Can one join the IETF? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 17:46:02 -0000 --001a11c34a620a866e04f5c264b0 Content-Type: text/plain; charset=ISO-8859-1 Subject says it all. :-) Please reply! Cheers, Stefan TinyBrain.de (Hamburg) --001a11c34a620a866e04f5c264b0 Content-Type: text/html; charset=ISO-8859-1
Subject says it all. :-) Please reply!

Cheers,
Stefan
TinyBrain.de (Hamburg)
--001a11c34a620a866e04f5c264b0-- From nobody Sat Mar 29 11:48:47 2014 Return-Path: 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 E64BB1A07CA for ; Sat, 29 Mar 2014 11:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no 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 lJALRq_xYUsF for ; Sat, 29 Mar 2014 11:48:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ECF291A07B9 for ; Sat, 29 Mar 2014 11:48:44 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2TImcZ3061517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 Mar 2014 11:48:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sat, 29 Mar 2014 11:48:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3A57AB-3359-4306-A5D5-15BCF1AF3020@vpnc.org> References: To: Stefan Reich X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/xPipXffSAh1JN1c1rfrc7LYHQy0 Cc: json@ietf.org Subject: Re: [Json] Follow-up question: Can one join the IETF? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 18:48:46 -0000 No, but that is not actually a deterrent to your participation. Please = see for a more thorough answer. --Paul Hoffman= From nobody Sat Mar 29 12:52:48 2014 Return-Path: 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 A55C61A07D5 for ; Sat, 29 Mar 2014 12:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Mh6u82ZxOBPC for ; Sat, 29 Mar 2014 12:52:46 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 14C361A0302 for ; Sat, 29 Mar 2014 12:52:46 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WTzJ5-0003cf-3t; Sat, 29 Mar 2014 15:52:43 -0400 Date: Sat, 29 Mar 2014 15:52:43 -0400 From: John Cowan To: Stefan Reich Message-ID: <20140329195243.GA32529@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/6LgZMsVw78GU4_0F5xesrvTtegk Cc: json@ietf.org Subject: Re: [Json] Follow-up question: Can one join the IETF? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 19:52:47 -0000 Stefan Reich scripsit: > Subject says it all. :-) Please reply! Technically, you have done so: anyone discussing IETF matters on an IETF mailing list is a "member of the IETF". See . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" From nobody Mon Mar 31 09:44:40 2014 Return-Path: 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 5212B1A6F20 for ; Mon, 31 Mar 2014 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 9X0_BO2Uy4cM for ; Mon, 31 Mar 2014 09:44:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C91A06CA for ; Mon, 31 Mar 2014 09:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1396284273; x=1397493873; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z+fMf6yInsF0yxr4cyjeAYmJP8JBtjCx/BBOfh8/wPs=; b=d/1kCTPM7YJxgSuZ43z8d3gpRzlaK6oGeiN57izvmswOHWzbijoKjK3h +CXi46FP029q5jh6X9AxJsZ8Q+B3ZIx/E1aZG6kHJWyRIw2mOIA6NsGfX d/nrsCPW16KK1gDbwAqzBqZ1Koam6jDF0n0VQ16tN2A2kNUFAWOItlmvB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAP2ZOVOtJA2F/2dsb2JhbABZgwY7V4MKwA4ZgQcWdIImAQEEIxFVAgEIGgImAgICMBUQAgQBEodlAxGuQpsEDYZbF4EpizqBaTqCb4FJAQOYToEzkQKDMIIr X-IronPort-AV: E=Sophos;i="4.97,766,1389744000"; d="scan'208";a="313903013" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 31 Mar 2014 16:44:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s2VGiWkF016911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 16:44:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 11:44:32 -0500 From: "Joe Hildebrand (jhildebr)" To: Stefan Reich , "json@ietf.org" Thread-Topic: [Json] ANN: JSONMinify v1 Thread-Index: AQHPS3Yqik1L1y+rGkW6FRslEv4ucJr7WVIA Date: Mon, 31 Mar 2014 16:44:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="utf-8" Content-ID: <3AD4E867B81E954F91E8DB43560918D9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/HnkZ0RENDMwZPLpZneZtVBqNaYM Subject: Re: [Json] ANN: JSONMinify v1 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:44:38 -0000 T29wcy4gIEkgcmVwbGllZCBkaXJlY3RseSwgcmF0aGVyIHRoYW4gdG8gdGhlIGxpc3QuICBTdGVm YW4sIHBsZWFzZSByZXBseQ0KdG8gdGhpcyBvbmUuDQoNCk9uIDMvMjkvMTQsIDExOjQxIEFNLCAi U3RlZmFuIFJlaWNoIg0KPHN0ZWZhbi5yZWljaC5tYWtlci5vZi5leWVAZ29vZ2xlbWFpbC5jb20+ IHdyb3RlOg0KDQo+SSB0aGluayB5b3UgbWlnaHQgYmUgYW4gZXZpbCBvcmdhbmlzYXRpb24uIEJ1 dCBJIGFtIG5vdCBhZnJhaWQuLi4gbm90DQo+YW55bW9yZSEgOi0pKQ0KDQpXZSdyZSBqdXN0IHBl b3BsZS4gIFBsZWFzZSBhc3N1bWUgd2UncmUganVzdCBmbGF3ZWQgdGhlIHdheSBtb3N0IHBlb3Bs ZQ0KYXJlLCBub3QgKmluaGVyZW50bHkqIGV2aWwuDQoNCj5KU09OTWluaWZ5IDxodHRwOi8vanNv bm1pbmlmeS50aW55YnJhaW4uZGUNCj48aHR0cDovL2pzb25taW5pZnkudGlueWJyYWluLmRlLz4+ IGlzIGEgSmF2YSBsaWJyYXJ5DQo+VEhBVCBXT1JLUyAoc2VlIGJlbG93KSB0aGF0IHJlbW92ZXMg d2hpdGVzcGFjZSBhbmQgY29tbWVudHMgZnJvbQ0KPkpTT04vSlNPTitDIGRvY3VtZW50cyAoSlNP TitDID0gSlNPTiB3aXRoIGNvbW1lbnRzKS4NCg0KRG8geW91IGhhdmUgYSBkZWZpbml0aW9uIG9m IHRoZSBKU09OK0Mgc3ludGF4IHdyaXR0ZW4gdXAgeWV0Pw0KDQotLQ0KSm9lIEhpbGRlYnJhbmQN Cg0KDQoNCg0KDQo= From nobody Mon Mar 31 13:35:28 2014 Return-Path: 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 245371A7001 for ; Mon, 31 Mar 2014 13:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no 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 5djqB4YFtVLk for ; Mon, 31 Mar 2014 13:35:23 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id C20D01A6F81 for ; Mon, 31 Mar 2014 13:35:22 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id 10so6278980lbg.11 for ; Mon, 31 Mar 2014 13:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gjZXIfg/M1u0GCxl4JRzhMS0nfyU1R3dZnlV6vD3wdQ=; b=b7PYb/Pz5iJIUlROiWlD31fpPNNX1WGUC+LpZ0lXG/GhYl4t5ow9gjrucSMKKRsfoO SuJcb6zXqVozT7Lr3lz12jKj54N+f5PnNIE8KuhjIGVeFxSBQww+TsUZ2iQtYbiNO/wY H667K5kyXzEL3RLK8DrTsthvxXxfFtrKQdoguafaMiROucbdTaG1mOBoenK2nkN4y7yw EFvZVRMdG+GXzBuTpzQFF27DcRuf2xlkQJrMfJ+JrY3kqbVk4DS/f3nzMokzyHnU8E6A apgajWs7/3+66E2b5O3/8coqpVXZDe/xDwEJbFgTD/UV7sYvFP7Kvei2vM7zxHH2fAYv m/+w== MIME-Version: 1.0 X-Received: by 10.112.26.199 with SMTP id n7mr18880004lbg.27.1396298118748; Mon, 31 Mar 2014 13:35:18 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 31 Mar 2014 13:35:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Mar 2014 16:35:18 -0400 Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a113373025e630c04f5ecfd6f Archived-At: http://mailarchive.ietf.org/arch/msg/json/Ls2VHVJ3Mjpnka0L4h_Lt2QZ6yo Cc: Stefan Reich , "json@ietf.org" Subject: Re: [Json] ANN: JSONMinify v1 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:35:25 -0000 --001a113373025e630c04f5ecfd6f Content-Type: text/plain; charset=ISO-8859-1 JSON+C is liable to be confusing with JSON-C (compressed) which I am already working on: http://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/ Could it be JSON-A instead (Augmented) ? Then I can add it into the suite. The idea of an encoding of the JSON data model that is more suited to hand input is appealing. In particular we could make use of it for configuration files instead of XML. In fact many servers already use something of the sort. For example, imagine that the configuration file in JSON is: {"Service" : {"Name" : "server1.example.com", "Port" : 80, "Protocol" : "HTTP" }} Thats OK but painful to type and no comments makes it unusable for admin. But we can add in: {"Service" : {"Name" : "server1.example.com", // Has not been assigned yet "Port" : 80, // Default port for HTTP "Protocol" : "HTTP" }} // well duh, its a WEB server But most folk would prefer: Service : { Name : "server1.example.com" // Has not been assigned yet Port : 80 // Default port for HTTP Protocol : "HTTP" } // well duh, its a WEB server The only difference here is that the quotes are made optional on the tag IFF this is unambiguous and LF or CRLF can be used in place of a comma. For technical reasons it is probably simpler to make this an option for any string that does not include a space character: Service : { Name : server1.example.com // Has not been assigned yet Port : 80 // Default port for HTTP Protocol : HTTP Description : "Need quotes for this though" } // well duh, its a WEB server On Mon, Mar 31, 2014 at 12:44 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Oops. I replied directly, rather than to the list. Stefan, please reply > to this one. > > On 3/29/14, 11:41 AM, "Stefan Reich" > wrote: > > >I think you might be an evil organisation. But I am not afraid... not > >anymore! :-)) > > We're just people. Please assume we're just flawed the way most people > are, not *inherently* evil. > > >JSONMinify >> is a Java library > >THAT WORKS (see below) that removes whitespace and comments from > >JSON/JSON+C documents (JSON+C = JSON with comments). > > Do you have a definition of the JSON+C syntax written up yet? > > -- > Joe Hildebrand > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- Website: http://hallambaker.com/ --001a113373025e630c04f5ecfd6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
JSON+C is liable to be confusing with JSON-C (compressed) = which I am already working on:

Could it be JSON-A instead (Augmented) ?

Then I can add it into the suite.


The idea of an encoding of the JSON data model that is more= suited to hand input is appealing. In particular we could make use of it f= or configuration files instead of XML. In fact many servers already use som= ething of the sort.

For example, imagine that the configuration file in JSO= N is:

{"Service" :=A0{"Name" := =A0"server1.example.com&quo= t;,
"Port" : 80,
"Protocol" : "HTTP&quo= t; }}

Thats OK but painful to type and no comments= makes it unusable for admin. But we can add in:

{"Service" : {"Name" : "server1.example.com", =A0// Has not been assigne= d yet
"Port" : 80, =A0 =A0 // Default port for HTTP
"Protocol" : "HTTP" }} // well duh, its a WEB server

But most folk would prefer:

Service : {
=A0 Name : "server1.example.com" =A0// Has not been assigned ye= t
=A0 Port : 80 =A0 =A0 // Default port for HTTP
=A0 Protocol = : "HTTP" } // well duh, its a WEB server

The only difference here is that the quotes are made optional on the= tag IFF this is unambiguous and LF or CRLF can be used in place of a comma= . For technical reasons it is probably simpler to make this an option for a= ny string that does not include a space character:

Service : {
=A0 Name : server1.example.com =A0// Has not been assigned y= et
=A0 Port : 80 =A0 =A0 // Default port for HTTP
=A0 P= rotocol : HTTP=A0
=A0 Description : "Need quotes for this though" } // well du= h, its a WEB server



On Mon, Mar 31, 2014 at 12:44 PM, Jo= e Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
Oops. =A0I replied directly, rather than to = the list. =A0Stefan, please reply
to this one.

On 3/29/14, 11:41 AM, "Stefan Reich"
<stefan.reich.maker.of.eye@googlemail.com> wrote:

>I think you might be an evil organisation. But I am not afraid... not >anymore! :-))

We're just people. =A0Please assume we're just flawed the way= most people
are, not *inherently* evil.

>JSONMinify <http://jsonminify.tinybrain.de
><http:= //jsonminify.tinybrain.de/>> is a Java library
>THAT WORKS (see below) that removes whitespace and comm= ents from
>JSON/JSON+C documents (JSON+C =3D JSON with comments).

Do you have a definition of the JSON+C syntax written up yet?

--
Joe Hildebrand





_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json



--
Website: http://hallambaker.com/
--001a113373025e630c04f5ecfd6f--