From tbray@textuality.com Mon Jan 6 15:53: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 1CBC61AE36B for ; Mon, 6 Jan 2014 15:53:07 -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 Acu_I_86oDBo for ; Mon, 6 Jan 2014 15:53:03 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1691AE36C for ; Mon, 6 Jan 2014 15:53:03 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id q8so10281083lbi.36 for ; Mon, 06 Jan 2014 15:52:54 -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:content-type; bh=4S/UZo+jLONf4cVqJHo0WKLvN9sXPJMN8zuBH+sX3pk=; b=IqT6jOyVcWOCDDFlbOQbgJ7PjE22UXeUoGMQvQA6acp5W//5XyD6N/xV3WXaS/xqEx cCWLfaeOcwdViC0yFO6Y3A+FnzIyamIVxLXl4QkHysm5FW76WriRQtswb4rrfcon9yim POFZb6KWi3McvsEcnG7kbnAqp+ZmhZItBXmM0C9ZF+DE97Qb3SLmQdlCrRtZeoBAuYlF NBWhTJTM/wH2cNGRNKs4ldWPynAl3zktI89kk1l9qWkVGgTz5uzLjMCwKphFR8k2mFyj 2E0wQbMUivol8DiNrdUir8C9xm7CYVnA2dRjY7vtbloV79DWhNQ8jR2wKeqz1zT7DghK BG8w== X-Gm-Message-State: ALoCoQmPVGDEAirNuHXAJTGka4SwHrB8sBBuB8AyLumz3ghGWdkRmXu+eeV8972RxGHdnqERo1sc MIME-Version: 1.0 X-Received: by 10.152.3.10 with SMTP id 10mr2283451lay.35.1389052374013; Mon, 06 Jan 2014 15:52:54 -0800 (PST) Received: by 10.114.24.6 with HTTP; Mon, 6 Jan 2014 15:52:53 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: <20140106235111.8963.33263.idtracker@ietfa.amsl.com> References: <20140106235111.8963.33263.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 15:52:53 -0800 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=089e014941f453dcd104ef55f514 Subject: [Json] Fwd: New Version Notification for draft-bray-i-json-01.txt 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, 06 Jan 2014 23:53:07 -0000 --089e014941f453dcd104ef55f514 Content-Type: text/plain; charset=UTF-8 Real HTML at https://www.tbray.org/tmp/draft-bray-i-json-01.html Updated to cover all the interop recommendations in the 4627bis draft, and to remove the self-identification stuff, aside from recommending that people who specify protocols based on i-json use an application/XXX+i-json media type. ---------- Forwarded message ---------- From: Date: Mon, Jan 6, 2014 at 3:51 PM Subject: New Version Notification for draft-bray-i-json-01.txt To: Tim Bray A new version of I-D, draft-bray-i-json-01.txt has been successfully submitted by Tim Bray and posted to the IETF repository. Name: draft-bray-i-json Revision: 01 Title: The I-JSON Message Format Document date: 2014-01-06 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-bray-i-json-01.txt Status: https://datatracker.ietf.org/doc/draft-bray-i-json/ Htmlized: http://tools.ietf.org/html/draft-bray-i-json-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-bray-i-json-01 Abstract: I-JSON is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. 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 --089e014941f453dcd104ef55f514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Real HTML at=C2=A0https://www.tbray.org/tmp/draft-bray-i-json-01.html=

Updated to cover all the interop recommendations in= the 4627bis draft, and to remove the self-identification stuff, aside from= recommending that people who specify protocols based on i-json use an appl= ication/XXX+i-json media type.


---------- Forwarded mes= sage ----------
From: <internet-drafts@ietf.org= >
Date: Mon, Jan 6, 2014 at 3:51 PM
Subject: New Version Notification for = draft-bray-i-json-01.txt
To: Tim Bray <tbray@textuality.com>



A new version of I-D, draft-bray-i-json-01.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bray-i-json
Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The I-JSON Message Format
Document date: =C2=A02014-01-06
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ie= tf.org/internet-drafts/draft-bray-i-json-01.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc= /draft-bray-i-json/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-bray-i-j= son-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/rfc= diff?url2=3Ddraft-bray-i-json-01

Abstract:
=C2=A0 =C2=A0I-JSON is a restricted profile of JSON designed to maximize =C2=A0 =C2=A0interoperability and increase confidence that software can pro= cess it
=C2=A0 =C2=A0successfully with predictable results.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e014941f453dcd104ef55f514-- From tony@att.com Mon Jan 6 17:25: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 17A271AE3B3 for ; Mon, 6 Jan 2014 17:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 tcjPiysymR6Q for ; Mon, 6 Jan 2014 17:25:38 -0800 (PST) Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B21AE3AB for ; Mon, 6 Jan 2014 17:25:38 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id s071PSNc000679 for ; Mon, 6 Jan 2014 17:25:29 -0800 Received: from vpn-135-70-96-217.vpn.swst.att.com ([135.70.96.217]) by maillennium.att.com (mailgw1) with ESMTP id <20140107012523gw100j0cd8e>; Tue, 7 Jan 2014 01:25:28 +0000 X-Originating-IP: [135.70.96.217] Message-ID: <52CB5782.2010001@att.com> Date: Mon, 06 Jan 2014 20:25:22 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tbray@textuality.com References: <20140106235111.8963.76125.idtracker@ietfa.amsl.com> In-Reply-To: <20140106235111.8963.76125.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030302060104090302060601" Cc: JSON WG Subject: Re: [Json] I-D Action: draft-bray-i-json-01.txt 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, 07 Jan 2014 01:25:40 -0000 This is a multi-part message in MIME format. --------------030302060104090302060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/6/14, 6:51 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : The I-JSON Message Format > Author : Tim Bray > Filename : draft-bray-i-json-01.txt A couple notes: There needs to be a registration template for the Structured Syntax Suffix +i-json, per rfc6838. This needs to go into an IANA Considerations section. Tony Hansen --------------030302060104090302060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/6/14, 6:51 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
        Title           : The I-JSON Message Format
        Author          : Tim Bray
	Filename        : draft-bray-i-json-01.txt

A couple notes: There needs to be a registration template for the Structured Syntax Suffix +i-json, per rfc6838. This needs to go into an IANA Considerations section.

    Tony Hansen
--------------030302060104090302060601-- From tbray@textuality.com Mon Jan 6 19:07: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 013B31ADF35 for ; Mon, 6 Jan 2014 19:07:03 -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 q5lblnK7K9Tl for ; Mon, 6 Jan 2014 19:07:01 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id 45D651AE3E1 for ; Mon, 6 Jan 2014 19:07:01 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id eh20so10389917lab.19 for ; Mon, 06 Jan 2014 19:06:52 -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=P317I/PhKq6kJb1xwxyImK7uBXtrZR27NBb3G2s5jU0=; b=aYPEHP6UEZCjVbRfRs+8toNX0vNYN0xc4wqz9bbFMi53KZYyxRpXNTFrbRrDfLdTyg GgLMbx3DPdL44bcviY9BgEDZWGoJlptyYMghQbyYRUsPIyvhJ0ytK+TpgcHl7TsSZDLK ckqD6rVpEiKNThmad2tC5pO0MOUeK/cLfLN/yVxl6q+6BG6xyLgQSQzRbkroIo9+9ssq qHK7o+jI//ywOOBMXycHpmnZ1cSvh+CaQfUEZKeXvhai1UK6fcIZTMtdN45wqev40hm7 xF5RXqOMdXg13+YJMxdKH8fw0eNpkJmkWNo6TDNhVDf99snZclx7aZqyZV6D6lBYYCra WFIw== X-Gm-Message-State: ALoCoQk8Zyw5vanhHJZBPXgBbEOiOOKKh454A2yKtHyEUGdlQKBNPC28E2IfMXawfRS7b5/qPVaG MIME-Version: 1.0 X-Received: by 10.152.22.201 with SMTP id g9mr2564066laf.27.1389063998893; Mon, 06 Jan 2014 19:06:38 -0800 (PST) Received: by 10.114.24.6 with HTTP; Mon, 6 Jan 2014 19:06:38 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <52CB5782.2010001@att.com> References: <20140106235111.8963.76125.idtracker@ietfa.amsl.com> <52CB5782.2010001@att.com> Date: Mon, 6 Jan 2014 19:06:38 -0800 Message-ID: From: Tim Bray To: Tony Hansen Content-Type: multipart/alternative; boundary=089e0158c308397f0704ef58aaf3 Cc: JSON WG Subject: Re: [Json] I-D Action: draft-bray-i-json-01.txt 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, 07 Jan 2014 03:07:03 -0000 --089e0158c308397f0704ef58aaf3 Content-Type: text/plain; charset=UTF-8 Yep. On Mon, Jan 6, 2014 at 5:25 PM, Tony Hansen wrote: > On 1/6/14, 6:51 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : The I-JSON Message Format > Author : Tim Bray > Filename : draft-bray-i-json-01.txt > > > A couple notes: There needs to be a registration template for the > Structured Syntax Suffix +i-json, per rfc6838. This needs to go into an > IANA Considerations section. > > Tony Hansen > --089e0158c308397f0704ef58aaf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yep.


On Mon, Jan 6, 2014 at 5:25 PM, Tony Hansen <tony@= att.com> wrote:
=20 =20 =20
On 1/6/14, 6:51 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Draf=
ts directories.
        Title           : The I-JSON Message Format
        Author          : Tim Bray
	Filename        : draft-bray-i-json-01.txt

A couple notes: There needs to be a registration template for the =20 Structured Syntax Suffix +i-json, per rfc6838. This needs to go into an IANA Considerations section.

=C2=A0=C2=A0=C2=A0 Tony Hansen

--089e0158c308397f0704ef58aaf3-- From tbray@textuality.com Fri Jan 10 13:14: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 283EA1AE1B3 for ; Fri, 10 Jan 2014 13:14:03 -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, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 6MB-9JGUJsC0 for ; Fri, 10 Jan 2014 13:14:02 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id E8D091AE12A for ; Fri, 10 Jan 2014 13:14:01 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id y1so3521039lam.25 for ; Fri, 10 Jan 2014 13:13:51 -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:date:message-id:subject:from:to :content-type; bh=+b4Zey1XOSerOR7aZUOi9xf9xRQLgjxI0yzagVlp3VU=; b=cSzNgPBBWR8XLtFk39qwjdJRWRTkXFo9Du2AE2fUz0VlKYr/MLSTwEYaCjE7fBlOZP L0/Xd+cIG15/jkhKICzfQvOLzanZz108PWssRQUe9kp/IDQPtZRDFq69elNrU7rEVApK GZxovaZ6k6v4AcPJ0jGsZWIeeO9gnQTioBhHxsCrbFEL432SNgOYXnDq4uStN/o4KHAq mMgCTtimzS4wO68rcCeP37AAxUNW5M+UoHfuo07Xhf3PYVUQeHKuJ2nU6BdyEhJ2MqfB yqYa5LxmbO/HSEHdlF6busftRB8LBL9IK7gGzbP8jp/STsYIhCfYb2S5SpoqJ979+2gj cHsg== X-Gm-Message-State: ALoCoQkoMiNCnbm64X5bLBz4gWzM6TUr/HlaaWkslY7UBpspYo0XiF48HfjbEQghlTnNbFPCURMj MIME-Version: 1.0 X-Received: by 10.112.201.167 with SMTP id kb7mr4431290lbc.32.1389388431054; Fri, 10 Jan 2014 13:13:51 -0800 (PST) Received: by 10.114.24.6 with HTTP; Fri, 10 Jan 2014 13:13:51 -0800 (PST) X-Originating-IP: [96.49.81.176] Date: Fri, 10 Jan 2014 13:13:51 -0800 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c25896e35e2804efa43345 Subject: [Json] =?utf-8?q?What=E2=80=99s_up_with_4627bis=3F?= 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, 10 Jan 2014 21:14:03 -0000 --001a11c25896e35e2804efa43345 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My IETF-process-fu is weak. Would like to start talking about I-JSON, the actual reason I=E2=80=99ve be= en investing this work. --001a11c25896e35e2804efa43345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My IETF-process-fu is weak. =C2=A0

Woul= d like to start talking about I-JSON, the actual reason I=E2=80=99ve been i= nvesting this work.
--001a11c25896e35e2804efa43345-- From julian.reschke@gmx.de Fri Jan 10 14:01: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 8CEBD1AE20E for ; Fri, 10 Jan 2014 14:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 M25Fvw0GZkR1 for ; Fri, 10 Jan 2014 14:01:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 58FFA1AE20D for ; Fri, 10 Jan 2014 14:01:09 -0800 (PST) Received: from [192.168.2.117] ([93.217.65.199]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LaGfK-1VfHpE2HQk-00m4du for ; Fri, 10 Jan 2014 23:00:58 +0100 Message-ID: <52D06D97.4050000@gmx.de> Date: Fri, 10 Jan 2014 23:00:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tim Bray , "json@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:XWkuiNwEwi/MQgS8LZEn7ADkKDNjG58fuo0904rCJVU22yfPpYE bfUtLyAL9w/ArQ5lMYqmFRq/xJaqnxM6WLGl2xmIbjboXfT6rvpT3RdufF1nG2kWnomNQKJ 28VJ0mGfvGj+bezOzesQTyWaxKC3Z4ORDwqLEroL/FXlXjwtWsMMdCRO7hDz9UzhEKSi8EG YKpGs1cQ9UFj8xxpRZUqQ== Subject: Re: [Json] =?windows-1252?q?What=92s_up_with_4627bis=3F?= 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, 10 Jan 2014 22:01:12 -0000 On 2014-01-10 22:13, Tim Bray wrote: > My IETF-process-fu is weak. > > Would like to start talking about I-JSON, the actual reason I’ve been > investing this work. Sounds like Pete needs to send a "follow up". Best regards, Julian From presnick@qti.qualcomm.com Fri Jan 10 14:40: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 5A2EA1AE1D4 for ; Fri, 10 Jan 2014 14:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 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, RP_MATCHES_RCVD=-0.538, 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 sQnpueuqlmrb for ; Fri, 10 Jan 2014 14:40:52 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 016AA1ACCF2 for ; Fri, 10 Jan 2014 14:40: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=1389393642; x=1420929642; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JVNWiuLqLCxrnzt4vhetv6EF9FM0fpuBEv4gZ7yPJys=; b=J8O3kCt42iJdnO+ualPmA4e7mPFFjsuqj9+TgTA62JRbk34n4Nsgwqm0 8x+4JfNRkFE8UChDoP+CJahQOoZq/OLTG6CkKw5KSAyFIMRkmxAIDIKb/ SSoYhMWVNPCPnuDQjiJvpKkdZ96YwA5nu5yh3eaq8YanylXeDwf0jeLKd E=; X-IronPort-AV: E=McAfee;i="5400,1158,7314"; a="58062613" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 10 Jan 2014 14:40:41 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7314"; a="574679383" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jan 2014 14:40:41 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 14:40:41 -0800 Message-ID: <52D076E8.3030609@qti.qualcomm.com> Date: Fri, 10 Jan 2014 16:40:40 -0600 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: <52D06D97.4050000@gmx.de> In-Reply-To: <52D06D97.4050000@gmx.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] =?windows-1252?q?What=92s_up_with_4627bis=3F?= 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, 10 Jan 2014 22:40:53 -0000 On 1/10/14 4:00 PM, Julian Reschke wrote: > On 2014-01-10 22:13, Tim Bray wrote: >> My IETF-process-fu is weak. >> >> Would like to start talking about I-JSON, the actual reason I’ve been >> investing this work. > > > > Sounds like Pete needs to send a "follow up". Yup. Post-holiday nonsense is at an impressive level. I will be working this weekend. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From ysharp.design@yahoo.com Fri Jan 10 22: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 C4DE21AE09D for ; Fri, 10 Jan 2014 22:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] 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 whHDOwxhztBF for ; Fri, 10 Jan 2014 22:57:58 -0800 (PST) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) by ietfa.amsl.com (Postfix) with ESMTP id 550941AE051 for ; Fri, 10 Jan 2014 22:57:57 -0800 (PST) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:57:47 -0000 Received: from [98.138.226.180] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:54:50 -0000 Received: from [98.139.212.150] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:54:50 -0000 Received: from [98.139.212.197] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2014 06:54:50 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 11 Jan 2014 06:54:50 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 233741.86592.bm@omp1006.mail.bf1.yahoo.com Received: (qmail 78347 invoked by uid 60001); 11 Jan 2014 06:54:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1389423290; bh=DKuqgWW77a17Bh6rHJkwLtjT2h7Cb+QTXXHjf+feLtE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NXEV+VyKIC99N+J7iMSaoL71nuk3tMobYaK2OxEVQNTMUq6ISnSuPDqObHMqKxB25qRq+3zOBLtqR7tHw6cxVAnr9t9N7t0bthN9wTZyKMRhSkOLLZrq79dMFpmvFfkoGm3XIa+pQzawEabDZ3foSXFRZ/9gdH4FLqeLkOMO06M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MVsFsRSFbxeVroAbvA7Mn/3srH292hYR/MkKN/F/LtuXFdcI9wUvyZF1wfAnKIO3xklg2YGwiuxNU9F61lpGPyvKiRDyQB3D8kgwtrSAzzQbpilgGoHmNOYwZvSdk7THMaiwlgxAUkr/NmZmUWHyEE9jREhmnhTk85ztk0Frmfg=; X-YMail-OSG: C2k7NmEVM1nxWphTc2qlu4dgUyOmjeTvKkJh_yz1asSxu5U 3T9NhbKs2_29g0JtgVRMbfLpg.Hhb_tRgQFb0_AtLdmmN7HbbsokGg4ZyoCV a9SZzfwVRh4jBTItUI7IRjSE60nZk96nTrV.afEqIFC9nQuxWY.Ef7PV7Kwi OlVwjN4j1v8axEEmc1uorHlFo5ezosuShSLxo3zFI5.esONzsafmmTUdbdbp 2N01DJUpoqoT6rGrprtVS.u0hKuJBlPKJcj_awLYRUxd0wwMzffWLeZ7Xqu_ lCvPzYEDGZ7J2JB0O.ckONyVEgx5D_726oquwe7_jY_hHFb1o0JUlc1qWL9b nonOxrOSsTpHJocPvmOnel9kXMjSZmIpFwzYOTTMzGyxah07cmGUyUdPVpYw GHJkLC1yV3Y83Hemss3gmk.jgZ259jUup0Vqi5LU1wXHpBpNyLzGnA9RwwPP 9FKICwkDnJALkBuCAHoruMNEqOP69QLgQHYjhQ2cYbxcQEWOpEymZcX1moMW .h9s2MRHplPvx03ohZ40MbqqBWXWUYwfisamPZ7AFPt.5NBbLreddbcbA5rh RQhd.X6YKxP0FbQ34.KzINECsXuAnIAa2sLITKW4Lqng_3yayEtfiIWS0Ucm Bewoili6ClS8QvZhU_hwaHwznk723Y_bXjXka65FSzFLubyK2OiX46tQnjne y2RDxXfVbwd9TZhns_x2rmf0E9hhILEQDcoS_MSBGgG.f6rVEw00FwuVfBTo mQ7QYFVuBqqfWQ4DpIjijB9_PKl5MK9AkelWkWdqiwFIQFNYanAiZHvDb52V PMt20fB.pKREcUMeWdBJIY57MUzvD1_eXcrqzTcVeaNRPSlf2mE1CK6LIOny SLPBZwK4ejGXw7m4HzJJakDoRkHKZlRHoT4o0pgt07eLexSj6wXRnM26sFul ObFVct9MpHTlpn2a6mcOE Received: from [67.180.136.63] by web162505.mail.bf1.yahoo.com via HTTP; Fri, 10 Jan 2014 22:54:49 PST X-Rocket-MIMEInfo: 002.001, SGkgYWxsLAoKQXMgYSBuZXdjb21lciB0byB0aGlzIGxpc3QncyB0aHJlYWRzIHRoYXQgSSdtIHN0aWxsIHRyeWluZyB0byBncm9rIGZyb20gdGhlaXIgYmVnaW5uaW5nLCBJIGhvcGUgSSBkaWRuJ3QgbWlzcyB0aGUgZm9sbG93aW5nIHRvcGljIHBvc3NpYmx5IGFscmVhZHkgbWVudGlvbmVkLgoKSWYgSSBkaWRuJ3QsIEkgbWlnaHQgaGF2ZSBzb21ldGhpbmcgb2YgaW50ZXJlc3QgZm9yIFRpbSwgd3J0LiBJLUpTT04uCgpBcyBib3RoIGEgdXNlciBhbmQgaW1wbGVtZW50b3Igb2YgYSBKU09OIHBhcnNlciAoYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.172.614 Message-ID: <1389423289.73944.YahooMailNeo@web162505.mail.bf1.yahoo.com> Date: Fri, 10 Jan 2014 22:54:49 -0800 (PST) From: Cyril J To: "json@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Json] =?utf-8?q?What=E2=80=99s_up_with_4627bis=3F?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Cyril J List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 07:03:02 -0000 Hi all,=0A=0AAs a newcomer to this list's threads that I'm still trying to = grok from their beginning, I hope I didn't miss the following topic possibl= y already mentioned.=0A=0AIf I didn't, I might have something of interest f= or Tim, wrt. I-JSON.=0A=0AAs both a user and implementor of a JSON parser (= and "deserializer") I couldn't miss to notice the rather ad-hoc, implementa= tion-dependent, solution to a seemingly frequent, recurring problem, in a s= tatically typed deserialization use case.=0A=0AIndeed, it isn't difficult t= o find many examples of applications written in statically typed languages = which, also, find themselves in an interesting situation with the following= facets:=0A=0A1) they need to consume some incoming JSON=0A2) they are (for= whatever, various legacy reasons) firmly relying on the "natural" static t= ype system of their platform=0A3) yet, (for whatever, other various legacy = reasons) they cannot quite afford to step back and settle once and for all,= as they should, for any of the schema languages for JSON - assuming they'd= have one meeting their needs (or for other non-schema-based, cleaner refac= toring)=0A4) but still, they need to "deserialize" that JSON into fresh ins= tances of object oriented (or not OO) *strongly typed* data structures - by= that I mean of course: going beyond just a plain vanilla hash map "string = to object"=0A=0AOf course, it didn't take long for JSON librairies implemen= tors to come up with the classic in-band-signalling workaround:=0A=0A... { = "$type": "Acme.Business.Model.CompanyDomain.Affiliate", "CompanyId": 123, .= .. }=0A=0A"You wanna know the type of that thing? Well, there you go, here = it is, buddy..."=0A=0A(to which some apparently were like... "Hey! Where is= the type of that thing?!" - see links at the bottom)=0A=0ATalking about th= e .NET realm alone I can already count at least two competing conventions a= lready, with the question regularly coming on the table for JSON users, and= found in three of the most popular implementations [1] - i.e., choosing "$= type" vs. "__type" for the key holding the type information hint.=0A=0AFor = obvious reasons of ease of implementation, however, regardless of the type = info hint key convention in use, they all happen, at least, to agree on req= uiring the same relative position for that ad-hoc key in the JSON object be= ing deserialized - if it needs to be present, they expect to encounter it i= mmediately after parsing the start of JSON object, marked "{".=0A=0A(it's a= lso for efficiency, as implementations usually simply create a fresh instan= ce of the deserialization target type right after encountering and parsing = that key name)=0A=0ASo, I was just wondering if per chance I-JSON could fin= d the above use case legitimate enough to recommend to implementations some= BCP=C2=A0about it.=0A=0AThoughts?=0A=0AAllow? Disallow? Name if allowed? P= osition? Etc.=0A=0A'Hoping it's not just completely off-topic,=0A=0ACheers,= =0A=0A=0ACyril Jandia=0A=0A[1]=C2=A0http://stackoverflow.com/questions/9490= 345/json-net-change-type-field-to-another-name=0A=0A=0A(JSON.NET uses "$typ= e" for that, following a habit I believe was introduced by Microsoft, as ea= rly as [2])=0A=0A[2]=C2=A0http://msdn.microsoft.com/en-us/library/system.we= b.script.serialization.javascriptserializer(v=3Dvs.90).aspx=0A=0AWhile Serv= iceStack (and probably others) uses "__type":=0A=0A[3]=C2=A0http://stackove= rflow.com/questions/12731214/remove-concrete-type-information-in-json-respo= nse-using-jsonserializer From iesg-secretary@ietf.org Mon Jan 13 15:02: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 51BA01AE1C1; Mon, 13 Jan 2014 15:02:18 -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] 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 ry6Qljm8RPUQ; Mon, 13 Jan 2014 15:02:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0739A1AE1BC; Mon, 13 Jan 2014 15:02:10 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140113230210.32042.12572.idtracker@ietfa.amsl.com> Date: Mon, 13 Jan 2014 15:02:10 -0800 Cc: json mailing list , json chair , RFC Editor Subject: [Json] Protocol Action: 'The JSON Data Interchange Format' to Proposed Standard (draft-ietf-json-rfc4627bis-10.txt) 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: Mon, 13 Jan 2014 23:02:18 -0000 The IESG has approved the following document: - 'The JSON Data Interchange Format' (draft-ietf-json-rfc4627bis-10.txt) as Proposed Standard This document is the product of the JavaScript Object Notation Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/ Technical Summary This document is an update to RFC 4627, the RFC that describes the JSON format. (Note that there two other independent definitions of JSON: json.org, and ECMA-262 (Edition 5.1, June 2011). This document is a minimal update to RFC 4627 that corrects some errors, adds a bit of clarification, and points out topics where there have been interoperability issues since RFC 4627 was published. As stated in the charter, this document is meant to be a Proposed Standard. Working Group Summary The WG went through a couple of phases during the review, with some folks wanting to fix a lot of things, some wanting to basicly push it out untouched, and still others wanting a light touch with useful notes. In then end, there was rough group consensus for the latter. Near the end of the review cycle, Ecma issued a new document that defined (mostly) just the syntax for JSON, Standard ECMA-404. The syntaxes in this document and ECMA-404 appear identical. It is worthwhile noting that the syntaxes are described in different languages (this document uses ABNF, the Ecma document uses racetrack-style pictures). Note: The WG charter says: The resulting document will be jointly published as an RFC and by ECMA. ECMA participants will be participating in the working group editing through the normal process of working group participation. The responsible AD will coordinate the approval process with ECMA so that the versions of the document that are approved by each body are the same. None of that happened. This document stands on its own, as does ECMA-404 and upcoming revision to the ECMAScript standard. Document Quality This document had a wonderfully wide and deep review. The WG had a high number of IETF regulars and newcomers. Although we had little input from the members of TC39 in Ecma, we had lots of input from the larger JSON-using community, including many active developers of JSON libraries. Personnel Paul Hoffman (one of the WG co-chairs) is the document shepherd. Pete Resnick is the responsible AD. From mamille2@cisco.com Fri Jan 17 14:50: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 681881AD6C1 for ; Fri, 17 Jan 2014 14:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 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.538, 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 LwJRv96mj3fr for ; Fri, 17 Jan 2014 14:50:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6801AD6B9 for ; Fri, 17 Jan 2014 14:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1389999006; x=1391208606; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ass7D4N31gxk2py7hY95GqepIUi1WCcGpHHNGjpgEAE=; b=eskgxlhVrOqmcRVl/SyvtRT46ytdobTNBzoY+NB6b4PlI3ZcESEhRJ+e Y0SIytJ1EFXIikIEELoa63V9OGVnvn5n6Xs5i/iIHIxUV7OTXhzSDwKk1 zrQN1X9nLfw5s4/rmJlfjgrBbYByYmlnvqAYkR7OzVf2yiCYq6VBeATt0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0KANiy2VKtJXHA/2dsb2JhbABZgws4VqYnA5YHFnSDJD0WGAMCAQIBSw0IAQGIAZhiqzMXkz4EiQ84jlqSF4NNggo X-IronPort-AV: E=Sophos;i="4.95,676,1384300800"; d="scan'208";a="13723906" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 17 Jan 2014 22:50:05 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0HMo5LX022023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jan 2014 22:50:05 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 17 Jan 2014 16:50:05 -0600 Message-ID: <52D9B39C.5020102@cisco.com> Date: Fri, 17 Jan 2014 15:50:04 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.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.76] Subject: [Json] Proposed rechartering for the JSON WG 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, 17 Jan 2014 22:50:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Greetings again. Now that the WG has completed its single goal (on time! yay!), a decision needs to be made on what to do next. Based on our earlier discussions, the Chairs believe the WG has two items they want to work on: - - I-JSON, the current draft of which is draft-bray-i-json-01.txt - - Suggested guidelines for developers using JSON In the latter category we have "guidelines for defining JSON objects in other documents/protocols, to make sure that we use JSON primitives for those definitions, and don't try to duplicate JSON grammar in ABNF". We may have others as time goes on. We propose the following charter: - -----BEGIN 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 published in RFC 4627, an Informational document. JSON has come into very broad use, often instead of or in addition to XML. The JSON WG has already published a standards-track update to RFC 4627. The WG will work on two items: - - a restricted profile of JSON designed to maximize interoperability; the starting point will be draft-bray-i-json - - a set of guidelines for developers who use JSON Milestones: May 2014: WG LC on a restricted profile of JSON May 2014: WG LC on a set of guidelines for developers who use JSON June 2014: IETF LC on a restricted profile of JSON June 2014: IETF LC on a set of guidelines for developers who use JSON - -----END CHARTER----- Does anyone have comments, questions, or other feedback on this proposal? - -- Paul Hoffman and Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS2bOcAAoJEDWi+S0W7cO1RGsIAJUfUETL8ZZEC4QH3gkS9m4x 1bqUuxln0Hjsp4TnAJ/Jc+r82wRiuq+ow/QcrY696haA8SwD1ktGn5890nNIVthb kpNImQY20sRMOCNZvlRyvf3+AstHmTar1Pve7CNSX07VX3VF8SeQGcA7vKiR5qNH K+2VJRNzPpyg3YPyg7t60aAxhuvupK1jWzfzmkJtQ+TTJ65REk2V+ScDXe3nnllT nqgp36XmZDfEQLOix4VUu67kAFwpgpfXj8a0n7zeE7ipYmYALM2bPKHy1NupFXtY nqTNmGEiJO/HgzZmW4+rhClJNcCJRaQVOkBsKISimC8B96PUZdEVkvQFhgap5/Y= =EmeZ -----END PGP SIGNATURE----- From tbray@textuality.com Fri Jan 17 16:02: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 7B6181A8028 for ; Fri, 17 Jan 2014 16:02:13 -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 UjREfMmlJhRy for ; Fri, 17 Jan 2014 16:02:11 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9009B1A1521 for ; Fri, 17 Jan 2014 16:02:11 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so1886752vcb.3 for ; Fri, 17 Jan 2014 16:01:58 -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=sz/Zq2rggl6Tzh0zCzTZzc7YsGV5lNjU4ha7X7EdUN8=; b=GobfQTIvKV7c04neWVidy16+wudW7DOv7K+Aaew2YS9VN5vPeD/mpQhSejI29uqOtq jjE9egeiEDizS/v61gh2yxwM3e5NK3kTdvjPliHyNObFMHGp1aHpZK6xCnOiJT96tmWU hiloQfMoiR8/tOQiLL0+5WAIW9YoQ8N7qLMytku3tM36mKu8ByFqyJSqq6h/OtR5vnAo WevM7gxTKWOcpfLqTf+ySimtp8Sl3XyaqfPoyGHhh2yxViks+/6Gj3878kafYcaH6rLD LCPRi7fG3RpKxQh8nYZr+HDNNNrzeAcI1XE9KMZ5jfICvCHCyFgqTnstR0V2jHbeEruG 7siA== X-Gm-Message-State: ALoCoQlcLN1w5aEsIa9X2UfsWrJP8u9MCGX4Yxwe0JWv5ys935ieMf7bZBhEF2UvTHm+gutqxMQi MIME-Version: 1.0 X-Received: by 10.52.113.97 with SMTP id ix1mr2051137vdb.9.1390003318728; Fri, 17 Jan 2014 16:01:58 -0800 (PST) Received: by 10.220.98.73 with HTTP; Fri, 17 Jan 2014 16:01:58 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <52D9B39C.5020102@cisco.com> References: <52D9B39C.5020102@cisco.com> Date: Fri, 17 Jan 2014 16:01:58 -0800 Message-ID: From: Tim Bray To: Matt Miller Content-Type: multipart/alternative; boundary=bcaec548a6270cc4e104f0335e9e Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 18 Jan 2014 00:02:13 -0000 --bcaec548a6270cc4e104f0335e9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 17, 2014 at 2:50 PM, Matt Miller wrote: > Based on our earlier discussions, the Chairs believe the WG has two > items they want to work on: > > - - I-JSON, the current draft of which is draft-bray-i-json-01.txt > - - Suggested guidelines for developers using JSON > It sounds from your narrative that the latter might be rephrased as =E2=80=9Csuggested guidelines for spec authors using JSON=E2=80=9D? The gu= ideline for developer is simple: =E2=80=9CDon=E2=80=99t do anything that 4627bis identi= fies as getting in the way of interoperability=E2=80=9D. What I heard at the Vancouver F2F= was more along the lines of =E2=80=9Cwhat terminology should RFC writers use to describe the parts of a JSON message? To be clear: I am unconvinced that the suggested-guidelines-for-developers is really worth doing, if you have 4627bis identifying the problems and I-JSON providing a maximally-interoperable profile. I=E2=80=99m neutral-to-positive on guidelines-for-spec-authors. > > In the latter category we have "guidelines for defining JSON objects > in other documents/protocols, to make sure that we use JSON primitives > for those definitions, and don't try to duplicate JSON grammar in ABNF". > We may have others as time goes on. > > We propose the following charter: > > - -----BEGIN 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 published in RFC 4627, > an Informational document. JSON has come into very broad use, often > instead of or in addition to XML. The JSON WG has already published > a standards-track update to RFC 4627. > > The WG will work on two items: > > - - a restricted profile of JSON designed to maximize interoperability; > the starting point will be draft-bray-i-json > > - - a set of guidelines for developers who use JSON > > Milestones: > > May 2014: WG LC on a restricted profile of JSON > May 2014: WG LC on a set of guidelines for developers who use JSON > June 2014: IETF LC on a restricted profile of JSON > June 2014: IETF LC on a set of guidelines for developers who use JSON > > - -----END CHARTER----- > > Does anyone have comments, questions, or other feedback on this proposal? > > > - -- Paul Hoffman and Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJS2bOcAAoJEDWi+S0W7cO1RGsIAJUfUETL8ZZEC4QH3gkS9m4x > 1bqUuxln0Hjsp4TnAJ/Jc+r82wRiuq+ow/QcrY696haA8SwD1ktGn5890nNIVthb > kpNImQY20sRMOCNZvlRyvf3+AstHmTar1Pve7CNSX07VX3VF8SeQGcA7vKiR5qNH > K+2VJRNzPpyg3YPyg7t60aAxhuvupK1jWzfzmkJtQ+TTJ65REk2V+ScDXe3nnllT > nqgp36XmZDfEQLOix4VUu67kAFwpgpfXj8a0n7zeE7ipYmYALM2bPKHy1NupFXtY > nqTNmGEiJO/HgzZmW4+rhClJNcCJRaQVOkBsKISimC8B96PUZdEVkvQFhgap5/Y=3D > =3DEmeZ > -----END PGP SIGNATURE----- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec548a6270cc4e104f0335e9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 17, 2014 at 2:50 PM, Matt Miller <mamille2@cisco.com>= wrote:
=C2=A0
Based on our earlier discussions, the Chairs believe the WG has two
items they want to work on:

- - I-JSON, the current draft of which is draft-bray-i-json-01.txt
- - Suggested guidelines for developers using JSON
It sounds from your narrative that the latter might be rephrase= d as =E2=80=9Csuggested guidelines for spec authors using JSON=E2=80=9D? = =C2=A0The guideline for developer is simple: =E2=80=9CDon=E2=80=99t do anyt= hing that 4627bis identifies as getting in the way of interoperability=E2= =80=9D. =C2=A0What I heard at the Vancouver F2F was more along the lines of= =E2=80=9Cwhat terminology should RFC writers use to describe the parts of = a JSON message?

To be clear: I am unconvinced that the suggested-guidel= ines-for-developers is really worth doing, if you have 4627bis identifying = the problems and I-JSON providing a maximally-interoperable profile. =C2=A0= I=E2=80=99m neutral-to-positive on guidelines-for-spec-authors.


=C2=A0

In the latter category we have "guidelines for defining JSON objects in other documents/protocols, to make sure that we use JSON primitives
for those definitions, and don't try to duplicate JSON grammar in ABNF&= quot;.
We may have others as time goes on.

We propose the following charter:

- -----BEGIN 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 published in RFC 4627,
an Informational document. JSON has come into very broad use, often
instead of or in addition to XML. The JSON WG has already published
a standards-track update to RFC 4627.

The WG will work on two items:

- - a restricted profile of JSON designed to maximize interoperability;
=C2=A0 the starting point will be draft-bray-i-json

- - a set of guidelines for developers who use JSON

Milestones:

May 2014: =C2=A0 =C2=A0WG LC on a restricted profile of JSON
May 2014: =C2=A0 =C2=A0WG LC on a set of guidelines for developers who use = JSON
June 2014: =C2=A0 IETF LC on a restricted profile of JSON
June 2014: =C2=A0 IETF LC on a set of guidelines for developers who use JSO= N

- -----END CHARTER-----

Does anyone have comments, questions, or other feedback on this proposal?

- -- Paul Hoffman and Matt Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS2bOcAAoJEDWi+S0W7cO1RGsIAJUfUETL8ZZEC4QH3gkS9m4x
1bqUuxln0Hjsp4TnAJ/Jc+r82wRiuq+ow/QcrY696haA8SwD1ktGn5890nNIVthb
kpNImQY20sRMOCNZvlRyvf3+AstHmTar1Pve7CNSX07VX3VF8SeQGcA7vKiR5qNH
K+2VJRNzPpyg3YPyg7t60aAxhuvupK1jWzfzmkJtQ+TTJ65REk2V+ScDXe3nnllT
nqgp36XmZDfEQLOix4VUu67kAFwpgpfXj8a0n7zeE7ipYmYALM2bPKHy1NupFXtY
nqTNmGEiJO/HgzZmW4+rhClJNcCJRaQVOkBsKISimC8B96PUZdEVkvQFhgap5/Y=3D
=3DEmeZ
-----END PGP SIGNATURE-----
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--bcaec548a6270cc4e104f0335e9e-- From duerst@it.aoyama.ac.jp Mon Jan 20 02:52: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 66B611A0110 for ; Mon, 20 Jan 2014 02:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.535] 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 89sC8TyawR37 for ; Mon, 20 Jan 2014 02:52:02 -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 745921A00EB for ; Mon, 20 Jan 2014 02:52:02 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0KApt7G028849; Mon, 20 Jan 2014 19:51:55 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 092e_d89d_e08e378c_81c0_11e3_a6bf_001e6722eec2; Mon, 20 Jan 2014 19:51:54 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 72967BF54D; Mon, 20 Jan 2014 19:51:54 +0900 (JST) Message-ID: <52DCFFC0.3000605@it.aoyama.ac.jp> Date: Mon, 20 Jan 2014 19:51:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Matt Miller References: <52D9B39C.5020102@cisco.com> In-Reply-To: <52D9B39C.5020102@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 20 Jan 2014 10:52:06 -0000 On 2014/01/18 7:50, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Greetings again. Now that the WG has completed its single goal (on > time! yay!), a decision needs to be made on what to do next. > > Based on our earlier discussions, the Chairs believe the WG has two > items they want to work on: > > - - I-JSON, the current draft of which is draft-bray-i-json-01.txt I have looked at this draft. The actual technical content (no duplicate names, no lone surrogates,...) is just fine. However, I strongly doubt the point of creating a separate Media type suffix ("application/XXX+i-json"). I think this will cause more confusion and fragmentation than benefit. There is nothing explicit in the current charter that requires a separate Media type suffix, but I'm voicing this concern here because it may be seen as implied by the charter by some people. Regards, Martin. > - - Suggested guidelines for developers using JSON > > In the latter category we have "guidelines for defining JSON objects > in other documents/protocols, to make sure that we use JSON primitives > for those definitions, and don't try to duplicate JSON grammar in ABNF". > We may have others as time goes on. > > We propose the following charter: > > - -----BEGIN 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 published in RFC 4627, > an Informational document. JSON has come into very broad use, often > instead of or in addition to XML. The JSON WG has already published > a standards-track update to RFC 4627. > > The WG will work on two items: > > - - a restricted profile of JSON designed to maximize interoperability; > the starting point will be draft-bray-i-json > > - - a set of guidelines for developers who use JSON > > Milestones: > > May 2014: WG LC on a restricted profile of JSON > May 2014: WG LC on a set of guidelines for developers who use JSON > June 2014: IETF LC on a restricted profile of JSON > June 2014: IETF LC on a set of guidelines for developers who use JSON > > - -----END CHARTER----- > > Does anyone have comments, questions, or other feedback on this proposal? > > > - -- Paul Hoffman and Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJS2bOcAAoJEDWi+S0W7cO1RGsIAJUfUETL8ZZEC4QH3gkS9m4x > 1bqUuxln0Hjsp4TnAJ/Jc+r82wRiuq+ow/QcrY696haA8SwD1ktGn5890nNIVthb > kpNImQY20sRMOCNZvlRyvf3+AstHmTar1Pve7CNSX07VX3VF8SeQGcA7vKiR5qNH > K+2VJRNzPpyg3YPyg7t60aAxhuvupK1jWzfzmkJtQ+TTJ65REk2V+ScDXe3nnllT > nqgp36XmZDfEQLOix4VUu67kAFwpgpfXj8a0n7zeE7ipYmYALM2bPKHy1NupFXtY > nqTNmGEiJO/HgzZmW4+rhClJNcCJRaQVOkBsKISimC8B96PUZdEVkvQFhgap5/Y= > =EmeZ > -----END PGP SIGNATURE----- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From dret@berkeley.edu Tue Jan 21 01: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 4486D1A00A2 for ; Tue, 21 Jan 2014 01:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 jf2SWrtChVTy for ; Tue, 21 Jan 2014 01:46:05 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id C11BC1A0087 for ; Tue, 21 Jan 2014 01:46:05 -0800 (PST) Received: from 91-66-137-169-dynip.superkabel.de ([91.66.137.169] helo=dretair13.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1W5XuE-0000Rk-EW; Tue, 21 Jan 2014 01:46:04 -0800 Message-ID: <52DE41D6.7030105@berkeley.edu> Date: Tue, 21 Jan 2014 10:45:58 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Matt Miller References: <52D9B39C.5020102@cisco.com> <52DCFFC0.3000605@it.aoyama.ac.jp> In-Reply-To: <52DCFFC0.3000605@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 21 Jan 2014 09:46:07 -0000 hello martin. On 2014-01-20, 11:51 , "Martin J. Dürst" wrote: > I have looked at this draft. The actual technical content (no duplicate > names, no lone surrogates,...) is just fine. However, I strongly doubt > the point of creating a separate Media type suffix > ("application/XXX+i-json"). I think this will cause more confusion and > fragmentation than benefit. > There is nothing explicit in the current charter that requires a > separate Media type suffix, but I'm voicing this concern here because it > may be seen as implied by the charter by some people. i think i have made this point before, but i'll briefly repeat it. it would be possible to go a different route, and i am wondering what you think about this one: - allow a "profile" media type parameter for the json media type (it could be added to JSONbis, and could look similar to the media type parameter drafted in http://tools.ietf.org/html/draft-wilde-atom-profile) - define a profile URI for I-JSON in the I-JSON spec, and then define I-JSON to use the regular JSON media type. the fact that some JSON actually is I-JSON then could be (optionally) indicated by adding a profile media type parameter with that specific profile URI. - any JSON-based media type then could simply use the +json suffix, and could allow the profile media type parameter to indicate I-JSON, if that's something that the media type wants to allow. kind regards, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From duerst@it.aoyama.ac.jp Tue Jan 21 03:16: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 5D2301A009D for ; Tue, 21 Jan 2014 03:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 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.535] 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 EUMDQfDp2NbG for ; Tue, 21 Jan 2014 03:16:00 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E82E61A00B1 for ; Tue, 21 Jan 2014 03:15:57 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0LBFbg1013121; Tue, 21 Jan 2014 20:15:38 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6b24_8215_5aec09a6_828d_11e3_a1b5_001e6722eec2; Tue, 21 Jan 2014 20:15:37 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 130EDBF4E2; Tue, 21 Jan 2014 20:15:37 +0900 (JST) Message-ID: <52DE56CD.708@it.aoyama.ac.jp> Date: Tue, 21 Jan 2014 20:15:25 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Erik Wilde References: <52D9B39C.5020102@cisco.com> <52DCFFC0.3000605@it.aoyama.ac.jp> <52DE41D6.7030105@berkeley.edu> In-Reply-To: <52DE41D6.7030105@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 21 Jan 2014 11:16:02 -0000 Hello Erik, On 2014/01/21 18:45, Erik Wilde wrote: > hello martin. > > On 2014-01-20, 11:51 , "Martin J. D=C3=BCrst" wrote: >> I have looked at this draft. The actual technical content (no duplicat= e >> names, no lone surrogates,...) is just fine. However, I strongly doubt >> the point of creating a separate Media type suffix >> ("application/XXX+i-json"). I think this will cause more confusion and >> fragmentation than benefit. >> There is nothing explicit in the current charter that requires a >> separate Media type suffix, but I'm voicing this concern here because = it >> may be seen as implied by the charter by some people. > > i think i have made this point before, but i'll briefly repeat it. it > would be possible to go a different route, and i am wondering what you > think about this one: > > - allow a "profile" media type parameter for the json media type (it > could be added to JSONbis, and could look similar to the media type > parameter drafted in http://tools.ietf.org/html/draft-wilde-atom-profil= e) > > - define a profile URI for I-JSON in the I-JSON spec, and then define > I-JSON to use the regular JSON media type. the fact that some JSON > actually is I-JSON then could be (optionally) indicated by adding a > profile media type parameter with that specific profile URI. > > - any JSON-based media type then could simply use the +json suffix, and > could allow the profile media type parameter to indicate I-JSON, if > that's something that the media type wants to allow. I guess the following point also has been made before: If you label the differences (it doesn't matter much whether that's done=20 with a Media type suffix, with a parameter, with an URI, or what), you=20 have the problem that something may be JSON, but not I-JSON, but still=20 labeled as such. You then either check, which means people will just use=20 JSON to not get errors, or you don't check, in which case I-JSON is=20 useless from the start. What we want to get to is that parsers have a setting so that for=20 certain applications, where so specified, the input can be checked to=20 avoid problems later on. In some cases, e.g. security-related stuff,=20 "application" may be a whole Media type (e.g.=20 application/securefoo+json). In other cases, it may be just an agreement=20 between two parties, or a condition of using a service, to always send=20 I-JSON, even if the same kind of data is used without necesarily=20 adhering to I-JSON between other parties. Regards, Martin. From barryleiba.mailing.lists@gmail.com Wed Jan 22 07:09: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 472941A00CF for ; Wed, 22 Jan 2014 07:09:55 -0800 (PST) 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 mOk_OI25Pfes for ; Wed, 22 Jan 2014 07:09:54 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A1E731A00EF for ; Wed, 22 Jan 2014 07:09:52 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id o19so286958vbm.33 for ; Wed, 22 Jan 2014 07:09:51 -0800 (PST) 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=kb7K55mOTx8GCRmaaxQ8zAmWuayAff0onQeXMtpwnTg=; b=rFX0jwMjewIdXFldKqKqcjUm0B9RJbXTHhaoiJ8+eNN3c1JVBvo9nggZsDlyxEPY+q 2qEL3RbBoHIQf6+GHpAYuL/3dLcSTpQlJ2/LtkvqiusHRFzVe0v6m3xRcNx8jfHFECjv ijen/YqZ5ZCdp57A8ecoqkZD29WXNSO6iXhVWavm5PHHdUAR8YRD0Jt2fGsQQjY9JEyq dDuK3K2QL9zPFxSBe/M/u1I4CWI0j7XbII7IHWB9rNjuMg/OWTiZVehfyhcUxFlHRyAa uY19+81LUgLWP7cNGevF9eTXLbbpfT/nCJ9sK4OjU+bAqg8D8u0NMV0+6s1iUTIKeG7L B+ag== MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr1259246vcx.1.1390403391896; Wed, 22 Jan 2014 07:09:51 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.170.71 with HTTP; Wed, 22 Jan 2014 07:09:51 -0800 (PST) In-Reply-To: <52D9B39C.5020102@cisco.com> References: <52D9B39C.5020102@cisco.com> Date: Wed, 22 Jan 2014 10:09:51 -0500 X-Google-Sender-Auth: 9l5TCufQFdSM79LK3w_mHYYj-Rg Message-ID: From: Barry Leiba To: Matt Miller Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 15:09:55 -0000 > Based on our earlier discussions, the Chairs believe the WG has two > items they want to work on: > > - - I-JSON, the current draft of which is draft-bray-i-json-01.txt > - - Suggested guidelines for developers using JSON Wasn't there also my item about language for representing JSON data structures in other documents? (I presented that at IETF 88, and there seemed to be interest, and Andy Newton also has a version of that.) Barry From cabo@tzi.org Wed Jan 22 07:21: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 49B061A0111 for ; Wed, 22 Jan 2014 07:21:39 -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 jVpdjXlYDD8o for ; Wed, 22 Jan 2014 07:21:38 -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 D12881A010C for ; Wed, 22 Jan 2014 07:21:37 -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 s0MFLOGI000438; Wed, 22 Jan 2014 16:21:24 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E611ABBE; Wed, 22 Jan 2014 16:21:23 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 Jan 2014 16:21:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08ABB7FE-106A-406F-89A2-3290E2639299@tzi.org> References: <52D9B39C.5020102@cisco.com> To: Barry Leiba X-Mailer: Apple Mail (2.1827) Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 15:21:39 -0000 On 22 Jan 2014, at 16:09, Barry Leiba wrote: > Wasn't there also my item about language for representing JSON data > structures in other documents? (I presented that at IETF 88, and there > seemed to be interest, and Andy Newton also has a version of that.) I am certainly interested in exploring that space. Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Wed Jan 22 08:31: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 E92F61A035D for ; Wed, 22 Jan 2014 08:31:50 -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 dM0LCsHtKggS for ; Wed, 22 Jan 2014 08:31:49 -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 B5DE71A0121 for ; Wed, 22 Jan 2014 08:31:49 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MGBTuH096145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 09:11:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 Jan 2014 08:31:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D9B39C.5020102@cisco.com> To: Barry Leiba X-Mailer: Apple Mail (2.1827) Cc: IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 16:31:51 -0000 On Jan 22, 2014, at 7:09 AM, Barry Leiba = wrote: > Wasn't there also my item about language for representing JSON data > structures in other documents? (I presented that at IETF 88, and there > seemed to be interest, and Andy Newton also has a version of that.) That was certainly part of what the second bullet, "- a set of = guidelines for developers who use JSON", was meant to cover. I guess we = were unclear about "developers" being both application developers and = protocol developers". How about: - a set of guidelines for application and protocol developers who use = JSON --Paul Hoffman= From tbray@textuality.com Wed Jan 22 08:32: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 AFB641A00D7 for ; Wed, 22 Jan 2014 08:32:31 -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 aMLOgdIv6brf for ; Wed, 22 Jan 2014 08:32:29 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id B93B61A00A0 for ; Wed, 22 Jan 2014 08:32:29 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id o19so357428vbm.33 for ; Wed, 22 Jan 2014 08:32:29 -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=qItv/G9MqGUabSmtPVDAM6IlNaISUi8+UJu+OZX4SvQ=; b=PFNYqVWc1IaOh1Jl3DStcyNM2Os6aOZ5uAlcV37aIeOJPBuvJBCihQyqA16L5tUcyM AamTebTEXoDLg8IsUhi+Zn6bpIOIi/SnI8pj8eFBVV6266JIx4gVVYiC9iiJUtC3zXCD gsg7dJBa2ybT5jB6qTUnd9o72VOA8gYkK0AN4Z7kBO/qTjNWXx4mSvxVgSVjFKR2LEAw MqQ/hLO7cQEm3S42sMHTJZ4D6K2JCQD0m9nO1HAbkcerymH79XiKRMF7MHyzH0XeAEv+ wvhhJP7/D0e6lWg9JjfkkH7GFYg7J/TeC2IO8zcLKomRHWW40TXvBroqV30KrkOeRDIS +8iA== X-Gm-Message-State: ALoCoQlyN2tECT4bCk7vqc1UsT3MvyI6P8Xlum7/2KAVXkrDCUn1HTpQgBEtEeACajK95PYgGcwq MIME-Version: 1.0 X-Received: by 10.58.106.70 with SMTP id gs6mr1504803veb.28.1390408349027; Wed, 22 Jan 2014 08:32:29 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 22 Jan 2014 08:32:28 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <52D9B39C.5020102@cisco.com> Date: Wed, 22 Jan 2014 08:32:28 -0800 Message-ID: From: Tim Bray To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b6d9904bcb3bc04f091abba Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 16:32:31 -0000 --047d7b6d9904bcb3bc04f091abba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Barry, I think possibly you and I are saying the same thing. What I thought we talked about at IETF88 was a standardized way to refer to the constructs found in JSON texts, to be used by people drafting specs for protocols with JSON payloads. If that=E2=80=99s what you mean by =E2=80= =9Crepresenting JSON data structures in other documents=E2=80=9D, I agree that=E2=80=99s a = better use of WG time than =E2=80=9Cguidelines for developers=E2=80=9D On Wed, Jan 22, 2014 at 7:09 AM, Barry Leiba wrote= : > > Based on our earlier discussions, the Chairs believe the WG has two > > items they want to work on: > > > > - - I-JSON, the current draft of which is draft-bray-i-json-01.txt > > - - Suggested guidelines for developers using JSON > > Wasn't there also my item about language for representing JSON data > structures in other documents? (I presented that at IETF 88, and there > seemed to be interest, and Andy Newton also has a version of that.) > > Barry > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6d9904bcb3bc04f091abba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry, I think possibly you and I are saying the same thin= g. =C2=A0What I thought we talked about at IETF88 was a standardized way to= refer to the constructs found in JSON texts, to be used by people drafting= specs for protocols with JSON payloads. =C2=A0 If that=E2=80=99s what you = mean by =E2=80=9Crepresenting JSON data structures in other documents=E2=80= =9D, I agree that=E2=80=99s a better use of WG time than =E2=80=9Cguideline= s for developers=E2=80=9D


On Wed, Jan 2= 2, 2014 at 7:09 AM, Barry Leiba <barryleiba@computer.org> wrote:
> Based on our earlier = discussions, the Chairs believe the WG has two
> items they want to work on:
>
> - - I-JSON, the current draft of which is draft-bray-i-json-01.txt
> - - Suggested guidelines for developers using JSON

Wasn't there also my item about language for representing JSON da= ta
structures in other documents? (I presented that at IETF 88, and there
seemed to be interest, and Andy Newton also has a version of that.)

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

--047d7b6d9904bcb3bc04f091abba-- From tbray@textuality.com Wed Jan 22 08:35: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 593BD1A035D for ; Wed, 22 Jan 2014 08:35:02 -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 th9IL1qhgqF1 for ; Wed, 22 Jan 2014 08:35:00 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 03BBF1A0128 for ; Wed, 22 Jan 2014 08:34:59 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so373699veb.2 for ; Wed, 22 Jan 2014 08:34:59 -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=KqGxbmtLaLr7p/0z1xQMhyh7rwjAd6yQ6GnvPr10ZIs=; b=lrueUxU8HTm89HgfOzKRfQdZjO3x+ZiQaAl+Z/eEzBMSAAy+Q+AFDecs1KHTmX2TvW mhK/MGSiRw0C8tdUJ1LOd8YZKz+ae8E1gs15YNlRAG2XghQ/SXVV/yaXBoen95I2+/sC SBB7AkPMbAMNHbpWz2Bz+4RS0m3LKvZSAW0tFiTF40vCN45QEuD8CnTbhRWAeD2/4MZK hrF5av6CdsLSTRW4CQwk2sbtfxpgb9r1C9YDSPTJP1M1r6vriaJq8ap8pYlLgQy7Hp+5 zDfXROQ/JGEACw94PYCog/xm9Rnpiizw8NUaBpmFdmBeXizIfMOGPDd2ONKsPW7h4J28 Lmag== X-Gm-Message-State: ALoCoQmr1Wm6dGL5AZJdONzKkl/Y9OqwJL7jmpSzfJTzWY3NhCPCKfb+qignvxVyQ6plviVo/oiW MIME-Version: 1.0 X-Received: by 10.220.88.204 with SMTP id b12mr1472090vcm.3.1390408499353; Wed, 22 Jan 2014 08:34:59 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 22 Jan 2014 08:34:59 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <52D9B39C.5020102@cisco.com> Date: Wed, 22 Jan 2014 08:34:59 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b3a92eeb26dfd04f091b410 Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 16:35:02 -0000 --047d7b3a92eeb26dfd04f091b410 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2014 at 8:31 AM, Paul Hoffman wrote= : > > - a set of guidelines for application and protocol developers who use JSO= N > I still think that=E2=80=99s not what we talked about at IETF 88. I think= Barry and others talked specifically about language for describing JSON constructs for use by protocol developers. I also think that I-JSON, assuming we get consensus, represents =E2=80=9Cguidelines for developers=E2= =80=9D. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b3a92eeb26dfd04f091b410 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 8:31 AM, Paul Hoffman <paul.hoffman@vpnc.org&g= t; wrote:

- a set of guidelines for application and protocol developers who use JSON<= br>

I still think that=E2=80=99s not what w= e talked about at IETF 88. =C2=A0 I think Barry and others talked specifica= lly about language for describing JSON constructs for use by protocol devel= opers. =C2=A0I also think that I-JSON, assuming we get consensus, represent= s =E2=80=9Cguidelines for developers=E2=80=9D.

=C2=A0

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

--047d7b3a92eeb26dfd04f091b410-- From paul.hoffman@vpnc.org Wed Jan 22 11:19: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 732081A03AB for ; Wed, 22 Jan 2014 11:19:53 -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 lmHRwE_q-R1v for ; Wed, 22 Jan 2014 11:19:52 -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 86D451A0141 for ; Wed, 22 Jan 2014 11:19:52 -0800 (PST) Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MIxZ2h001689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 11:59:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 Jan 2014 11:19:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF98EDB-337C-4D1C-83B2-0326B2FDAE94@vpnc.org> References: <52D9B39C.5020102@cisco.com> To: Tim Bray X-Mailer: Apple Mail (2.1827) Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 19:19:53 -0000 On Jan 22, 2014, at 8:34 AM, Tim Bray wrote: > On Wed, Jan 22, 2014 at 8:31 AM, Paul Hoffman = wrote: >=20 > - a set of guidelines for application and protocol developers who use = JSON >=20 > I still think that=92s not what we talked about at IETF 88. I think = Barry and others talked specifically about language for describing JSON = constructs for use by protocol developers. =20 Yes, exactly. I thought that would be part of the above. If there is = better wording to get Barry's point in there, please suggest. > I also think that I-JSON, assuming we get consensus, represents = =93guidelines for developers=94. The current draft isn't a "guideline", it is a specific profile with = MUSTs. --Paul Hoffman= From jhildebr@cisco.com Wed Jan 22 12:45: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 54FD01A01DA for ; Wed, 22 Jan 2014 12:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 4LIvfhu2Zar4 for ; Wed, 22 Jan 2014 12:45:22 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id E49171A01B3 for ; Wed, 22 Jan 2014 12:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=483; q=dns/txt; s=iport; t=1390423521; x=1391633121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SW0dIyXT7l83L/23bkx3cvB57DrRPM4KwRJCWzuQbc4=; b=TSMd1555xMd235Pcv2DRNP79tPj8VJpv8nodirmAta9CdASmuZQxTrvV 1w62TFzDeFQS8zVx1WpKTx9qMxov+b1eXjnDU3V5OAGYFMY3eRcZLFdT/ 0QCZDIrzy1SFwH1nt2ujTTf+z92BJiYBKCdONP6sIR3IDDfAG3TOWm5Qa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOss4FKtJXG9/2dsb2JhbABbgwyBDrtdgRcWdIImAQEEeRACAQgOODIlAgQBDQWIBcNyF45JMweEOAEDiQ+PE5IYgy2CKg X-IronPort-AV: E=Sophos;i="4.95,702,1384300800"; d="scan'208";a="14781659" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 22 Jan 2014 20:45:21 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MKjLLc009834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 20:45:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 14:45:21 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Paul Hoffman Thread-Topic: [Json] Proposed rechartering for the JSON WG Thread-Index: AQHPE9aDSwfdoxagNU6j0iYYmIcg6pqRROaAgAAW2YCAAADxgP//0JiA Date: Wed, 22 Jan 2014 20:45:20 +0000 Message-ID: References: <52D9B39C.5020102@cisco.com> 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.156] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 20:45:23 -0000 On 1/22/14 9:34 AM, "Tim Bray" wrote: >I still think that=B9s not what we talked about at IETF 88. I think Barr= y >and others talked specifically about language for describing JSON >constructs for use by protocol developers. Yes. The way I remembered this was "something like ABNF for JSON-based protocols". >I also think that I-JSON, assuming we get consensus, represents >=B3guidelines > for developers=B2. +1 --=20 Joe Hildebrand From tbray@textuality.com Wed Jan 22 13:06: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 8EC7A1A0472 for ; Wed, 22 Jan 2014 13:06:10 -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 biswsJDMvu5B for ; Wed, 22 Jan 2014 13:06:07 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCB1A0474 for ; Wed, 22 Jan 2014 13:06:05 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so596828veb.0 for ; Wed, 22 Jan 2014 13:06:05 -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=LIK8CM6t9gbVc4gleYohTOu+kfrU39onMjhYvuGkjuU=; b=WReIV3Qjg5l61mK3h28gZnj8Xk02aQ2JKyWnYOIFDJXoEbsiMOOFl7xkASHSseDQav 8afo89MP4JF9KXzDjME96KTWnaZkmvvCZOok9y/k98uL0KwaO1pmgIKEK21JsGHPfxBm 3weCokGEO7440tnSkwlDttfLGDTJ3X1YdeM851+aPjUhdQOqQ2BNS8oS4mUgSAHN/L8u bOnsV4fPreNo/+aloRtlj6ui8Z9H5+SBP7spdzTmGJpjldT3IFlOFKpAKn/8vgMnkkMC wewxDLrzhBkvml1URQluNh5Lvcc2ljF5e3q9FfH/iXcXhbcHnlGcAWCDr0BnUR5ian+S koHg== X-Gm-Message-State: ALoCoQnueNWJVauuwMX5o/R67VdjawXBIgi+/6p6gNTmVcQw+8S37rGvmTrXVQBm+lkDfeU10Atf MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr2446441vcx.1.1390424765199; Wed, 22 Jan 2014 13:06:05 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 22 Jan 2014 13:06:05 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: <7CF98EDB-337C-4D1C-83B2-0326B2FDAE94@vpnc.org> References: <52D9B39C.5020102@cisco.com> <7CF98EDB-337C-4D1C-83B2-0326B2FDAE94@vpnc.org> Date: Wed, 22 Jan 2014 13:06:05 -0800 Message-ID: From: Tim Bray To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2ca0c3788ef04f0957e2d Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 22 Jan 2014 21:06:10 -0000 --001a11c2ca0c3788ef04f0957e2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2014 at 11:19 AM, Paul Hoffman wrote= : > > I also think that I-JSON, assuming we get consensus, represents > =E2=80=9Cguidelines for developers=E2=80=9D. > > The current draft isn't a "guideline", it is a specific profile with MUST= s. > Right. So, the guideline is: =E2=80=9CFor maximum interoperability, specify= the use of I-JSON=E2=80=9D. My concern is that a best-practices doc is going to e= nd up just echoing I-JSON: No dupes, no busted Unicode, no top-level primitives, etc... > > --Paul Hoffman --001a11c2ca0c3788ef04f0957e2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 22, 2014 at 11:19 AM, Paul Hoffman <paul.hoffman@vpnc.org&= gt; wrote:
> I also think that I-J= SON, assuming we get consensus, represents =E2=80=9Cguidelines for develope= rs=E2=80=9D.

The current draft isn't a "guideline", it is a specific= profile with MUSTs.

Right. So, the gui= deline is: =E2=80=9CFor maximum interoperability, specify the use of I-JSON= =E2=80=9D. =C2=A0 My concern is that a best-practices doc is going to end u= p just echoing I-JSON: No dupes, no busted Unicode, no top-level primitives= , etc...

=C2=A0

--Paul Hoffman

--001a11c2ca0c3788ef04f0957e2d-- From odonoghue@isoc.org Wed Jan 22 21:46: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 506D51A016D; Wed, 22 Jan 2014 21:46:09 -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, 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 vU0CQi9MSa0P; Wed, 22 Jan 2014 21:46:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 31C391A003E; Wed, 22 Jan 2014 21:46:07 -0800 (PST) Received: from kodonog-mac.local (74.214.48.55) by DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) with Microsoft SMTP Server (TLS) id 15.0.851.15; Thu, 23 Jan 2014 05:46:05 +0000 Message-ID: <52E0AC98.9090609@isoc.org> Date: Thu, 23 Jan 2014 00:46:00 -0500 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: , , , References: <52E0AB85.1070409@isoc.org> In-Reply-To: <52E0AB85.1070409@isoc.org> X-Forwarded-Message-Id: <52E0AB85.1070409@isoc.org> Content-Type: multipart/alternative; boundary="------------080507020009020703000405" X-Originating-IP: [74.214.48.55] X-ClientProxiedBy: BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) To DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) X-Forefront-PRVS: 0100732B76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(2473001)(199002)(189002)(13464003)(41574002)(56816005)(74366001)(49866001)(59896001)(80316001)(76482001)(77982001)(19580405001)(74706001)(54316002)(85306002)(19580395003)(64126003)(77096001)(56776001)(46102001)(87976001)(47976001)(80976001)(94316002)(50986001)(80022001)(4396001)(47736001)(512934002)(76786001)(92726001)(15202345003)(15975445006)(92566001)(85852003)(93136001)(81542001)(79102001)(74876001)(83072002)(63696002)(33656001)(47446002)(76796001)(69226001)(31966008)(65806001)(54356001)(65956001)(2201001)(81342001)(83506001)(81686001)(42186004)(59766001)(51856001)(84326002)(90146001)(83322001)(66066001)(53806001)(93516002)(74502001)(81816001)(74662001)(71186001)(86362001)(16236675002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR06MB591; H:kodonog-mac.local; CLIP:74.214.48.55; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: isoc.org Subject: [Json] Fwd: WGLC for JWA, JWE, JWK, and JWS 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, 23 Jan 2014 05:46:09 -0000 --------------080507020009020703000405 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit The JOSE WG has started WGLCs on the documents below. We would like to encourage this group to review the specifications as well. You are welcome to either use the issue tracker (http://tools.ietf.org/wg/jose/trac/report/1) or send email to the working group. Thanks! -------- Original Message -------- Subject: WGLC for JWA, JWE, JWK, and JWS Date: Thu, 23 Jan 2014 00:41:25 -0500 From: Karen O'Donoghue To: jose@ietf.org Folks, This message initiates three week WGLCs for the four JOSE WG specifications referenced below: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ Please review and comment on the documents and put any issues in the JOSE WG issue tracker. The WGLC will end on 13 February 2014. Regards, JOSE WG co-chairs --------------080507020009020703000405 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
The JOSE WG has started WGLCs on the documents below. We would like to
encourage this group to review the specifications as well. You are welcome to
either use the issue tracker (http://tools.ietf.org/wg/jose/trac/report/1) or
send email to the working group. Thanks!


-------- Original Message --------
Subject: WGLC for JWA, JWE, JWK, and JWS
Date: Thu, 23 Jan 2014 00:41:25 -0500
From: Karen O'Donoghue <odonoghue@isoc.org>
To: jose@ietf.org <jose@ietf.org> 


Folks,

This message initiates three week WGLCs for the four JOSE WG specifications
referenced below:

https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/

Please review and comment on the documents and put any issues in the
JOSE WG issue tracker. The WGLC will end on 13 February 2014.

Regards,
JOSE WG co-chairs


--------------080507020009020703000405-- From stefan@drees.name Thu Jan 23 01:35: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 63AD91A0385 for ; Thu, 23 Jan 2014 01:35:53 -0800 (PST) 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 5dIV0WBjOVGM for ; Thu, 23 Jan 2014 01:35:52 -0800 (PST) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD8C1A0357 for ; Thu, 23 Jan 2014 01:35:51 -0800 (PST) Received: from newyork.local.box ([93.197.210.97]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0Lp712-1VcSFl3DIS-00epmc for ; Thu, 23 Jan 2014 10:35:49 +0100 Message-ID: <52E0E273.4020802@drees.name> Date: Thu, 23 Jan 2014 10:35:47 +0100 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , Tim Bray , Paul Hoffman References: <52D9B39C.5020102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:oagJNidU+tIY+pDfgerXAyv1dM9TP+f5beI7xy6PrH+aJ1u2Mny X5P8+adiSP4+qYeFq63MT9RHBnuOINya9e1i8R+p4xww8kwpHf7+3Z1nPqlse3cNiSb0e+r ZEViI02qWOdg2csWBsWNb1dcyyLIzErmfjvnWhjUtyrXbi4yHPFEFM+RSaQbWWnKIwiSSEL uRQdvTovzgoOQOd67uU1w== Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 23 Jan 2014 09:35:53 -0000 On 2014-01-22 21:45 +01:00, Joe Hildebrand (jhildebr) wrote: > On 1/22/14 9:34 AM, "Tim Bray" wrote: > >> I still think that¹s not what we talked about at IETF 88. I think Barry >> and others talked specifically about language for describing JSON >> constructs for use by protocol developers. > > Yes. The way I remembered this was "something like ABNF for JSON-based > protocols". I second, that we should aid future specification writers to write ABNF for JSON-based protocols with ease. >> I also think that I-JSON, assuming we get consensus, represents >> ³guidelines >> for developers². > > +1 As I-JSON IMO names everything important (with assumed consensus) in the developer arena, I see no benefit in working on "guidelines for developers", but only disadvantages (as it might cost momentum needed for finding consensus on I-JSON). "Stefan" From jhildebr@cisco.com Thu Jan 23 10:07: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 78FC41A017B for ; Thu, 23 Jan 2014 10:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 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.535, 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 D1Fk9kkEnA-9 for ; Thu, 23 Jan 2014 10:07:45 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 39A3C1A013B for ; Thu, 23 Jan 2014 10:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=498; q=dns/txt; s=iport; t=1390500464; x=1391710064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gvKVdMcgGJ9blMNR5BQUz2BYePro5cDIFYbRWAAyUz8=; b=gxa9ezV3Zvc+7058uOiUzR/0oIJyN/sK8EKZoEVVjLxpLbrkXTZGLn5M OHnlW2ITO2HdzScDLwUb4at+yWP90wxVgW3Vre8LkxzWeCLJo5h4QilHR vDLw9Z95VZBSDGl7aQioh/l3wHgF1oyp67W63epzTbqaOpnv/niXnyE0S w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFACdZ4VKtJV2b/2dsb2JhbABbgwyBDrt7gRMWdIImAQEEOj8QAgEINhAyJQIEAQ0FiAXGBRePAAeEOAEDmCOSGIMtgio X-IronPort-AV: E=Sophos;i="4.95,707,1384300800"; d="scan'208";a="15041524" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 23 Jan 2014 18:07:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0NI7ilG014844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 18:07:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 12:07:44 -0600 From: "Joe Hildebrand (jhildebr)" To: "stefan@drees.name" , Tim Bray , Paul Hoffman Thread-Topic: [Json] Proposed rechartering for the JSON WG Thread-Index: AQHPE9aDSwfdoxagNU6j0iYYmIcg6pqRROaAgAAW2YCAAADxgP//0JiAgAFMnYCAABmuAA== Date: Thu, 23 Jan 2014 18:07:43 +0000 Message-ID: References: <52D9B39C.5020102@cisco.com> <52E0E273.4020802@drees.name> In-Reply-To: <52E0E273.4020802@drees.name> 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.156] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F69C6B52C8DF642BBE4C235B2AC96AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 23 Jan 2014 18:07:50 -0000 On 1/23/14 2:35 AM, "Stefan Drees" wrote: >As I-JSON IMO names everything important (with assumed consensus) in the >developer arena, I see no benefit in working on "guidelines for >developers", but only disadvantages (as it might cost momentum needed >for finding consensus on I-JSON). If there *are* other important considerations for developers that are not currently in I-JSON, we could decide to add them to that document, couldn't we? --=20 Joe Hildebrand From tbray@textuality.com Thu Jan 23 10:59: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 7B6171A00B6 for ; Thu, 23 Jan 2014 10:59:42 -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 q_sChxhcxBwA for ; Thu, 23 Jan 2014 10:59:37 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE91A0234 for ; Thu, 23 Jan 2014 10:58:50 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id jz11so1336998veb.8 for ; Thu, 23 Jan 2014 10:58:49 -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=BuiWB3Zi5nAHvFtIFZi/s/x+785QSfAT2oCdkBYawro=; b=P+TjM8TRFjjN3k+8B3x9BE4hAJtFwOFn0avwFR7KoBiSqNR6JvC3XLNT502tcHO20U INu2SKEch4RwE66xxc4bOOZiFCd4Y9/AlPQUB8KiNTbrC+hi2fuM8GRnXF5HjwJzpSp4 9e8cy/qQv4100aROBwPa4y3CWccx9cj8liyFRrTlbiFOxEpY8S3gMPeCvNdkeVReLDnm mLf/iMsLmeomSQ808MfKCzka1a+KwOdclBylnP9HbUNbEV13hFRx623NpZw4ctWi/Qm3 MW5JfSpdj65FoPlNFWDLMyF3ZpwLvjwkOBoWnM5Odmu9bURLg9NS04pmQQmUgbhMEn14 BmnA== X-Gm-Message-State: ALoCoQmwNfUxSW18HKjf5aXXi4FUlqFuKWDhGSDF1jh4AsvIxJi+yq/WTjFnA6d4kyLtl/k4CQUI MIME-Version: 1.0 X-Received: by 10.58.181.165 with SMTP id dx5mr5150870vec.19.1390503528986; Thu, 23 Jan 2014 10:58:48 -0800 (PST) Received: by 10.220.98.73 with HTTP; Thu, 23 Jan 2014 10:58:48 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <52D9B39C.5020102@cisco.com> <52E0E273.4020802@drees.name> Date: Thu, 23 Jan 2014 10:58:48 -0800 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b673c86e79a4d04f0a7d4fe Cc: Barry Leiba , "stefan@drees.name" , Paul Hoffman , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 23 Jan 2014 18:59:42 -0000 --047d7b673c86e79a4d04f0a7d4fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What Joe said. I think that I-JSON constitutes advice for protocol designers on how to achieve maximum interoperability. That=E2=80=99s an ob= vious 80/20 point and has the virtue of being mechanically verifiable; once you get past it, you get heavily into opinion-space. For example, should your protocol be versioned and where should the version number go? Eek! Here be bikesheds. Perhaps the word =E2=80=9Cnomenclature=E2=80=9D would be useful. Let me tr= y to re-spin Matt=E2=80=99s original draft. I=E2=80=99m also going to take out the relat= ionship-to-XML piece, which adds no useful information. Also, I think JSON was actually originally derived from de-facto JavaScript Object Notation independent of any standardization activity, but whatever. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D 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 published in RFC 4627, an Informational document. JSON has come into very broad use. The JSON WG has already published a standards-track update to RFC 4627. The WG will work on two items: - - a restricted profile of JSON designed to maximize interoperability; the starting point will be draft-bray-i-json. - - a standardized nomenclature for referring to the constructs in a JSON text, for use by those specifying protocols with JSON payloads. On Thu, Jan 23, 2014 at 10:07 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 1/23/14 2:35 AM, "Stefan Drees" wrote: > > >As I-JSON IMO names everything important (with assumed consensus) in the > >developer arena, I see no benefit in working on "guidelines for > >developers", but only disadvantages (as it might cost momentum needed > >for finding consensus on I-JSON). > > If there *are* other important considerations for developers that are not > currently in I-JSON, we could decide to add them to that document, > couldn't we? > > -- > Joe Hildebrand > > > > --047d7b673c86e79a4d04f0a7d4fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What Joe said. =C2=A0I think that I-JSON constitutes advic= e for protocol designers on how to achieve maximum interoperability. =C2=A0= That=E2=80=99s an obvious 80/20 point and has the virtue of being mechanica= lly verifiable; once you get past it, you get heavily into opinion-space. F= or example, should your protocol be versioned and where should the version = number go? =C2=A0Eek! =C2=A0Here be bikesheds.

Perhaps the word =E2=80=9Cnomenclature=E2=80=9D would be use= ful. =C2=A0Let me try to re-spin Matt=E2=80=99s original draft. I=E2=80=99m= also going to take out the relationship-to-XML piece, which adds no useful= information. =C2=A0Also, I think JSON was actually originally derived from= de-facto JavaScript Object Notation independent of any standardization act= ivity, but whatever.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Javascript Object Notation (JSON) is a lightwe= ight, text-based,=C2=A0language-independent data interchange format. It was derived= from the=C2=A0ECMAScript Programming Language Standard and was published in RFC 46= 27,=C2=A0an Informational document. JSON has come into very broad use. The JSON WG <= span style=3D"font-size:13px;font-family:arial,sans-serif">has already publ= ished=C2=A0a standards-track update to RFC 4627.

The WG will work on two it= ems:

- - a restricte= d profile of JSON designed to maximize interoperability;=C2=A0 the starting point = will be draft-bray-i-json.

- - a standardized nomenclature = for referring to the constructs in a JSON text, for use by those specifying= protocols with JSON payloads.


O= n Thu, Jan 23, 2014 at 10:07 AM, Joe Hildebrand (jhildebr) <jhildebr@cisc= o.com> wrote:
On 1/23/14 2:35 AM, "= Stefan Drees" <stefan@drees.na= me> wrote:

>As I-JSON IMO names everything important (with assumed consensus) in th= e
>developer arena, I see no benefit in working on "guidelines for >developers", but only disadvantages (as it might cost momentum nee= ded
>for finding consensus on I-JSON).

If there *are* other important considerations for developers that are= not
currently in I-JSON, we could decide to add them to that document,
couldn't we?

--
Joe Hildebrand




--047d7b673c86e79a4d04f0a7d4fe-- From masinter@adobe.com Thu Jan 23 19:57: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 11ACF1A02D4 for ; Thu, 23 Jan 2014 19:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GKQQByrdFWQu for ; Thu, 23 Jan 2014 19:57:09 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 031701A025B for ; Thu, 23 Jan 2014 19:57:08 -0800 (PST) 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.859.15; Fri, 24 Jan 2014 03:57: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.0859.013; Fri, 24 Jan 2014 03:57:06 +0000 From: Larry Masinter To: Tim Bray , "json@ietf.org" Thread-Topic: media types for i-json profiles Thread-Index: Ac8Yt9SGmcBEPbD+RiiDf+EG4yu3kA== Date: Fri, 24 Jan 2014 03:57:05 +0000 Message-ID: <022f2f7f16ed4e25a1b3cb3162e20f3f@BL2PR02MB307.namprd02.prod.outlook.com> 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: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(189002)(199002)(76176001)(31966008)(63696002)(79102001)(87266001)(76796001)(69226001)(76576001)(81342001)(81542001)(74502001)(74662001)(85306002)(81816001)(47446002)(76786001)(15975445006)(59766001)(54316002)(56776001)(77982001)(19580395003)(65816001)(74706001)(85852003)(83072002)(80022001)(16601075003)(4396001)(47736001)(76482001)(56816005)(19300405004)(53806001)(47976001)(54356001)(49866001)(46102001)(33646001)(51856001)(83322001)(50986001)(86362001)(66066001)(80976001)(2656002)(15202345003)(19609705001)(81686001)(87936001)(92566001)(93136001)(74316001)(74366001)(74876001)(93516002)(90146001)(94316002)(16236675002)(21314002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_022f2f7f16ed4e25a1b3cb3162e20f3fBL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Subject: [Json] media types for i-json profiles 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, 24 Jan 2014 03:57:12 -0000 --_000_022f2f7f16ed4e25a1b3cb3162e20f3fBL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIGFueW9uZSBnaXZlIGEgc2luZ2xlIGNvbmNyZXRlIHVzZSBjYXNlIHdoZXJlIGhhdmluZyB0 d28gbWVkaWEgdHlwZXMNCg0KICAgYXBwbGljYXRpb24vWFhYK2ktanNvbiBhbmQNCiAgIGFwcGxp Y2F0aW9uL1hYWCtqc29uDQoNCm9yIGp1c3QgaGF2aW5nIGJvdGgNCg0KICAgICAgYXBwbGljYXRp b24vanNvbg0KYW5kIGFwcGxpY2F0aW9uL2ktanNvbg0KDQppcyBldmVuIGEgbGl0dGxlIGJpdCB1 c2VmdWwgb3IgdGhlIGRpZmZlcmVuY2Ugc2lnbmlmaWNhbnQ/IFRoZSBvbmx5IHNpdHVhdGlvbnMg SSBjYW4gaW1hZ2luZSAob2gsIHZhbGlkYXRpb24gb2YgaW5wdXQsIHByb2Nlc3NpbmcgdGhlbSBk aWZmZXJlbnRseSwgb3Igc29tZSBndWFyYW50ZWUgb2Yg4oCYc2FmZXR54oCZKSBkb27igJl0IHdv cmsgb3V0IGZvciBtZS4NCg0KDQoNCsOYICByZWNvbW1lbmRpbmcgdGhhdCBwZW9wbGUgd2hvIHNw ZWNpZnkgcHJvdG9jb2xzIGJhc2VkIG9uIGktanNvbiB1c2UgYW4gYXBwbGljYXRpb24vWFhYK2kt anNvbiBtZWRpYSB0eXBlLg0KDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5l dA0KDQoNCg== --_000_022f2f7f16ed4e25a1b3cb3162e20f3fBL2PR02MB307namprd02pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUxMzk0MDk1Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzY2MDQ0Mzc2IDE3 NjAxODUyNTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjojMUY0OTdEO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q2FuIGFueW9uZSBnaXZlIGEgc2luZ2xlIGNvbmNyZXRlIHVzZSBjYXNlIHdoZXJlIGhhdmlu ZyB0d28gbWVkaWEgdHlwZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbi9YWFgm IzQzO2ktanNvbiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IGFwcGxpY2F0aW9uL1hYWCYjNDM7anNvbiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vciBqdXN0IGhhdmlu ZyBib3RoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRp b24vanNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hbmQgYXBwbGljYXRpb24vaS1q c29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5pcyBldmVuIGEgbGl0dGxlIGJpdCB1c2VmdWwgb3IgdGhlIGRpZmZlcmVu Y2Ugc2lnbmlmaWNhbnQ/IFRoZSBvbmx5IHNpdHVhdGlvbnMgSSBjYW4gaW1hZ2luZSAob2gsIHZh bGlkYXRpb24gb2YgaW5wdXQsIHByb2Nlc3NpbmcgdGhlbSBkaWZmZXJlbnRseSwgb3Igc29tZQ0K IGd1YXJhbnRlZSBvZiDigJhzYWZldHnigJkpIGRvbuKAmXQgd29yayBvdXQgZm9yIG1lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+cmVjb21tZW5kaW5nIHRoYXQgcGVvcGxlIHdobyBzcGVjaWZ5IHByb3RvY29scyBi YXNlZCBvbiBpLWpzb24gdXNlIGFuIGFwcGxpY2F0aW9uL1hYWCYjNDM7aS1qc29uIG1lZGlhIHR5 cGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MYXJyeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5o dHRwOi8vbGFycnkubWFzaW50ZXIubmV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_022f2f7f16ed4e25a1b3cb3162e20f3fBL2PR02MB307namprd02pro_-- From masinter@adobe.com Thu Jan 23 20:06: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 838111A0482 for ; Thu, 23 Jan 2014 20:06:44 -0800 (PST) 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 KrVMgDk0mZZa for ; Thu, 23 Jan 2014 20:06:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 65AC41A045D for ; Thu, 23 Jan 2014 20:06:42 -0800 (PST) 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.859.15; Fri, 24 Jan 2014 04:06: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.0859.013; Fri, 24 Jan 2014 04:06:39 +0000 From: Larry Masinter To: "stefan@drees.name" , "Joe Hildebrand (jhildebr)" , Tim Bray , Paul Hoffman Thread-Topic: [Json] Proposed rechartering for the JSON WG Thread-Index: AQHPE9aU+yb6JYkpq0upffcrT0rDtJqQ4FGAgAAW2YCAAADwgIAARfMAgADXQ4CAATO6cA== Date: Fri, 24 Jan 2014 04:06:38 +0000 Message-ID: <48b176306d7b4532ae754298b0b6ae89@BL2PR02MB307.namprd02.prod.outlook.com> References: <52D9B39C.5020102@cisco.com> <52E0E273.4020802@drees.name> In-Reply-To: <52E0E273.4020802@drees.name> 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: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(189002)(199002)(31966008)(63696002)(79102001)(87266001)(76796001)(69226001)(76576001)(81342001)(81542001)(74502001)(74662001)(85306002)(81816001)(47446002)(76786001)(15975445006)(59766001)(54316002)(56776001)(77982001)(19580395003)(65816001)(74706001)(85852003)(83072002)(80022001)(4396001)(47736001)(76482001)(56816005)(53806001)(47976001)(54356001)(49866001)(46102001)(33646001)(51856001)(83322001)(50986001)(86362001)(66066001)(80976001)(2656002)(15202345003)(81686001)(87936001)(92566001)(93136001)(74316001)(74366001)(74876001)(93516002)(90146001)(94316002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Cc: Barry Leiba , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 24 Jan 2014 04:06:44 -0000 With respect to guidelines for using JSON, one model might be BCP 70 / RFC = 3470, "Guidelines for the use of XML within IETF Protocols".=20 You might question the utility of such a document, but RFC 3470 seems to be= reasonably popular in citations from Internet Drafts and a few RFCs here a= nd there. More controversial but also useful would be to point out the considerations= for using JSON vs. alternatives (much as section 3 of RFC 3470 talks about= alternatives to XML). Larry -- http://larry.masinter.net From tbray@textuality.com Thu Jan 23 20:37: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 844EF1A0051 for ; Thu, 23 Jan 2014 20:37:49 -0800 (PST) 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 uvWReTqpXO5S for ; Thu, 23 Jan 2014 20:37:48 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0934F1A002B for ; Thu, 23 Jan 2014 20:37:47 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id p14so1569859vbm.39 for ; Thu, 23 Jan 2014 20:37:46 -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=URD5IskMTTp2w3Kwf4HWOP5I+qPS+IOG3SFkrXPOHpk=; b=JjrmL/i0i7EG2QOrfS0pMBRzW5mcc65UWATCrciGuK/jBINA5Gx3w101qnAfPP+CGJ 0gsNj12zMgZ6pHzxZfywqGBVwgNi/eA+9BjLnhTtFI6Vh6hyXS3HQ7V2CrwvJ3Mglq+d j9Lsc0JYHF7xmmVKfKVaVovf8mZD/oIc7lVrXA77j5NmgjIkRExPbVnO3IkSoiRKHCML NgETmzCNzgXiHhU6+YOgVjyd9XBvQty9yVLkwxRvaKL0HjvStRAr08510j/9XEpzJ4ee vytqkfErG4XLtSwJQbEt0RDVzIxvMmTy5Ix9h3j0wmLrRJbrz1gixaHr4GnSMyUkZrAG 61/A== X-Gm-Message-State: ALoCoQlslznIW2ds4cTlnw3L//mEvKveKyFCM147DpkjOKA+7T2J/LfbQrYggKv8U6c0Sb/wpUdB MIME-Version: 1.0 X-Received: by 10.221.20.199 with SMTP id qp7mr6486497vcb.24.1390538266711; Thu, 23 Jan 2014 20:37:46 -0800 (PST) Received: by 10.220.98.73 with HTTP; Thu, 23 Jan 2014 20:37:46 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <48b176306d7b4532ae754298b0b6ae89@BL2PR02MB307.namprd02.prod.outlook.com> References: <52D9B39C.5020102@cisco.com> <52E0E273.4020802@drees.name> <48b176306d7b4532ae754298b0b6ae89@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 23 Jan 2014 20:37:46 -0800 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=001a11339e2e6f2ac504f0afebd7 Cc: Barry Leiba , "stefan@drees.name" , Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , IETF JSON WG Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 24 Jan 2014 04:37:49 -0000 --001a11339e2e6f2ac504f0afebd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, I just looked through 3470 again, and it=E2=80=99s a fine piece of work= . Having said that, the vast majority of the material there is very specific to XML=E2=80=99s idiosyncracies, and it=E2=80=99s hard to think of what the= corresponding guidance would be in JSON, since JSON is so much simpler. The single exception that struck me was section 4.11, about embedding binary data in an XML document; I can believe that there might be useful guidance for designers of JSON-based protocols that wouldn=E2=80=99t bikesh= ed horribly. I guess the default position would be =E2=80=9CIf you can=E2=80= =99t use separate message bodies with their own media-types, then use base64=E2=80=9D? On Thu, Jan 23, 2014 at 8:06 PM, Larry Masinter wrote: > With respect to guidelines for using JSON, one model might be BCP 70 / RF= C > 3470, "Guidelines for the use of XML within IETF Protocols". > > You might question the utility of such a document, but RFC 3470 seems to > be reasonably popular in citations from Internet Drafts and a few RFCs he= re > and there. > > More controversial but also useful would be to point out the > considerations for using JSON vs. alternatives (much as section 3 of RFC > 3470 talks about alternatives to XML). > > Larry > -- > http://larry.masinter.net > > --001a11339e2e6f2ac504f0afebd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, I just looked through 3470 again, and it=E2=80=99s a f= ine piece of work. =C2=A0Having said that, the vast majority of the materia= l there is very specific to XML=E2=80=99s idiosyncracies, and it=E2=80=99s = hard to think of what the corresponding guidance would be in JSON, since JS= ON is so much simpler. =C2=A0

The single exception that struck me was section 4.11, about = embedding binary data in an XML document; I can believe that there might be= useful guidance for designers of JSON-based protocols that wouldn=E2=80=99= t bikeshed horribly. =C2=A0I guess the default position would be =E2=80=9CI= f you can=E2=80=99t use separate message bodies with their own media-types,= then use base64=E2=80=9D?




On Thu, Jan 23, 2014 at 8:06 PM, Larry Masinter <m= asinter@adobe.com> wrote:
With respect to guidelines for using JSON, o= ne model might be BCP 70 / RFC 3470, "Guidelines for the use of XML wi= thin IETF Protocols".

You might question the utility of such a document, but RFC 3470 seems to be= reasonably popular in citations from Internet Drafts and a few RFCs here a= nd there.

More controversial but also useful would be to point out the considerations= for using JSON vs. alternatives (much as section 3 of RFC 3470 talks about= alternatives to XML).

Larry
--
http://larry.masint= er.net


--001a11339e2e6f2ac504f0afebd7-- From duerst@it.aoyama.ac.jp Thu Jan 23 22:40: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 7CB141A012A for ; Thu, 23 Jan 2014 22:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 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.535] 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 KkPqfCv5b4AE for ; Thu, 23 Jan 2014 22:40:39 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE91A010B for ; Thu, 23 Jan 2014 22:40:38 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0O6eYZk008627; Fri, 24 Jan 2014 15:40:34 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 61c3_2a63_6d4c736a_84c2_11e3_8346_001e6722eec2; Fri, 24 Jan 2014 15:40:33 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AC583BF54C; Fri, 24 Jan 2014 15:40:33 +0900 (JST) Message-ID: <52E20AD0.3060901@it.aoyama.ac.jp> Date: Fri, 24 Jan 2014 15:40:16 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Larry Masinter References: <022f2f7f16ed4e25a1b3cb3162e20f3f@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <022f2f7f16ed4e25a1b3cb3162e20f3f@BL2PR02MB307.namprd02.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] media types for i-json profiles 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, 24 Jan 2014 06:40:41 -0000 Fully agreed. I tried to say the same thing in http://www.ietf.org/mail-archive/web/json/current/msg02373.html. Regards, Martin. On 2014/01/24 12:57, Larry Masinter wrote: > Can anyone give a single concrete use case where having two media types > > application/XXX+i-json and > application/XXX+json > > or just having both > > application/json > and application/i-json > > is even a little bit useful or the difference significant? The only sit= uations I can imagine (oh, validation of input, processing them different= ly, or some guarantee of =E2=80=98safety=E2=80=99) don=E2=80=99t work out= for me. > > > > =C3=98 recommending that people who specify protocols based on i-json = use an application/XXX+i-json media type. > > > Larry > -- > http://larry.masinter.net > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From duerst@it.aoyama.ac.jp Thu Jan 23 22:47: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 A83E11A010B for ; Thu, 23 Jan 2014 22:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 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.535] 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 5j351fMXoJM2 for ; Thu, 23 Jan 2014 22:47:51 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9381A00EA for ; Thu, 23 Jan 2014 22:47:51 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0O6lS34013528; Fri, 24 Jan 2014 15:47:28 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 61c3_30f5_6400299a_84c3_11e3_8346_001e6722eec2; Fri, 24 Jan 2014 15:47:27 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 97AF3BF54C; Fri, 24 Jan 2014 15:47:27 +0900 (JST) Message-ID: <52E20C6E.1030000@it.aoyama.ac.jp> Date: Fri, 24 Jan 2014 15:47:10 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <52D9B39C.5020102@cisco.com> <52E0E273.4020802@drees.name> <48b176306d7b4532ae754298b0b6ae89@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "stefan@drees.name" , Paul Hoffman , Larry Masinter , IETF JSON WG , "Joe Hildebrand \(jhildebr\)" , Barry Leiba Subject: Re: [Json] Proposed rechartering for the JSON WG 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, 24 Jan 2014 06:47:52 -0000 On 2014/01/24 13:37, Tim Bray wrote: > Hm, I just looked through 3470 again, and it=E2=80=99s a fine piece of = work. > Having said that, the vast majority of the material there is very spe= cific > to XML=E2=80=99s idiosyncracies, and it=E2=80=99s hard to think of what= the corresponding > guidance would be in JSON, since JSON is so much simpler. Well, one important point may be that because it's so simple, it invites=20 people to invent things on top of it. People try to invent conventions=20 for comments, convents for encoding textual markup (where in most cases=20 XML would be the better solution), and so on. Some of the ways of doing such things make sense in some situations, but=20 in other situations, or done other ways, or also just in general, may=20 not make much sense, and a document could point this out. Regards, Martin. > The single exception that struck me was section 4.11, about embedding > binary data in an XML document; I can believe that there might be usefu= l > guidance for designers of JSON-based protocols that wouldn=E2=80=99t bi= keshed > horribly. I guess the default position would be =E2=80=9CIf you can=E2= =80=99t use separate > message bodies with their own media-types, then use base64=E2=80=9D? From James.H.Manger@team.telstra.com Fri Jan 24 04:29: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 D90AD1A02E7 for ; Fri, 24 Jan 2014 04:29:55 -0800 (PST) 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 adFW_MdBMiAd for ; Fri, 24 Jan 2014 04:29:54 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id C0B7F1A027A for ; Fri, 24 Jan 2014 04:29:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,712,1384261200"; d="scan'208";a="190004518" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 24 Jan 2014 23:29:50 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7327"; a="247102381" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcavi.tcif.telstra.com.au with ESMTP; 24 Jan 2014 23:29:37 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 24 Jan 2014 23:29:28 +1100 From: "Manger, James" To: Larry Masinter , Tim Bray , "json@ietf.org" Date: Fri, 24 Jan 2014 23:29:25 +1100 Thread-Topic: media types for i-json profiles Thread-Index: Ac8Yt9SGmcBEPbD+RiiDf+EG4yu3kAAREvBg Message-ID: <255B9BB34FB7D647A506DC292726F6E11538595765@WSMSG3153V.srv.dir.telstra.com> References: <022f2f7f16ed4e25a1b3cb3162e20f3f@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <022f2f7f16ed4e25a1b3cb3162e20f3f@BL2PR02MB307.namprd02.prod.outlook.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] media types for i-json profiles 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, 24 Jan 2014 12:29:56 -0000 PiBDYW4gYW55b25lIGdpdmUgYSBzaW5nbGUgY29uY3JldGUgdXNlIGNhc2Ugd2hlcmUgaGF2aW5n IHR3byBtZWRpYSB0eXBlcw0KPiANCj4gwqDCoCBhcHBsaWNhdGlvbi9YWFgraS1qc29uIGFuZA0K PiDCoMKgIGFwcGxpY2F0aW9uL1hYWCtqc29uDQo+IA0KPiBvciBqdXN0IGhhdmluZyBib3RoDQo+ IA0KPiDCoMKgwqDCoMKgIGFwcGxpY2F0aW9uL2pzb24NCj4gYW5kIGFwcGxpY2F0aW9uL2ktanNv bg0KPiANCj4gaXMgZXZlbiBhIGxpdHRsZSBiaXQgdXNlZnVsIG9yIHRoZSBkaWZmZXJlbmNlIHNp Z25pZmljYW50PyBUaGUgb25seQ0KPiBzaXR1YXRpb25zIEkgY2FuIGltYWdpbmUgKG9oLCB2YWxp ZGF0aW9uIG9mIGlucHV0LCBwcm9jZXNzaW5nIHRoZW0NCj4gZGlmZmVyZW50bHksIG9yIHNvbWUg Z3VhcmFudGVlIG9mIOKAmHNhZmV0eeKAmSkgZG9u4oCZdCB3b3JrIG91dCBmb3IgbWUuDQo+IA0K PiANCj4g4p6iwqAgcmVjb21tZW5kaW5nIHRoYXQgcGVvcGxlIHdobyBzcGVjaWZ5IHByb3RvY29s cyBiYXNlZCBvbiBpLWpzb24gdXNlDQo+IGFuIGFwcGxpY2F0aW9uL1hYWCtpLWpzb24gbWVkaWEg dHlwZS4NCj4gDQo+IA0KPiBMYXJyeQ0KPiAtLQ0KPiBodHRwOi8vbGFycnkubWFzaW50ZXIubmV0 DQoNCg0KTm8uIFRoZXJlIGlzIG5vIHJlYXNvbiB0byBoYXZlIGFwcGxpY2F0aW9uL1hYWCtpLWpz b24gYW5kIGFwcGxpY2F0aW9uL1hYWCtqc29uLg0KQnV0IGRyYWZ0LWJyYXktaS1qc29uLTAxIG5v IGxvbmdlciBzdWdnZXN0cyB0aGF0Lg0KSXQgZG9lcyBub3QgZGVmaW5lIGFwcGxpY2F0aW9uL2kt anNvbi4NCkl0IHJlY29tbWVuZHMgdGhhdCBuZXcgcHJvdG9jb2xzIGRlZmluZSBhbiBhcHBsaWNh dGlvbi9YWFgraS1qc29uIG1lZGlhIHR5cGUsIHByZXN1bWFibHkgKmluc3RlYWQgb2YqIGFuIGFw cGxpY2F0aW9uL1hYWCtqc29uIG9uZSAobm90IGluIGFkZGl0aW9uIHRvIGl0KS4NCg0KSXQgd291 bGQgaGVscCB0byBiZSBqdXN0IGEgYml0IGNsZWFyZXIgdGhhdCBhIG5ldyBtZXNzYWdlIHNwZWMg dGhhdCBuZWVkcyBhIG5ldyBtZWRpYSB0eXBlIFNIT1VMRCBjaG9vc2Ugb25lIG9mIHRoZSBmb3Jt IGFwcGxpY2F0aW9uL1hYWCtpLWpzb24sIGJ1dCBtZXNzYWdlcyB0aGF0IGFscmVhZHkgaGF2ZSBt ZWRpYSB0eXBlcyBkbyBub3QgbmVlZCBuZXcgb25lcy4gSW4gcGFydGljdWxhciwgYXBwbGljYXRp b24vWFhYK2ktanNvbiBTSE9VTEQgTk9UIGJlIGRlZmluZWQgaWYgYXBwbGljYXRpb24vWFhYK2pz b24gaXMgYWxyZWFkeSBkZWZpbmVkIGZvciB0aGUgc2FtZSBtZXNzYWdlcy4NCg0KSSB3b3VsZCBz dGlsbCBwcmVmZXIgdG8gZHJvcCBhcHBsaWNhdGlvbi9YWFgraS1qc29uIGFsbCB0b2dldGhlci4N Cg0KLS0NCkphbWVzIE1hbmdlcg0K From hallam@gmail.com Fri Jan 24 13:50: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 4C1A61A00C2 for ; Fri, 24 Jan 2014 13:50:24 -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 Lr5WcKrWIRLo for ; Fri, 24 Jan 2014 13:50:23 -0800 (PST) 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 9B8E81A013C for ; Fri, 24 Jan 2014 13:50:22 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so2959520lab.20 for ; Fri, 24 Jan 2014 13:50:20 -0800 (PST) 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=Em5XULrqAkIEwlilTGGvvFWjjW2zdIDXHAxC1vdca7E=; b=Lj3oIllXt2F8stS9F+ClSOxINiALUXMdyRnMJTjxNjeKyaS8VV1Abu/rdJZph/ifx3 dBXnMooBWgFUuvobc1ik7tW0B45m2wANBtzCj1/chex30S0Z6W5e8kxwWoNAhSe5a1ZG 4cO2CqCWiNN4lHoGpFY3SdP5VejWCqIgW6DjegmejiidhNyM6zZprNkK2etr6ynRdqGm +H4M6OExb1QTIcKEQu2OlUj395oZa+oT1L79xtw+uBMWRYiD1Zx3UUnrCy/h6cNjLQ7e 6Gn8DVP6MjLMTwgPo/JWrrgcAuegoSp+uvLbzs3JnLpVp/g/cND4Xqm6MMtXdD9oz5GM 8skA== MIME-Version: 1.0 X-Received: by 10.112.45.108 with SMTP id l12mr9912427lbm.21.1390600220613; Fri, 24 Jan 2014 13:50:20 -0800 (PST) Received: by 10.112.37.172 with HTTP; Fri, 24 Jan 2014 13:50:20 -0800 (PST) Date: Fri, 24 Jan 2014 16:50:20 -0500 Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=001a1134bfc82ca38504f0be58a3 Subject: [Json] Sensible limits for tags 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, 24 Jan 2014 21:50:24 -0000 --001a1134bfc82ca38504f0be58a3 Content-Type: text/plain; charset=ISO-8859-1 I am just working on converting my JSON parser / schema package to C. One major change in moving to C is that there is no string package and so managing infinitely extensible strings becomes a lot more expensive than for C#. I am considering putting limits on the lengths of tags. Setting the max tag length to 255 octets improves efficiency and 'should be sufficient for anyone'. (insert 640 byte joke here). Since I only support UTF8 encoding (anyone needing another encoding can convert externally) this would support 128 Unicode characters which seems generous. Has anyone come up against this before and come up with a particular limit? -- Website: http://hallambaker.com/ --001a1134bfc82ca38504f0be58a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am just working on converting my JSON parser / schema pa= ckage to C.

One major change in moving to C is that ther= e is no string package and so managing infinitely extensible strings become= s a lot more expensive than for C#.

I am considering putting limits on the lengths of tags.= Setting the max tag length to 255 octets improves efficiency and 'shou= ld be sufficient for anyone'. (insert 640 byte joke here).=A0

Since I only support UTF8 encoding (anyone needing another e= ncoding can convert externally) this would support 128 Unicode characters w= hich seems generous.


Has anyone com= e up against this before and come up with a particular limit?
--001a1134bfc82ca38504f0be58a3-- From cowan@ccil.org Fri Jan 24 14:49: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 943271A01E8 for ; Fri, 24 Jan 2014 14:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 vR4DNd5GmgPS for ; Fri, 24 Jan 2014 14:49:25 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CEDB41A01E5 for ; Fri, 24 Jan 2014 14:49:25 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1W6pYx-0001qC-GG; Fri, 24 Jan 2014 17:49:23 -0500 Date: Fri, 24 Jan 2014 17:49:23 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140124224923.GC19502@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 Cc: JSON WG Subject: Re: [Json] Sensible limits for tags 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, 24 Jan 2014 22:49:27 -0000 Phillip Hallam-Baker scripsit: > Since I only support UTF8 encoding (anyone needing another encoding can > convert externally) this would support 128 Unicode characters which seems > generous. 255 bytes supports, worst-case, 63 Unicode codepoints, if none of them are in the range U+0000 to U+FFFF (unlikely, but someone may want names entirely in Gothic). -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe From duerst@it.aoyama.ac.jp Fri Jan 24 22:49: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 57FF81A012A for ; Fri, 24 Jan 2014 22:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 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.535] 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 O4TKdZ5RLklS for ; Fri, 24 Jan 2014 22:49:49 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA2B1A0129 for ; Fri, 24 Jan 2014 22:49:48 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0P6nicD005758; Sat, 25 Jan 2014 15:49:44 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 61c6_0e85_df878eea_858c_11e3_b9e3_001e6722eec2; Sat, 25 Jan 2014 15:49:44 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A4FA5BF54F; Sat, 25 Jan 2014 15:49:43 +0900 (JST) Message-ID: <52E35E6C.4070306@it.aoyama.ac.jp> Date: Sat, 25 Jan 2014 15:49:16 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: JSON WG Subject: Re: [Json] Sensible limits for tags 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, 25 Jan 2014 06:49:51 -0000 On 2014/01/25 6:50, Phillip Hallam-Baker wrote: > I am just working on converting my JSON parser / schema package to C. First, I'd only do that with really strong reasons, but I'd guess you have been through that already. > One major change in moving to C is that there is no string package It's just a wild guess, but I'd think there should be such packages somewhere out there. and so > managing infinitely extensible strings becomes a lot more expensive than > for C#. In terms of programmer effort, definitely. > I am considering putting limits on the lengths of tags. Setting the max tag > length to 255 octets improves efficiency and 'should be sufficient for > anyone'. (insert 640 byte joke here). Any such limit (even a lower one or a higher one) is going to work until it fails some day. At that point, it will become apparent that you implementation is simply not conforming. I'd not go with a fully variable implementation, but use a fixed length (possibly shorter than 255 bytes) for efficiency in the general case, and something extensible for the exceptions. > Since I only support UTF8 encoding (anyone needing another encoding can > convert externally) this would support 128 Unicode characters which seems > generous. John already corrected this. It would be 255 ASCII only, 127 Cyrillic/Arabic/Greek/Hebrew,..., 85 for all Indic Scripts, Thai,..., and CJK. > Has anyone come up against this before and come up with a particular limit? No, I didn't. Long names should be really rare (a really thin long tail :-), but they can't be excluded. Regards, Martin. From derhoermi@gmx.net Sat Jan 25 05:14: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 B01A61A02EE for ; Sat, 25 Jan 2014 05:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 i7ajmbkrDM9g for ; Sat, 25 Jan 2014 05:14:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D02EC1A02EA for ; Sat, 25 Jan 2014 05:14:13 -0800 (PST) Received: from netb.Speedport_W_700V ([84.180.231.225]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LbxQO-1VPz0B1Jci-00jI8T for ; Sat, 25 Jan 2014 14:14:11 +0100 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Sat, 25 Jan 2014 14:14:18 +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:FRWs2ftdG00EH9xPsI7WyFngkDB8LbdhAWLZTRTvJaAWACDy1fs BzBnWusyoIlSd65BZVC/UliGRRSD4FlbZ9/CIDdIrtHZk+faFzg7miK4xVzB5Qf0RYCT1kz i8Z9bFFyrA/gpLFu/D+Q8GSsp7iUBKS2oY4Cw1cOUjZmj4un6n6np0VkTdPgP7SiXeg63um PNIWp1466Uw6K2hypOWyA== Cc: JSON WG Subject: Re: [Json] Sensible limits for tags 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, 25 Jan 2014 13:14:16 -0000 * Phillip Hallam-Baker wrote: >I am just working on converting my JSON parser / schema package to C. > >One major change in moving to C is that there is no string package and so >managing infinitely extensible strings becomes a lot more expensive than >for C#. > >I am considering putting limits on the lengths of tags. Setting the max tag >length to 255 octets improves efficiency and 'should be sufficient for >anyone'. (insert 640 byte joke here). > >Since I only support UTF8 encoding (anyone needing another encoding can >convert externally) this would support 128 Unicode characters which seems >generous. > >Has anyone come up against this before and come up with a particular limit? It is very common to have arbitrarily long strings as keys in objects in JSON documents especially when they don't come from a finite enumeration of pre-defined keys. As a trivial example, take `sort | uniq -c` which would create a histogram for repeated lines, and it would be natural to represent the lines as object keys in JSON, and frequencies as values. And it is obviously common that lines of text exceed 255 UTF-8 octets, like when paragraphs are not hard-wrapped. I would regard anything below 64KB as a joke in a general-purpose parser. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cowan@ccil.org Sat Jan 25 16:23: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 814751A00BB for ; Sat, 25 Jan 2014 16:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 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.535] 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 Tl1h-Mv1PlE2 for ; Sat, 25 Jan 2014 16:23:37 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEC81A00BA for ; Sat, 25 Jan 2014 16:23:36 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1W7DVb-0000wr-My; Sat, 25 Jan 2014 19:23:31 -0500 Date: Sat, 25 Jan 2014 19:23:31 -0500 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20140126002331.GB12402@mercury.ccil.org> References: <52E35E6C.4070306@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: <52E35E6C.4070306@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Sensible limits for tags 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, 26 Jan 2014 00:23:39 -0000 "Martin J. Dürst" scripsit: > Any such limit (even a lower one or a higher one) is going to work > until it fails some day. At that point, it will become apparent that > you implementation is simply not conforming. It is in fact conforming, thanks to the escape in Section 4 that allows implementations to set limits on things. Indeed, no implementations exist that allow *unlimited* strings. > I'd not go with a fully variable implementation, but use a fixed > length (possibly shorter than 255 bytes) for efficiency in the > general case, and something extensible for the exceptions. Fixed 255 length would be very wasteful. I think the implication is that counted strings are being used, with one-byte counts. -- An observable characteristic is not necessarily John Cowan a functional requirement. --John Hudson cowan@ccil.org From prvs=0096fa7df1=johnl@iecc.com Sat Jan 25 18:23: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 3879E1A00D2 for ; Sat, 25 Jan 2014 18:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 cgqSc5uS96gy for ; Sat, 25 Jan 2014 18:23:41 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 373731A00CD for ; Sat, 25 Jan 2014 18:23:40 -0800 (PST) Received: (qmail 86316 invoked from network); 26 Jan 2014 02:23:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Jan 2014 02:23:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52e471aa.xn--yuvv84g.k1401; i=johnl@user.iecc.com; bh=r+rRygdIk93pToHb19x5objinahfHNWIkJv8d/FdjXU=; b=Zhk4rbhIoEZTYNyaZuVmtTF+Ku+SE/prbo08S34PROQxhDuvJoNw4IATvN1pExd+oEiYEbZgBZRv61Mtx/6F5SreHr+eIYeeVdFvQVcEZ0CSM80ngX+9zi7tBW+bt2zWk9UUAGh/gogtImJzq9eCA7t0KyGzKY9x7rCca1xiOTH1EzunufTzjXe20kI3eohMzj/QE033S+I0eu35XCOY1acnHympBo2FgxdR7lwtCVKrhyHRYOs1G4RA/ZYgc6ED DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52e471aa.xn--yuvv84g.k1401; olt=johnl@user.iecc.com; bh=r+rRygdIk93pToHb19x5objinahfHNWIkJv8d/FdjXU=; b=o+7rwuq7kcBW4yaScYxSGtzWyT/r+jzSOqUlIlOIN47Niq1EjNExjKFzRRlZre7xO7KzRwbRrVRt6fJq4iPzkHw2O4SMNJ0+CSsWsl2ar82dtG0H2a0NE00bP8d5tvhKHDrfeu7bXky1A88FRZTDs7xS1+kyM+Q/iLXctOSIeVdvt4lFhzgMWFaqbrKkWxgg5QVGBfNbOYm2Z4z/RXsKtnimwswuBlG/jRLszXuDbsvnBNgzYdyfBxWj1pON0hKR Date: 26 Jan 2014 02:23:16 -0000 Message-ID: <20140126022316.95232.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <52E35E6C.4070306@it.aoyama.ac.jp> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: duerst@it.aoyama.ac.jp Subject: Re: [Json] Sensible limits for tags 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, 26 Jan 2014 02:23:43 -0000 >> One major change in moving to C is that there is no string package > >It's just a wild guess, but I'd think there should be such packages >somewhere out there. There are a gazillion packages for counted dynamically allocated strings. Some are quite good. The problem is that none of them are in the standard C or POSIX libraries, so you can't count on having any of them available. R's, John From hallam@gmail.com Sat Jan 25 19:15: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 83DA51A00DF for ; Sat, 25 Jan 2014 19:15:30 -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 cYz-EU7I-cj0 for ; Sat, 25 Jan 2014 19:15:28 -0800 (PST) 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 CB0681A00DD for ; Sat, 25 Jan 2014 19:15:27 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id c6so3632207lan.11 for ; Sat, 25 Jan 2014 19:15:25 -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=6EaqDeuK+t3nxiQrNaZff5i/1B7D16YE1Jiu+o00ddQ=; b=I/Yi0ln4pwRi5KuLl7J3S6r1ZHVpxHOzZXSkq4gvt8c5ZYe6MCBvR+lfFQu4lJhemO YaeQ5rgkAh76RplrIECJZ8bsrc7cnML14oAyFhVPmc34DdcrCaj03dquS3KUtK/EsPeI YlnOjNCnXrBCPOGysFiYT3KoU78gZWz6guhd0vpBm8bE6917BYC0xNVp6cg+3/oJUdvL TLJRna8LiFCFh/MTMgjbxRz1VwRlHgv+SQA80dL7yw4zoanDy+fJAhnD4JuscOhiGUAN rsH/JCyk/EsJh10nF3CX7occVfhfJkrI4W/KVzZgDmSVFIPKWKPGf+/jcGOASiH0c5KH LEjQ== MIME-Version: 1.0 X-Received: by 10.152.2.5 with SMTP id 5mr13599976laq.21.1390706125451; Sat, 25 Jan 2014 19:15:25 -0800 (PST) Received: by 10.112.37.168 with HTTP; Sat, 25 Jan 2014 19:15:25 -0800 (PST) In-Reply-To: <20140126022316.95232.qmail@joyce.lan> References: <52E35E6C.4070306@it.aoyama.ac.jp> <20140126022316.95232.qmail@joyce.lan> Date: Sat, 25 Jan 2014 22:15:25 -0500 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=089e013c664098381304f0d7008f Cc: =?ISO-8859-1?Q?Martin_D=FCrst?= , JSON WG Subject: Re: [Json] Sensible limits for tags 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, 26 Jan 2014 03:15:30 -0000 --089e013c664098381304f0d7008f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 25, 2014 at 9:23 PM, John Levine wrote: > >> One major change in moving to C is that there is no string package > > > >It's just a wild guess, but I'd think there should be such packages > >somewhere out there. > > There are a gazillion packages for counted dynamically allocated > strings. Some are quite good. The problem is that none of them are > in the standard C or POSIX libraries, so you can't count on having any > of them available. > Precisely. I would be very happy if the C world could detach itself from the C++ world and define a set of simple libraries for lists, bound checked array and strings. I don't ever want C++ because the last thing I need is a badly designed object system when I can choose C# or Java or possibly even the Google scheme on its way. Looking at most C packages, they typically come with their own memory management and string handling schemes. Which means that when you have three or four packages, there is redundancy and inconsistency. Anyway, I came up with a solution that should suffice. If the labels grow over 256 bytes I just feed them into SHA256 and thats done with them. One reason I am rolling my own is that I am writing crypto code and none of the libraries I have looked at is appropriate. Shotgun parsing isn't acceptable in security code. The rule is that you first check the integrity of the bits received, iff and only iff they are correct you put the checked bits and only the checked bits through the parser and then the code works on the parsed data and only the parsed data. So the parser needs to be schema driven and the decoded structures synced to the schema. One of the advantages of JSON is that it avoids some of the security problems that most IETF protocols have managed to create because it does not have nested definite length delimited structures. -- Website: http://hallambaker.com/ --089e013c664098381304f0d7008f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 25, 2014 at 9:23 PM, John Levine <johnl@taugh.com> wro= te:
>> One major change in moving to C is that there is= no string package
>
>It's just a wild guess, but I'd think there should be such pack= ages
>somewhere out there.

There are a gazillion packages for counted dynamically allocated
strings. =A0Some are quite good. =A0The problem is that none of them are in the standard C or POSIX libraries, so you can't count on having any<= br> of them available.

Precisely.

I would be very happy if the C world could detach itself fr= om the C++ world and define a set of simple libraries for lists, bound chec= ked array and strings.

I don't ever want C++ because the last thing I need= is a badly designed object system when I can choose C# or Java or possibly= even the Google scheme on its way.=A0

Looki= ng at most C packages, they typically come with their own memory management= and string handling schemes. Which means that when you have three or four = packages, there is redundancy and inconsistency.


Anyway, I came up with a solution that s= hould suffice. If the labels grow over 256 bytes I just feed them into SHA2= 56 and thats done with them.

One reason I am rolli= ng my own is that I am writing crypto code and none of the libraries I have= looked at is appropriate. Shotgun parsing isn't acceptable in security= code. The rule is that you first check the integrity of the bits received,= iff and only iff they are correct you put the checked bits and only the ch= ecked bits through the parser and then the code works on the parsed data an= d only the parsed data.

So the parser needs to be schema driven and the decoded= structures synced to the schema.


O= ne of the advantages of JSON is that it avoids some of the security problem= s that most IETF protocols have managed to create because it does not have = nested definite length delimited structures.=A0


--
Website: http://hallambaker.com/
--089e013c664098381304f0d7008f-- From sgbeal@googlemail.com Sun Jan 26 01:06: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 977EF1A011C for ; Sun, 26 Jan 2014 01:06:48 -0800 (PST) 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 AWYniDcK_te3 for ; Sun, 26 Jan 2014 01:06:46 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC91A0118 for ; Sun, 26 Jan 2014 01:06:46 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so4794064pab.5 for ; Sun, 26 Jan 2014 01:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xBgnMQYe8fhb+K2kdsk3/+AGqgr4AaX/BuyEJk95dbE=; b=SO/w3ZJibY00gA2jknnagXqir3brAhaWoXyB3ilQGNivo6//zniGY5fvKrWyW4R7kS jtvJZJq+Acsbv1CAh5GOHcidzgy5TyGdBxyMJ+4A/ZgIF1ctXXwW7FPkiFAXQTF0YCX2 k5j+22GBzR/xt46ead0zdiiuzeqP4lo3/F0FNwIuWQyYal3ZRcgcFOLMSiqe18iGRSSD edegAUiBC4xKlsRJl3GlXpl95Q9M2hjiuxQt3PbwDzjangEAm7Ucxo9DD4UFyXUDH6bi oGLJxikiryQMybJkf2kHeGMeq8kdLZlyE/qSKQswDRiQu/aj8UDtwCf3GbblvNLqnVbI RSMQ== MIME-Version: 1.0 X-Received: by 10.68.241.134 with SMTP id wi6mr23833118pbc.44.1390727204965; Sun, 26 Jan 2014 01:06:44 -0800 (PST) Received: by 10.68.229.193 with HTTP; Sun, 26 Jan 2014 01:06:44 -0800 (PST) In-Reply-To: <20140126022316.95232.qmail@joyce.lan> References: <52E35E6C.4070306@it.aoyama.ac.jp> <20140126022316.95232.qmail@joyce.lan> Date: Sun, 26 Jan 2014 10:06:44 +0100 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b339be708158504f0dbe9a1 Subject: Re: [Json] Sensible limits for tags 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, 26 Jan 2014 09:06:48 -0000 --047d7b339be708158504f0dbe9a1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 26, 2014 at 3:23 AM, John Levine wrote: > There are a gazillion packages for counted dynamically allocated > strings. Some are quite good. The problem is that none of them are > in the standard C or POSIX libraries, so you can't count on having any > of them available. > The C JSON libs i've looked at or written tend to provide their own String struct wrapper, not because the world needs yet another String struct for C, but because it's the only portable way to do it in C without pulling in 3rd-party libs. In the off chance that this is of any help to the original poster, mine looks like this: struct json_string { unsigned int length; }; Notice that there is no (char *). The struct instances can be allocated with N (==strlen) +1 (NUL) extra bytes and that can be used to store the string bytes: json_string * json_string_new(char const * src, unsigned int n); An accessor function can be used to fetch the contents. Mine looks something like (eliding the special-case optimization for zero-length strings): char const * json_string_cstr(json_string const * js){ return (char const *)(js+1); } char const * json_string_cstr2(json_string const * js, unsigned int * len ){ if(len) *len = js->length; return (char const *)(js+1); } and the public API provides no mechanism for modifying them. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf --047d7b339be708158504f0dbe9a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 26, 2014 at 3:23 AM, John Levine <johnl@taugh.com> wro= te:
There are a gazillion packages for counted dynamically allocated
strings. =A0Some are quite good. =A0The problem is that none of them are in the standard C or POSIX libraries, so you can't count on having any<= br> of them available.


The C= JSON libs i've looked at or written tend to provide their own String s= truct wrapper, not because the world needs yet another String struct for C,= but because it's the only portable way to do it in C without pulling i= n 3rd-party libs.

In the off chance that this is of any help to the origi= nal poster, mine looks like this:

struct json_stri= ng {
=A0 =A0 unsigned int length;
};

Notice that there is no (char *). The struct instances can be allocate= d with N (=3D=3Dstrlen) +1 (NUL) extra bytes and that can be used to store = the string bytes:

json_string * json_string_new(ch= ar const * src, unsigned int n);

An accessor function can be used to fetch the contents.= Mine looks something like (eliding the special-case optimization for zero-= length strings):

char const * json_string_cstr(jso= n_string const * js){
=A0 =A0 return (char const *)(js+1);
}

<= div>
char const * json_string_cstr2(json_string const * js, unsigned in= t * len ){
=A0 =A0 if(len) *len =3D js->length;
=A0 = =A0 return (char const *)(js+1);
}

and the public API provides no mechan= ism for modifying them.

--
-= ---- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only gu= aranteed byproduct of those who insist on a perfect world, freedom will hav= e to do." -- Bigby Wolf
--047d7b339be708158504f0dbe9a1--