From nobody Mon Jan 5 14:04:11 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037F21A8F50 for ; Mon, 5 Jan 2015 14:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 wwubSezm2SDL for ; Mon, 5 Jan 2015 14:04:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 02B271A8F46 for ; Mon, 5 Jan 2015 14:04:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E7E1F1832B6; Mon, 5 Jan 2015 14:03:44 -0800 (PST) To: tbray@textuality.com, barryleiba@computer.org, presnick@qti.qualcomm.com, mamille2@cisco.com, paul.hoffman@vpnc.org X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150105220344.E7E1F1832B6@rfc-editor.org> Date: Mon, 5 Jan 2015 14:03:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/json/M6Uq4Ei9peXiM-o8e5o3m1vTUz4 Cc: rfc-editor@rfc-editor.org, json@ietf.org, tg@mirbsd.org Subject: [Json] [Technical Errata Reported] RFC7159 (4220) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jan 2015 22:04:09 -0000 The following errata report has been submitted for RFC7159, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4220 -------------------------------------- Type: Technical Reported by: mirabilos Section: 7 Original Text ------------- […] All Unicode characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). […] unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Corrected Text -------------- […] All Unicode characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark, reverse solidus, the control characters (U+0000 through U+001F), and codepoints beyond the BMP (U-00010000 through U-0010FFFF). […] unescaped = %x20-21 / %x23-5B / %x5D-FFFF Notes ----- ECMA-262 states that "ECMAScript source text is assumed to be a sequence of 16-bit code units", and everything must be converted to UTF-16 first. This stems from the fact that Java™, like Win32, used UCS-2, which only later got extended to allow UTF-16. This means that SMP codepoints must always be escaped into their twelve-character form. This is also an interoperability issue: implementations may wish to parse (or generate) JSON by using a wchar_t data type (in C) which, depending on the platform, may be only 16 bits wide. ECMAscript allows for this. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : March 2014 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Jan 5 18:19:55 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC251A90D0 for ; Mon, 5 Jan 2015 18:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxp_8aC3ZQRd for ; Mon, 5 Jan 2015 18:19:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDEE1A037B for ; Mon, 5 Jan 2015 18:19:51 -0800 (PST) Received: from netb ([89.204.130.114]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LpPg1-1XeUpa09Uj-00fE9k; Tue, 06 Jan 2015 03:19:32 +0100 From: Bjoern Hoehrmann To: RFC Errata System Date: Tue, 06 Jan 2015 03:19:25 +0100 Message-ID: <36hmaa5b180omvoo815c97ul8g84cebrcr@hive.bjoern.hoehrmann.de> References: <20150105220344.E7E1F1832B6@rfc-editor.org> In-Reply-To: <20150105220344.E7E1F1832B6@rfc-editor.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:AlKaImjSxAufOCEFjMC4blVyV/ywugXh64PEJ0NToG6v9ayLQwC x0iWBGjjq6YhQzabs+DkmJrzro8TP0yzy9MiBjzaN1/9uE0N4LAzkHuV2VlLZuHtbeoboVc LYGsvlKtp2Zy9QZ9TmoNJdT5s1rYKYK7GilawO548AfUgAdf+w8iEaxLf2uPfJcIh82wD+z +xKv18zpxJmGjBpHWgyGQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/json/7cF5yelhy52uEhNfE5iHceAuKaA Cc: tg@mirbsd.org, presnick@qti.qualcomm.com, paul.hoffman@vpnc.org, json@ietf.org, tbray@textuality.com, mamille2@cisco.com, barryleiba@computer.org, rfc-editor@rfc-editor.org Subject: Re: [Json] [Technical Errata Reported] RFC7159 (4220) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jan 2015 02:19:53 -0000 * RFC Errata System wrote: >Original Text >------------- > […] All Unicode characters may be placed within the > quotation marks, except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F). > >[…] > > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF >ECMA-262 states that "ECMAScript source text is assumed to be a sequence >of 16-bit code units", and everything must be converted to UTF-16 first. >This stems from the fact that Javaâ„¢, like Win32, used UCS-2, which only >later got extended to allow UTF-16. This means that SMP codepoints must >always be escaped into their twelve-character form. > >This is also an interoperability issue: implementations may wish to parse >(or generate) JSON by using a wchar_t data type (in C) which, depending on >the platform, may be only 16 bits wide. ECMAscript allows for this. What assumptions ECMA-262 makes when defining the ECMAScript language is not really relevant to the construction of `application/json` entities. Likewise, how implementations might internally represent parts of JSON documents does not affects the bits-on-the-wire format. I also do not see what difference it would make from either perspective when a UTF-8 encoded `application/json` entity encoded a non-BMP character literally or as escaped surrogate pair, it's just a lexical difference, you can use wchar_t the same either way. In any case, I am quite sure allowing unescaped non-BMP characters is a deliberate decision and not an error. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Tue Jan 6 00:46:44 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0921A899D for ; Tue, 6 Jan 2015 00:46:42 -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] 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 eAjlEQSfiN83 for ; Tue, 6 Jan 2015 00:46:41 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B581B1A1EEE for ; Tue, 6 Jan 2015 00:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t068kaXt018850; Tue, 6 Jan 2015 09:46:36 +0100 (CET) Received: from [192.168.217.149] (p548916FA.dip0.t-ipconnect.de [84.137.22.250]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kGnPS2Jsmz7yVx; Tue, 6 Jan 2015 09:46:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: <20150105220344.E7E1F1832B6@rfc-editor.org> Date: Tue, 6 Jan 2015 09:46:35 +0100 X-Mao-Original-Outgoing-Id: 442225688.984178-a808f7545b190beda47206c74825ee47 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150105220344.E7E1F1832B6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/JqeFHoTCmg09qkFK2kZK2j88YVg Cc: tg@mirbsd.org, JSON WG Subject: Re: [Json] [Technical Errata Reported] RFC7159 (4220) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jan 2015 08:46:43 -0000 On 05 Jan 2015, at 23:03, RFC Errata System = wrote: >=20 > ECMA-262 states that "ECMAScript source text is assumed to be a = sequence > of 16-bit code units", and everything must be converted to UTF-16 = first. =E2=80=A6 which is a source of a common misconception about JavaScript = that sometimes carries over into a common misconception about JSON. While it is true that a number of programming languages that were = created at a time when Unicode was thought to be a 16-bit character set = are now stuck with the workarounds of UTF-16, there is no problem with = non-BMP characters in JavaScript source code or in JavaScript strings. JavaScript will just process them as two code units (a source of bugs, = but something a JavaScript coder has to contend with in any case): > "=F0=9F=90=AD".length < 2 As Bj=C3=B6rn said, any limitations of ECMA-262 or JavaScript are of no = import to JSON anyway, as would be limitations of specific C = implementations. More importantly, this errata is not really reporting an error, but = trying to change a conscious decision of the WG (here: not to deviate = from RFC 4627 in what is allowed unescaped in strings); it thus needs to = be rejected. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 6 01:55:04 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC751A912B for ; Tue, 6 Jan 2015 01:54:52 -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] 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 XZjwJEvWRPHi for ; Tue, 6 Jan 2015 01:54:52 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC53B1A0029 for ; Tue, 6 Jan 2015 01:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t069smZ2027741; Tue, 6 Jan 2015 10:54:48 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kGpw80RDsz7yVl; Tue, 6 Jan 2015 10:54:48 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: <20150105220344.E7E1F1832B6@rfc-editor.org> Date: Tue, 6 Jan 2015 10:54:48 +0100 X-Mao-Original-Outgoing-Id: 442227107.467863-a4c23c74294d35c6bde340f857e93eb0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150105220344.E7E1F1832B6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/_rWAC7HSKCDRZ6THWJQMaEhPmBQ Cc: tg@mirbsd.org, JSON WG Subject: Re: [Json] [Technical Errata Reported] RFC7159 (4220) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jan 2015 09:54:54 -0000 On 05 Jan 2015, at 23:03, RFC Errata System = wrote: >=20 > ECMA-262 states that "ECMAScript source text is assumed to be a = sequence > of 16-bit code units", and everything must be converted to UTF-16 = first. =E2=80=A6 which is a source of a common misconception about JavaScript = that sometimes carries over into a common misconception about JSON. While it is true that a number of programming languages that were = created at a time when Unicode was thought to be a 16-bit character set = are now stuck with the workarounds of UTF-16, there is no problem with = non-BMP characters in JavaScript source code or in JavaScript strings. JavaScript will just process them as two code units (a source of bugs, = but something a JavaScript coder has to contend with in any case): > "=F0=9F=90=AD".length < 2 As Bj=C3=B6rn said, any limitations of ECMA-262 or JavaScript are of no = import to JSON anyway, as would be limitations of specific C = implementations. More importantly, this errata is not really reporting an error, but = trying to change a conscious decision of the WG (here: not to deviate = from RFC 4627 in what is allowed unescaped in strings); it thus needs to = be rejected. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 6 07:47:05 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128511A01F0 for ; Tue, 6 Jan 2015 07:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0K50LBDxrt1 for ; Tue, 6 Jan 2015 07:47:02 -0800 (PST) Received: from opus1.proper.com (unknown [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD32B1A1BED for ; Tue, 6 Jan 2015 07:47:01 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by opus1.proper.com (8.15.1/8.14.7) with ESMTPSA id t06FkTAd040060 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 08:46:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: opus1.proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <20150105220344.E7E1F1832B6@rfc-editor.org> Date: Tue, 6 Jan 2015 07:46:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <542C6D58-B66E-4EF3-A806-638EB0905EA7@vpnc.org> References: <20150105220344.E7E1F1832B6@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/YUABJekXda9UL6Ng6O45KQl3jIQ Cc: tg@mirbsd.org, Pete Resnick , json@ietf.org, Tim Bray , Matt Miller , Barry Leiba Subject: Re: [Json] [Technical Errata Reported] RFC7159 (4220) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jan 2015 15:47:04 -0000 Please reject this errata. It stems from a disagreement with a WG = decision, not as a report of a error. --Paul Hoffman, JSON WG co-chair > On Jan 5, 2015, at 2:03 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7159, > "The JavaScript Object Notation (JSON) Data Interchange Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4220 >=20 > -------------------------------------- > Type: Technical > Reported by: mirabilos >=20 > Section: 7 >=20 > Original Text > ------------- > [=E2=80=A6] All Unicode characters may be placed within the > quotation marks, except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F). >=20 > [=E2=80=A6] >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF >=20 > Corrected Text > -------------- > [=E2=80=A6] All Unicode characters may be placed within the > quotation marks, except for the characters that must be escaped: > quotation mark, reverse solidus, the control characters (U+0000 > through U+001F), and codepoints beyond the BMP (U-00010000 > through U-0010FFFF). >=20 > [=E2=80=A6] >=20 > unescaped =3D %x20-21 / %x23-5B / %x5D-FFFF >=20 > Notes > ----- > ECMA-262 states that "ECMAScript source text is assumed to be a = sequence > of 16-bit code units", and everything must be converted to UTF-16 = first. > This stems from the fact that Java=E2=84=A2, like Win32, used UCS-2, = which only > later got extended to allow UTF-16. This means that SMP codepoints = must > always be escaped into their twelve-character form. >=20 > This is also an interoperability issue: implementations may wish to = parse > (or generate) JSON by using a wchar_t data type (in C) which, = depending on > the platform, may be only 16 bits wide. ECMAscript allows for this. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7159 (draft-ietf-json-rfc4627bis-rfc7159bis) > -------------------------------------- > Title : The JavaScript Object Notation (JSON) Data = Interchange Format > Publication Date : March 2014 > Author(s) : T. Bray, Ed. > Category : PROPOSED STANDARD > Source : JavaScript Object Notation > Area : Applications > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu Jan 8 07:55:25 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139F61A8AAF for ; Thu, 8 Jan 2015 07:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 F7Kk8C59bHJb; Thu, 8 Jan 2015 07:55:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 974601A8A92; Thu, 8 Jan 2015 07:55:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108155520.30268.79978.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 07:55:20 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:55:23 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Thu Jan 8 08:15:02 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114581A875D for ; Thu, 8 Jan 2015 08:15:01 -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 N5-2R1KkpwbO; Thu, 8 Jan 2015 08:14:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD07D1A8A92; Thu, 8 Jan 2015 08:14:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108161456.29249.38451.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 08:14:56 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:15:01 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Thu Jan 8 08:15:05 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4841A8A9E; Thu, 8 Jan 2015 08:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 hCRWvwnktF7O; Thu, 8 Jan 2015 08:15:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C131A8AC0; Thu, 8 Jan 2015 08:14:57 -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: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108161457.29249.11891.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 08:14:57 -0800 Archived-At: Cc: json mailing list , json chair , RFC Editor Subject: [Json] Protocol Action: 'JavaScript Object Notation (JSON) Text Sequences' to Proposed Standard (draft-ietf-json-text-sequence-13.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: Thu, 08 Jan 2015 16:15:04 -0000 The IESG has approved the following document: - 'JavaScript Object Notation (JSON) Text Sequences' (draft-ietf-json-text-sequence-13.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-text-sequence/ Technical Summary This document describes the JSON text sequence format. A JSON text sequence is specifically not a JSON text itself, but it is composed of (possible) JSON texts. JSON text sequences can be parsed (and produced) incrementally without having to have a streaming parser (nor streaming encoder). This allows easy coding of extremely large datasets, logs, and so on. Because it is a format, it is appropriate for standards track. Working Group Summary The WG had some problems with early drafts of the document, but came to rough consensus at the end. There was disagreement about what character(s) should be used to delimit text sequences, but there was fairly extensive discussion and most of the participants agreed that the sequence chosen in the latest draft is the best of the alternatives discussed. Document Quality There was not a huge amount of interest in the format in the WG, but there was definite interest from some users of JSON, particularly those who want to write out JSON texts in logs. Personnel Paul Hoffman (co-chair of the JSON WG) is the document shepherd Pete Resnick is the responsible Area Director. From nobody Thu Jan 8 16:38:21 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015691A7029 for ; Thu, 8 Jan 2015 16:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 28uiv92K2AQN; Thu, 8 Jan 2015 16:38:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C04FF1A7028; Thu, 8 Jan 2015 16:38:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109003811.13327.83673.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 16:38:11 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 00:38:19 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Thu Jan 8 18:05:24 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9649E1A7028 for ; Thu, 8 Jan 2015 18:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 Y95LY9RJVOQR; Thu, 8 Jan 2015 18:05:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12C1A702E; Thu, 8 Jan 2015 18:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109020521.14530.87878.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 18:05:21 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 02:05:23 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Fri Jan 9 14:05:31 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E419B1A1A9A for ; Fri, 9 Jan 2015 14:05:28 -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 ZP6EBwW5XDw2; Fri, 9 Jan 2015 14:05:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A48DA1A034F; Fri, 9 Jan 2015 14:05:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109220527.24917.52358.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 14:05:27 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:05:29 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ From nobody Mon Jan 12 13:07:22 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01711ACDF3 for ; Mon, 12 Jan 2015 13:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 m-2P9lWgLyV6; Mon, 12 Jan 2015 13:07:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF681ACDFA; Mon, 12 Jan 2015 13:06:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112210647.7580.96246.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 13:06:47 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: 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, 12 Jan 2015 21:07:13 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Mon Jan 12 14:05:42 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A911ACDF2 for ; Mon, 12 Jan 2015 14:05:36 -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 PCk951F7SPfT; Mon, 12 Jan 2015 14:05:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAD71ACDF5; Mon, 12 Jan 2015 14:05:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112220517.27778.53957.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 14:05:17 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: 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, 12 Jan 2015 22:05:37 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Mon Jan 12 19:06:44 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E9C1A89FB for ; Mon, 12 Jan 2015 19:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 L-2m89R_Uysc; Mon, 12 Jan 2015 19:06:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD011A8A11; Mon, 12 Jan 2015 19:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113030617.19614.73151.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 19:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: 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: Tue, 13 Jan 2015 03:06:41 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Wed Jan 14 00:08:31 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2085E1B29F8; Wed, 14 Jan 2015 00:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 JJTMzvGD80mF; Wed, 14 Jan 2015 00:08:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A44841A8F40; Wed, 14 Jan 2015 00:08:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114080826.7009.72729.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 00:08:26 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Json] Last Call Expired: 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: Wed, 14 Jan 2015 08:08:29 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Wed Jan 14 08:47:54 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4027E1A911D for ; Wed, 14 Jan 2015 08:47:41 -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 gYCXxUh5tfS4; Wed, 14 Jan 2015 08:47:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0F81A90E5; Wed, 14 Jan 2015 08:47:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114164722.804.10720.idtracker@ietfa.amsl.com> Date: Wed, 14 Jan 2015 08:47:22 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: 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: Wed, 14 Jan 2015 16:47:43 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ From nobody Mon Jan 19 06:01:24 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7081B2A5D; Mon, 19 Jan 2015 06:01:21 -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 UYmOQvJ5pwud; Mon, 19 Jan 2015 06:01:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1531AD2A9; Mon, 19 Jan 2015 06:01:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119140118.824.91479.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 06:01:18 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, linuxwolf@outer-planes.net, json@ietf.org, Juergen Schoenwaelder , draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Benoit Claise's No Objection on draft-ietf-json-i-json-05: (with COMMENT) 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, 19 Jan 2015 14:01:21 -0000 Benoit Claise has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There is still a ongoing discussion between J. Schönwälder (OPS-DIR) and Tim Bray. On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote: > On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > >> My understanding is that compliance to I-JSON means compliance to >> section 2 of this document. Perhaps it makese sense to clarify this >> (in particular if my interpretation is wrong). >> > > Hmm, good point. ​The draft currently doesn’t mention compliance; all it > does is give a syntactic definition of something called an “I-JSON > message”. The notion was that other specs which wanted to require the use > of I-JSON should say something like “The message body must be an I-JSON > message [RFCXXXX]”. I think that would work fine, but I wonder if others, > like you, will be bothered by the absence of a specification of > “compliance”. > I am raising this question since I think the draft goes somewhat beyond simply defining I-JSON (which I believe is the material contained in section 2). In particular, the I-D uses RFC 2119 language in a section titled "Protocol-design Recommendations". It is not clear to me how these recommendations have been selected or why they are part of an I-JSON specification. This applies mostly to sections 4.3 and 4.4. Anyway, since these sections use RFC 2119 requirements language, I am wondering what happens if a protocol complies to section 2 but not all of section 4 - is it using I-JSON? I hope so, but it might be good to make this clear. /js ---------------------------------------------------- Editorial nit: - s/values in in ISO 8601/values in ISO 8601/ From nobody Mon Jan 19 12:18:59 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00E1B2C3A; Mon, 19 Jan 2015 12:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 w3MKlEssxBE5; Mon, 19 Jan 2015 12:18:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A6C1B2AE8; Mon, 19 Jan 2015 12:18:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119201854.30003.24739.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 12:18:54 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Spencer Dawkins' No Objection on draft-ietf-json-i-json-05: (with COMMENT) 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, 19 Jan 2015 20:18:56 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Juergen/s question ... From nobody Mon Jan 19 12:24:23 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5171B2C42; Mon, 19 Jan 2015 12:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 OeNgv0kNDXl7; Mon, 19 Jan 2015 12:24:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A961B2AE8; Mon, 19 Jan 2015 12:24:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 12:24:07 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) 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, 19 Jan 2015 20:24:13 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir reviewer in his assessment of this draft after reading it. I'm putting this in as comments/suggestions to be considered as the security considerations really should be in the JSON document. If any considerations are missing, that is where I'd expect to see them. The JSON format is not simple, so agree with the SecDir reviewer that one would have expected additional handling considerations for security purposes to be in that document. They don't need to be listed in this one. Having said that, it might be good idea to add text to the security considerations section, to state that I-JSON restricts and limits some of the dangerous formats of the original JSON, therefore it might be considered more secure than the original JSON. Perhaps also mention that security critical usages of the JSON should use I-JSON (perhaps even provide references to the jose specifications). https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html From nobody Mon Jan 19 14:44:02 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703581B2D0D; Mon, 19 Jan 2015 14:43:59 -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 9a-GBU4G4XUE; Mon, 19 Jan 2015 14:43:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E367A1B2D03; Mon, 19 Jan 2015 14:43:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 14:43:57 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) 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, 19 Jan 2015 22:43:59 -0000 Barry Leiba has entered the following ballot position for draft-ietf-json-i-json-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be quite simple to sort out: -- Section 2.1 -- Object member names, and string values in arrays and object members, MUST NOT include code points which identify Surrogates or Noncharacters. Where are the definitions of "Surrogates" and "Noncharacters"? Because you say they MUST NOT be included, I think they need to be defined in normative reference(s) and cited here (they're not defined in 3629, nor does 3620 cite a definition). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The RFC Editor will make a lot of "which" -> "that" changes. Just be aware. -- Sections 3 and 4 -- Going in the other direction from Jürgen's comments, I think these sections are unremarkable, and would just suggest changing the 2119 language to English words instead. This is all giving sage advice, not defining protocol. -- Section 5 -- I don't normally comment on "Acknowledgments" sections, and please take this as you will and do as you think best. You mention the contributions of Douglas Crockford, and I wonder whether you might also mention the contributions of Ecma International TC39. From nobody Mon Jan 19 15:28:57 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA11B2CF9; Mon, 19 Jan 2015 15:28:52 -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 12O3T7JvzZlM; Mon, 19 Jan 2015 15:28:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB051B2D33; Mon, 19 Jan 2015 15:28:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119232839.19662.13834.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 15:28:39 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Stephen Farrell's No Objection on draft-ietf-json-i-json-05: (with COMMENT) 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, 19 Jan 2015 23:28:52 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 2.1: I've no idea what Surrogate or Noncharacter means here - a precise reference would be good for me. And the examples don't help me. So I agree with Barry's discuss. - 4.3: Did the WG discuss whether to require/encourage inclusion/exclusion of 00 values and timezones in times? E.g. is there a preference for 20150119T2304Z or 20150119T230400Z which represent the same time. - 4.3: I'm also a bit surprised you don't say that UTC is the default TZ. I think those time rules do help interoperability so defining defaults would have been an improvement. Why is that? (I don't think 3339 does that or does it?) - 4.4: I don't recall them so have had to track down the difference between base64 and base64url and check I'm using the right APIs over and over. That might be because I only write code sporadically (and badly:-) and forget stuff in between, but an example of the difference (possibly parenthetical) would help me a bit, just so's I could look at a value I generate and spot I've done it wrong again. - I mostly agree with the secdir reviewer's [1] point that it might be good to RECOMMEND use of I-JSON for more security sensitive applications, but I'd have felt more strongly about that if you'd profiled the time values more strictly as messing up those can lead to vulnerabilities and being more precise there helps to get e.g. signatures correct a bit more easily. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html From nobody Mon Jan 19 19:22:20 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E319F1ACE1E; Mon, 19 Jan 2015 19:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPFPH-pGPml6; Mon, 19 Jan 2015 19:22:15 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC5B1ACDF6; Mon, 19 Jan 2015 19:22:14 -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=1421724135; x=1453260135; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0I/PwXI6rfdbzJ21khiDrjTMF2Dtg2T7XzIAj3oMHrw=; b=nb2hT1Tg4QclbZY3jNrS5jnUs11uQQHDH2qTc3JlO8wP7v92+ANfoeJF PisGBuwNnEgS/JGc98a7Al9eqxlbPbsw+HoFco100zJEzoQ8sjyE9wJ5Z gidMxd3GX3Yo/tPFEhTbp2+eY2scd0WA1nsANgHd+F6aERnvEuc+12XNn s=; X-IronPort-AV: E=McAfee;i="5600,1067,7686"; a="190850070" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2015 19:22:14 -0800 X-IronPort-AV: E=Sophos;i="5.09,431,1418112000"; d="scan'208";a="795797461" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Jan 2015 19:22:13 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 19 Jan 2015 19:22:12 -0800 Message-ID: <54BDC9E3.2050507@qti.qualcomm.com> Date: Mon, 19 Jan 2015 21:22:11 -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: Barry Leiba References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> In-Reply-To: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jan 2015 03:22:18 -0000 On 1/19/15 4:43 PM, Barry Leiba wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be quite simple to sort out: > > -- Section 2.1 -- > > Object member names, and string values in arrays and object members, > MUST NOT include code points which identify Surrogates or > Noncharacters. > > Where are the definitions of "Surrogates" and "Noncharacters"? Because > you say they MUST NOT be included, I think they need to be defined in > normative reference(s) and cited here (they're not defined in 3629, nor > does 3620 cite a definition). > The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) are mentioned in 3629 in the first paragraph at the top of page 5 , though I'm surprised not to see a reference to 2781, which also talks about surrogates. There is discussion of non-characters (as well as surrogates) in RFC 3454 (which is referenced by 6885). None of those are great citations. We could simply cite Unicode . pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Jan 19 19:25:34 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E156F1ACDF6 for ; Mon, 19 Jan 2015 19:25:28 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TOfJ5NTgHqs for ; Mon, 19 Jan 2015 19:25:27 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D421ACDAE for ; Mon, 19 Jan 2015 19:25:26 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ms9so9810566lab.1 for ; Mon, 19 Jan 2015 19:25:24 -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=Ygb3zjkIOQeGkTWuZpjf9raMBdewqwfzDFr6NGLyX8E=; b=bVnTJSkGx0/WdxWaMTEuS4XqJQkTRiRtPHKtd3aBkAmOz+UxkwkH7ZvuxSWi3y96T8 sDvi0hI5/cgaYgbMCPs3QiGxLjRfCrLKwVCTG1NjSFLtBXaVtaVfzOM8+e1y4MoEhe+W lu/x3KE84xB/QIBc0jOvTUsI9kYLKjz9jbQBnBs74stqygsLtG5pp1sBriOqQJF1OI34 7vSpcbDN4yJsWgGsDkr1c2U2ZdCfuAdFkAQ3MeCo4ComrSK/6mmfTmYetHHCHvd6bAN7 tloToGp3uPJMX9/2NnMuTUuT+ks1tBjKFiO/gp6eTMn16HvMBcmKjyMxB/OTRFBedE5H uB/Q== X-Gm-Message-State: ALoCoQlKxjD13ypGuk6WXqAUFHKTr0DvA1V+70gahLwJT2f1N7jbGgPJ5nDBn/YKt0zP+6kjFmYj MIME-Version: 1.0 X-Received: by 10.152.1.2 with SMTP id 2mr29158335lai.89.1421724324595; Mon, 19 Jan 2015 19:25:24 -0800 (PST) Received: by 10.114.28.98 with HTTP; Mon, 19 Jan 2015 19:25:24 -0800 (PST) X-Originating-IP: [24.84.235.32] Received: by 10.114.28.98 with HTTP; Mon, 19 Jan 2015 19:25:24 -0800 (PST) In-Reply-To: <54BDC9E3.2050507@qti.qualcomm.com> References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> Date: Mon, 19 Jan 2015 19:25:24 -0800 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=089e013c6672561ae3050d0cfd37 Archived-At: Cc: linuxwolf@outer-planes.net, json@ietf.org, The IESG , draft-ietf-json-i-json.all@tools.ietf.org, Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jan 2015 03:25:29 -0000 --089e013c6672561ae3050d0cfd37 Content-Type: text/plain; charset=UTF-8 Yup, those are Unicode notions, Unicode is the right reference for them. On Jan 19, 2015 7:22 PM, "Pete Resnick" wrote: > On 1/19/15 4:43 PM, Barry Leiba wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This should be quite simple to sort out: >> >> -- Section 2.1 -- >> >> Object member names, and string values in arrays and object members, >> MUST NOT include code points which identify Surrogates or >> Noncharacters. >> >> Where are the definitions of "Surrogates" and "Noncharacters"? Because >> you say they MUST NOT be included, I think they need to be defined in >> normative reference(s) and cited here (they're not defined in 3629, nor >> does 3620 cite a definition). >> >> > > The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) are > mentioned in 3629 in the first paragraph at the top of page 5 < > https://tools.ietf.org/html/rfc3629#page-5>, though I'm surprised not to > see a reference to 2781, which also talks about surrogates. There is > discussion of non-characters (as well as surrogates) in RFC 3454 (which is > referenced by 6885). > > None of those are great citations. We could simply cite Unicode < > http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf>. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e013c6672561ae3050d0cfd37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yup, those are Unicode notions, Unicode is the right referen= ce for them.

On Jan 19, 2015 7:22 PM, "Pete Resnick"= ; <presnick@qti.qualcomm.co= m> wrote:
On = 1/19/15 4:43 PM, Barry Leiba wrote:
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

This should be quite simple to sort out:

-- Section 2.1 --

=C2=A0 =C2=A0 Object member names, and string values in arrays and object m= embers,
=C2=A0 =C2=A0 MUST NOT include code points which identify Surrogates or
=C2=A0 =C2=A0 Noncharacters.

Where are the definitions of "Surrogates" and "Noncharacters= "?=C2=A0 Because
you say they MUST NOT be included, I think they need to be defined in
normative reference(s) and cited here (they're not defined in 3629, nor=
does 3620 cite a definition).
=C2=A0 =C2=A0

The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) are me= ntioned in 3629 in the first paragraph at the top of page 5 <https://tools= .ietf.org/html/rfc3629#page-5>, though I'm surprised not = to see a reference to 2781, which also talks about surrogates. There is dis= cussion of non-characters (as well as surrogates) in RFC 3454 (which is ref= erenced by 6885).

None of those are great citations. We could simply cite Unicode <http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf&g= t;.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--089e013c6672561ae3050d0cfd37-- From nobody Tue Jan 20 07:00:52 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03F71B2D73; Mon, 19 Jan 2015 23:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_0ziB5UGLx3; Mon, 19 Jan 2015 23:24:13 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B250D1ACE43; Mon, 19 Jan 2015 23:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9363; q=dns/txt; s=iport; t=1421738652; x=1422948252; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iNbXyt0jXKpI1/qNTI22go71j5VbZCXKoVrsdex+aRw=; b=eETPRXEQMXTVk12p6fJ7xKqLkFmb41llGn9R55KR7LckfcoVBe1UHyWW 3mnih8AQpfV6HXrLDOAcjyNvECrqSugsgf1ia52loXW7izF+XQCb+enZc MTzPGTuBMbNJiaZmGUEo/VA89oB/8mTyQNaXS0wW9DSRdKFvyR1cud0vs o=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAGwBvlStJssW/2dsb2JhbABRBwMWg0JYgwfDIwEJhXECgWEBAQEBAX2EDQEBAgIBAQEgBEcKARALDgoJFggDAgIJAwIBAgEVHxEGAQwBBQIBAQWIIw25fZQVAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48dTBAHEYJXgUEFhTqKboEpT4VQgRSFG4g+gz0igVtXgT09MQEBAYJAAQEB X-IronPort-AV: E=Sophos;i="5.09,432,1418083200"; d="asc'?scan'208,217";a="314641121" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 20 Jan 2015 07:24:10 +0000 Received: from [10.61.196.18] ([10.61.196.18]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0K7OA7v006364; Tue, 20 Jan 2015 07:24:10 GMT Message-ID: <54BE029F.2090709@cisco.com> Date: Tue, 20 Jan 2015 08:24:15 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tim Bray , Pete Resnick References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tBAB5MxMefhs2BBHPrEPx9VM4Ej4aoAiN" Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 07:00:51 -0800 Cc: linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , John C Klensin , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jan 2015 07:24:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tBAB5MxMefhs2BBHPrEPx9VM4Ej4aoAiN Content-Type: multipart/alternative; boundary="------------020008040909020301020907" This is a multi-part message in MIME format. --------------020008040909020301020907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late comment, but... The IAB is preparing a cautionary statement regarding Unicode 7.0.0 and specifically the introduction of pre-composed characters involving HAMZA where it is impossible to typographically distinguish the precomposed and decomposed characters outside the context of a locale. John Klensin has explained the problem well in Section 2 of draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to review that work, and ask i8n program for a copy of the draft statement, because it may have security implications on your work, in as much as i-json is used to pass identifiers. Eliot On 1/20/15 4:25 AM, Tim Bray wrote: > > Yup, those are Unicode notions, Unicode is the right reference for them= =2E > > On Jan 19, 2015 7:22 PM, "Pete Resnick" > wrote: > > On 1/19/15 4:43 PM, Barry Leiba wrote: > > ---------------------------------------------------------------= ------- > DISCUSS: > ---------------------------------------------------------------= ------- > > This should be quite simple to sort out: > > -- Section 2.1 -- > > Object member names, and string values in arrays and > object members, > MUST NOT include code points which identify Surrogates or > Noncharacters. > > Where are the definitions of "Surrogates" and > "Noncharacters"? Because > you say they MUST NOT be included, I think they need to be > defined in > normative reference(s) and cited here (they're not defined in > 3629, nor > does 3620 cite a definition). > =20 > > > The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) > are mentioned in 3629 in the first paragraph at the top of page 5 > , though I'm surprised > not to see a reference to 2781, which also talks about surrogates. > There is discussion of non-characters (as well as surrogates) in > RFC 3454 (which is referenced by 6885). > > None of those are great citations. We could simply cite Unicode > . > > pr > > --=20 > Pete Resnick > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --------------020008040909020301020907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

Sorry for the late comment, but...

The IAB is preparing a cautionary statement regarding Unicode 7.0.0 and specifically the introduction of pre-composed characters involving HAMZA where it is impossible to typographically distinguish the precomposed and decomposed characters outside the context of a locale.=C2=A0 John Klensin has explained the problem wel= l in Section 2 of draft-klensin-idna-5892upd-unicode70-03.txt.=C2=A0 You m= ay wish to review that work, and ask i8n program for a copy of the draft statement, because it may have security implications on your work, in as much as i-json is used to pass identifiers.

Eliot

On 1/20/15 4:25 AM, Tim Bray wrote:

Yup, those are Unicode notions, Unicode is the right= reference for them.

On Jan 19, 2015 7:22 PM, "Pete Resnick" <presnick@qti.qualcomm= =2Ecom> wrote:
On 1/19/15 4:43 PM, Barry Leiba wrote:
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

This should be quite simple to sort out:

-- Section 2.1 --

=C2=A0 =C2=A0 Object member names, and string values in array= s and object members,
=C2=A0 =C2=A0 MUST NOT include code points which identify Sur= rogates or
=C2=A0 =C2=A0 Noncharacters.

Where are the definitions of "Surrogates" and "Noncharacters"?=C2=A0 Because
you say they MUST NOT be included, I think they need to be defined in
normative reference(s) and cited here (they're not defined in 3629, nor
does 3620 cite a definition).
=C2=A0 =C2=A0

The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) are mentioned in 3629 in the first paragraph at the top of page 5 <https://tools.ietf.org/html/rfc3629#page-5<= /a>>, though I'm surprised not to see a reference to 2781, which also talks about surrogates. There is discussion of non-characters (as well as surrogates) in RFC 3454 (which is referenced by 6885).

None of those are great citations. We could simply cite Unicode <http://www.unicode.org/versions/Unicode7.0.= 0/ch03.pdf>.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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


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

--------------020008040909020301020907-- --tBAB5MxMefhs2BBHPrEPx9VM4Ej4aoAiN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUvgKfAAoJEIe2a0bZ0noz/nwH/jsk7F4ejKc4fVhXS9mJy9u3 FQP16vHwtuAK5RIB6HEZacI1Vc8eOfSP+tfvt4x9b9QS8JOG6h8zfLAMmWs3Lety O/arKXIEbr66SyZRW/2nBmjFYaL+j9Zb9Gba/6awGzFbCB8wvqnL9Xx1MHvsxLgD +7xaqQYA+QTLtBX/qTEfX/tlB0tbSi2qYJFmLkkSUFLpchrkX7ODaZpzdFyCqmoJ P7fxpfWyQYv83y0bXJlhOr88e/dMyVw8qm5CJEUdkn7AbcGK2sCrAaY1iqSiNT4f 3+1Ojgs9wqmVe6AP8Y8wzLmStSjIPp0qjDeqSOvkpeZyo8iRQBLqTkuLk8KPF0U= =tMMq -----END PGP SIGNATURE----- --tBAB5MxMefhs2BBHPrEPx9VM4Ej4aoAiN-- From nobody Tue Jan 20 07:06:38 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4559A1B2A97; Tue, 20 Jan 2015 07:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4FjQQCwiVin; Tue, 20 Jan 2015 07:06:09 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCD11B2A02; Tue, 20 Jan 2015 07:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10981; q=dns/txt; s=iport; t=1421766370; x=1422975970; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+Opx2HiGCn1FbjIIjtHNCiocdfXqtIgNDkGaQK9HdyE=; b=JuLCwq0DJmg1GV6b2yHYmYXjMLIxqOh6zsmp73Ov07IkdKxj1pliBxid 5QRGPk/zFgMFC36cvwYoIYfq8zybSgOJrP1CIhQlcuVPtsYtyn6eP1dFc azrBRw79dfss3XqkSW0KnX9dsZa6gYK8IajCr7r2zd/53dvxwEPpmKn5c k=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EABxuvlStJssW/2dsb2JhbABRBwMWg0JYgwfDJQEJhXECgWcBAQEBAX2EDQEBAgIBAQEgBEcKARALDgoJFggDAgIJAwIBAgEVHxEGAQwBBQIBAQWIIw28MpNcAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48dTBAHEYJXgUEFhTqKboEpT4VQgRSFG4g+gz0igVtXgT09MQEBAYJAAQEB X-IronPort-AV: E=Sophos;i="5.09,434,1418083200"; d="asc'?scan'208,217";a="315142144" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 20 Jan 2015 15:06:07 +0000 Received: from [10.61.71.140] (ams3-vpn-dhcp1932.cisco.com [10.61.71.140]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0KF63pB016361; Tue, 20 Jan 2015 15:06:06 GMT Message-ID: <54BE6EDA.7030408@cisco.com> Date: Tue, 20 Jan 2015 16:06:02 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tim Bray , Pete Resnick References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> In-Reply-To: <54BE029F.2090709@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xOkIGddAdrLoLdjDppKfPUxWnq6pCLhlH" Archived-At: Cc: json@ietf.org, Andrew Sullivan , John C Klensin , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jan 2015 15:06:13 -0000 X-List-Received-Date: Tue, 20 Jan 2015 15:06:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xOkIGddAdrLoLdjDppKfPUxWnq6pCLhlH Content-Type: multipart/alternative; boundary="------------020206020501080605080807" This is a multi-part message in MIME format. --------------020206020501080605080807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just one further comment: I would not anticipate ANY change to the specification over this, but you may think it worth mentioning as an upper layer matter. Or not. Eliot On 1/20/15 8:24 AM, Eliot Lear wrote: > Hi, > > Sorry for the late comment, but... > > The IAB is preparing a cautionary statement regarding Unicode 7.0.0 > and specifically the introduction of pre-composed characters involving > HAMZA where it is impossible to typographically distinguish the > precomposed and decomposed characters outside the context of a > locale. John Klensin has explained the problem well in Section 2 of > draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to review > that work, and ask i8n program for a copy of the draft statement, > because it may have security implications on your work, in as much as > i-json is used to pass identifiers. > > Eliot > > On 1/20/15 4:25 AM, Tim Bray wrote: >> >> Yup, those are Unicode notions, Unicode is the right reference for the= m. >> >> On Jan 19, 2015 7:22 PM, "Pete Resnick" > > wrote: >> >> On 1/19/15 4:43 PM, Barry Leiba wrote: >> >> --------------------------------------------------------------= -------- >> DISCUSS: >> --------------------------------------------------------------= -------- >> >> This should be quite simple to sort out: >> >> -- Section 2.1 -- >> >> Object member names, and string values in arrays and >> object members, >> MUST NOT include code points which identify Surrogates or >> Noncharacters. >> >> Where are the definitions of "Surrogates" and >> "Noncharacters"? Because >> you say they MUST NOT be included, I think they need to be >> defined in >> normative reference(s) and cited here (they're not defined in >> 3629, nor >> does 3620 cite a definition). >> =20 >> >> >> The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) >> are mentioned in 3629 in the first paragraph at the top of page 5 >> , though I'm >> surprised not to see a reference to 2781, which also talks about >> surrogates. There is discussion of non-characters (as well as >> surrogates) in RFC 3454 (which is referenced by 6885). >> >> None of those are great citations. We could simply cite Unicode >> . >> >> pr >> >> --=20 >> Pete Resnick> > >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --------------020206020501080605080807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just one further comment: I would not anticipate ANY change to the specification over this, but you may think it worth mentioning as an upper layer matter.=C2=A0 Or not.

Eliot

On 1/20/15 8:24 AM, Eliot Lear wrote:<= br>
Hi,

Sorry for the late comment, but...

The IAB is preparing a cautionary statement regarding Unicode 7.0.0 and specifically the introduction of pre-composed characters involving HAMZA where it is impossible to typographically distinguish the precomposed and decomposed characters outside the context of a locale.=C2=A0 John Klensin has explained the problem w= ell in Section 2 of draft-klensin-idna-5892upd-unicode70-03.txt.=C2=A0 = You may wish to review that work, and ask i8n program for a copy of the draft statement, because it may have security implications on your work, in as much as i-json is used to pass identifiers.

Eliot

On 1/20/15 4:25 AM, Tim Bray wrote:<= br>

Yup, those are Unicode notions, Unicode is the right reference for them.

On Jan 19, 2015 7:22 PM, "Pete Resnick= " <presnick@qti.qualco= mm.com> wrote:
On 1/19/15 4:43 PM, Barry Leiba wrote:
-----------------------------------------------------------= -----------
DISCUSS:
----------------------------------------------------------------------
This should be quite simple to sort out:

-- Section 2.1 --

=C2=A0 =C2=A0 Object member names, and string values in arr= ays and object members,
=C2=A0 =C2=A0 MUST NOT include code points which identify S= urrogates or
=C2=A0 =C2=A0 Noncharacters.

Where are the definitions of "Surrogates" and "Noncharacters"?=C2=A0 Because
you say they MUST NOT be included, I think they need to be defined in
normative reference(s) and cited here (they're not defined in 3629, nor
does 3620 cite a definition).
=C2=A0 =C2=A0

The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) are mentioned in 3629 in the first paragraph at the top of page 5 <https://tools.ietf.org/html/rfc3629#page-= 5>, though I'm surprised not to see a reference to 2781, which also talks about surrogates. There is discussion of non-characters (as well as surrogates) in RFC 3454 (which is referenced by 6885).

None of those are great citations. We could simply cite Unicode <http://www.unicode.org/versions/Unicode7.= 0.0/ch03.pdf>.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>= ;
Qualcomm Technologies, Inc. - +1 (858)651-4478

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


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listi=
nfo/json




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

--------------020206020501080605080807-- --xOkIGddAdrLoLdjDppKfPUxWnq6pCLhlH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUvm7bAAoJEIe2a0bZ0nozl4sIANN1ggLAJ8f4maEQ/LFlhm2F Ob4C6aw9tKxwIlnXqc6ppsFLyt2M6Mmna8VxbLsDkqgVwKA817KxrdNbWPl400a8 uPt2z3IB3QLDTuMqsl8cAryvPdI+7m4aIU/HMNozY0ghjEQYGVTUA/KttsCFBva5 CQvLP/MmZWMu24UzkwggjFaRTHFEpUGKigtIRLEn6NGTmreHYmrnHxkeAZX4q8pQ GXNDIStGQcFX8V9a7j4U3xOzrg2Qafmjt691tuiRN2RFsbkUJwc6CaSLmIRqKD4P CLxw3btz+CMdtSjXni3iRtXg8dWeeYqqaOuJFfNaaLkubhfOtqluYhpOFNkGLGw= =ukcq -----END PGP SIGNATURE----- --xOkIGddAdrLoLdjDppKfPUxWnq6pCLhlH-- From nobody Wed Jan 21 07:21:49 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1C61A0282; Tue, 20 Jan 2015 20:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 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_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50ewUgC8Dvns; Tue, 20 Jan 2015 20:05:10 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9F80C1A0270; Tue, 20 Jan 2015 20:05:09 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id D07E332E592; Wed, 21 Jan 2015 13:04:23 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 43ef_3e43_b24a4876_f4db_4476_84ee_5e862725e9e8; Wed, 21 Jan 2015 13:04:23 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 39B0CBF4E2; Wed, 21 Jan 2015 13:04:23 +0900 (JST) Message-ID: <54BF2546.9030006@it.aoyama.ac.jp> Date: Wed, 21 Jan 2015 13:04:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Eliot Lear , Tim Bray , Pete Resnick References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> In-Reply-To: <54BE029F.2090709@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 07:21:38 -0800 Cc: linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , John C Klensin , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, "idna-update@alvestrand.no" , Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 04:05:18 -0000 Hello Eliot, Many thanks for the information. Some comments below. Note that I'm not=20 assuming that the IAB statement will contain as much 'near misses' as=20 your explanation below, but I think it's better to address potential=20 errors before it's too late. And yes, in this sense it would be good to=20 get a draft of that statement. I have also taken the liberty of adding the IDNA mailing list, because=20 most of the Unicode side experts are on that list but not on the json lis= t. On 2015/01/20 16:24, Eliot Lear wrote: > Hi, > > Sorry for the late comment, but... > > The IAB is preparing a cautionary statement regarding Unicode 7.0.0 and I very much hope that the statement will be specific to the actual=20 concerns, and not, as this sentence seems to suggest, about Unicode=20 7.0.0 in general. The later would be throwing out the baby with the=20 bathwater. > specifically the introduction of pre-composed characters involving HAMZ= A > where it is impossible to typographically distinguish the precomposed > and decomposed characters Please note that first, there are no cases where it's *impossible* to=20 typographically distinguish precomposed and decomposed characters, or=20 some other usually not distinguished pairs (see below for examples).=20 There's always the choice of choosing (for a font designer) of choosing=20 somewhat different glyphs, or for a rendering engine to include some=20 distinctions (such as showing the precomposed variant with a separated=20 combining character). Second, there are other cases where in general, no typographic=20 distinction is used. =E0=AE=95 and =E0=AF=A7 (Tamil 'ka' and '1') would b= e a good example. > outside the context of a locale. There's no guarantee that all text in a Fula locale (e.g. on a computer=20 with a Fula OS, if there ever is such a thing) will have Behs with=20 Hamzas above represented with U+08A1 (composed) rather than decomposed. =D8=A8=D9=94 U+0628 U+0654 (decomposed) may get in there from Arabic text= easily. > John Klensin > has explained the problem well in Section 2 of > draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to review > that work, and ask i8n program for a copy of the draft statement, > because it may have security implications on your work, in as much as > i-json is used to pass identifiers. Given that JSON implementations, in contrast to IDNA, compare object=20 member names codepoint-by-codepoint, the much more obvious addition to=20 the security section would be to point out the potential consequences=20 for precomposed/decomposed confusions in general. The chance that this=20 becomes an actual issue is much much higher (although still rather low)=20 in e.g. French or German than in Fula, where Arabic isn't even the main=20 script used for writing the language. Regards, Martin. P.S.: Please note that the comments above don't mean that I'm happy with=20 the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely hope the=20 Unicode Consortium will weight the problems of identifier confusability=20 higher in their future decisions. > Eliot > > On 1/20/15 4:25 AM, Tim Bray wrote: >> >> Yup, those are Unicode notions, Unicode is the right reference for the= m. >> >> On Jan 19, 2015 7:22 PM, "Pete Resnick" > > wrote: >> >> On 1/19/15 4:43 PM, Barry Leiba wrote: >> >> -------------------------------------------------------------= --------- >> DISCUSS: >> -------------------------------------------------------------= --------- >> >> This should be quite simple to sort out: >> >> -- Section 2.1 -- >> >> Object member names, and string values in arrays and >> object members, >> MUST NOT include code points which identify Surrogates or >> Noncharacters. >> >> Where are the definitions of "Surrogates" and >> "Noncharacters"? Because >> you say they MUST NOT be included, I think they need to be >> defined in >> normative reference(s) and cited here (they're not defined in >> 3629, nor >> does 3620 cite a definition). >> >> >> >> The codepoints used for UTF-16 surrogate pairs (U+D800 -> U+DFFF) >> are mentioned in 3629 in the first paragraph at the top of page 5 >> , though I'm surprise= d >> not to see a reference to 2781, which also talks about surrogates= . >> There is discussion of non-characters (as well as surrogates) in >> RFC 3454 (which is referenced by 6885). >> >> None of those are great citations. We could simply cite Unicode >> . >> >> pr >> >> -- >> Pete Resnick> > >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Jan 21 08:23:37 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DD1A1B11; Wed, 21 Jan 2015 08:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 EyHI8kyz3wGS; Wed, 21 Jan 2015 08:22:19 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 344891A1B0A; Wed, 21 Jan 2015 08:22:19 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id B5CC51DE070; Wed, 21 Jan 2015 08:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Rjg3ArOFKqqmVOSiPad8qvCz1YQ=; b=AJ+Bx87Vvk1 /n+uwmm5xxP81knWsnYSdapWkkZua6s6XwxZ0xQDwAqzewEk6VfVD8rq7AC/lBoT BJND/PhFKM/T8tPxnaISdMxUKgm5GDLdgU1mGXwbJz/fEYc0so8SqWM+bWALHTJq jwA7j5v49iOAiGHcafOxArHIS1pK5kyU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 918781DE060; Wed, 21 Jan 2015 08:22:17 -0800 (PST) Date: Wed, 21 Jan 2015 10:22:10 -0600 From: Nico Williams To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20150121162206.GN2350@localhost> References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> <54BF2546.9030006@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54BF2546.9030006@it.aoyama.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 08:23:34 -0800 Cc: Eliot Lear , Pete Resnick , linuxwolf@outer-planes.net, "idna-update@alvestrand.no" , json@ietf.org, Andrew Sullivan , Tim Bray , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, John C Klensin , Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 16:22:21 -0000 On Wed, Jan 21, 2015 at 01:04:22PM +0900, "Martin J. D=FCrst" wrote: > >John Klensin > >has explained the problem well in Section 2 of > >draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to review > >that work, and ask i8n program for a copy of the draft statement, > >because it may have security implications on your work, in as much as > >i-json is used to pass identifiers. >=20 > Given that JSON implementations, in contrast to IDNA, compare object > member names codepoint-by-codepoint, the much more obvious addition > to the security section would be to point out the potential > consequences for precomposed/decomposed confusions in general. The > chance that this becomes an actual issue is much much higher > (although still rather low) in e.g. French or German than in Fula, > where Arabic isn't even the main script used for writing the > language. A JSON implementation could normalize as it hashes (if it hashes) the keys, though, of course, RFC7159 says nothing about this. Implementations of form-insensitive Unicode character string comparison and hashing functions do exist that basically normalize one _character_ (not codepoint) at a time. The reason for doing it this way is performance: there's no need to allocate memory dynamically for this, and in many cases most characters in the input string(s) have just one form or are already in canonical form. > P.S.: Please note that the comments above don't mean that I'm happy > with the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely > hope the Unicode Consortium will weight the problems of identifier > confusability higher in their future decisions. I thought that NFC was closed to new precompositions though new precompositions might be added to Unicode. That is, the NFC form of U+08A1 must be the same as the NFD form of U+08A1, which is to say: U+0628 U+0654. Is my memory wrong about that? Nico --=20 From nobody Wed Jan 21 08:51:49 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43E51A1B1B; Wed, 21 Jan 2015 08:34:50 -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 p8QJMpeJwPst; Wed, 21 Jan 2015 08:34:49 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886F91A1AFA; Wed, 21 Jan 2015 08:34:49 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so40261661lbi.10; Wed, 21 Jan 2015 08:34:48 -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:content-transfer-encoding; bh=7luAeJv2tXWCge0x1H+3FnlGV3h6LV+pkvhFpALkFlY=; b=nsitS6rZj3ws4X6I5eET5JLHKJyCvDlKlGrBwStjw7veaU7GZnPNrtl62Ka9ITmvS/ w3T//xAKdvc0ycWbbtwgck9F4JQxJfczL8CvnkQAfIbbWnqFSusbVbGAl4M0ouoFaKqv skyZFQ1iv2HBiWGCtd6G12syQ6IBL+ZU3XgPv2gXYaK3xKRz58Obdb8Ilcv6CRJIVA3+ wcQJ9gRImOvdly0llYREC/EcWNloiI9km6daknuDebRdo1vr0ZN27LMFit8CxufsBjVc 3Q8Gh7cLw1DE+MfKZMaOH66xMmKOdJskF+cr5YIV+h2uNR+u0oxy+8WypSqNjIodPDZ9 /7Lw== MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr45921291laf.82.1421858088043; Wed, 21 Jan 2015 08:34:48 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Wed, 21 Jan 2015 08:34:47 -0800 (PST) In-Reply-To: <20150121162206.GN2350@localhost> References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> <54BF2546.9030006@it.aoyama.ac.jp> <20150121162206.GN2350@localhost> Date: Wed, 21 Jan 2015 11:34:47 -0500 X-Google-Sender-Auth: jcPDxZ8a0AEkZW5Bba3xN9MPqvM Message-ID: From: Barry Leiba To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 08:51:45 -0800 Cc: Eliot Lear , Pete Resnick , Matt Miller , "json@ietf.org" , Andrew Sullivan , "idna-update@alvestrand.no" , The IESG , John C Klensin , draft-ietf-json-i-json.all@tools.ietf.org, Tim Bray , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , "json-chairs@tools.ietf.org" Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 16:34:50 -0000 All, can we please take this up in a separate message thread? It's a useful discussion to have, but it has nothing to do with my DISCUSS and comments on the document. Thanks, Barry On Wed, Jan 21, 2015 at 11:22 AM, Nico Williams wro= te: > On Wed, Jan 21, 2015 at 01:04:22PM +0900, "Martin J. D=FCrst" wrote: >> >John Klensin >> >has explained the problem well in Section 2 of >> >draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to review >> >that work, and ask i8n program for a copy of the draft statement, >> >because it may have security implications on your work, in as much as >> >i-json is used to pass identifiers. >> >> Given that JSON implementations, in contrast to IDNA, compare object >> member names codepoint-by-codepoint, the much more obvious addition >> to the security section would be to point out the potential >> consequences for precomposed/decomposed confusions in general. The >> chance that this becomes an actual issue is much much higher >> (although still rather low) in e.g. French or German than in Fula, >> where Arabic isn't even the main script used for writing the >> language. > > A JSON implementation could normalize as it hashes (if it hashes) the > keys, though, of course, RFC7159 says nothing about this. > > Implementations of form-insensitive Unicode character string comparison > and hashing functions do exist that basically normalize one _character_ > (not codepoint) at a time. The reason for doing it this way is > performance: there's no need to allocate memory dynamically for this, > and in many cases most characters in the input string(s) have just one > form or are already in canonical form. > >> P.S.: Please note that the comments above don't mean that I'm happy >> with the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely >> hope the Unicode Consortium will weight the problems of identifier >> confusability higher in their future decisions. > > I thought that NFC was closed to new precompositions though new > precompositions might be added to Unicode. That is, the NFC form of > U+08A1 must be the same as the NFD form of U+08A1, which is to say: > U+0628 U+0654. > > Is my memory wrong about that? > > Nico > -- > From nobody Wed Jan 21 11:32:15 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CD61A8715; Wed, 21 Jan 2015 11:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S05LjRIrMHB; Wed, 21 Jan 2015 11:29:33 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04AC1A86FF; Wed, 21 Jan 2015 11:29:32 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YE0xz-000Jl8-VR; Wed, 21 Jan 2015 14:29:27 -0500 Date: Wed, 21 Jan 2015 14:29:22 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Eliot Lear , Tim Bray , Pete Resnick Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 11:31:58 -0800 Cc: linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , idna-update@alvestrand.no, The IESG , draft-ietf-json-i-json.all@tools.ietf.org, Barry Leiba , json-chairs@tools.ietf.org Subject: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 19:29:35 -0000 (Resending from my IETF address, which did not appear in the first version I received but that doesn't work on some of the multiple mailing lists copied) (Changing subject line per Barry's request and addressing that one issue only.) --On Wednesday, January 21, 2015 13:04 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >... >> outside the context of a locale. >=20 > There's no guarantee that all text in a Fula locale (e.g. on a > computer with a Fula OS, if there ever is such a thing) Note that isn't "a Fula locale", but "a Fula locale that uses the Arabic script to write the language". There are no known such locales of even country-scope; Fula is normally written in Latin characters and has been for at least a few centuries. There are lots of problems with the analogy, but thinking about Fula-in-Arabic in ordinary locale terms is a little bit like thinking about Japanese-exclusively-in-Romanji (and Romanji with a few characters that don't appear anywhere else in Latin script) as a locale. Probably possible to make it work, but not the way most of us usually think about things. > will > have Behs with Hamzas above represented with U+08A1 (composed) > rather than decomposed. > =D8=A8=D9=94 U+0628 U+0654 (decomposed) may get in there from = Arabic > text easily. I presume that is one of the reasons TUS 7.0 says "preferentially" should use the precombined (composed) form rather than the decomposed one rather than something we would recognize as "MUST". >> John Klensin >> has explained the problem well in Section 2 of >> draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to >> review that work, and ask i8n program for a copy of the draft >> statement, because it may have security implications on your >> work, in as much as i-json is used to pass identifiers. >=20 > Given that JSON implementations, in contrast to IDNA, compare > object member names codepoint-by-codepoint, the much more > obvious addition to the security section would be to point out > the potential consequences for precomposed/decomposed > confusions in general. The chance that this becomes an actual > issue is much much higher (although still rather low) in e.g. > French or German than in Fula, where Arabic isn't even the > main script used for writing the language. Agreed. And, fwiw, that would be my preferred solution. I think Fula and U+08A1 are important only as illustrative examples of what appears to me to be a very nasty situation when the nature of the identifier(s) or their uses does not provide a reliable language context. > P.S.: Please note that the comments above don't mean that I'm > happy with the inclusion of U+08A1 in Unicode 7.0.0, and that > I sincerely hope the Unicode Consortium will weight the > problems of identifier confusability higher in their future > decisions. Agreed, although the way in which the U+08A1 decision has been defended, and the antecedents for it, do not predict to that result. See below. --On Wednesday, January 21, 2015 10:22 -0600 Nico Williams wrote: > I thought that NFC was closed to new precompositions though = new > precompositions might be added to Unicode. That is, the NFC > form of U+08A1 must be the same as the NFD form of U+08A1, > which is to say: U+0628 U+0654. >=20 > Is my memory wrong about that? That is the understanding that several -- I dare to say most or all of the IDNAbis WG participants -- of us had. What has actually occurred either violates that assumption or introduces an extra case, depending on how one looks at the problem. We understood that, if precompositions (your term) are added, they would have decompositions and NFC of the character would yield the decomposed form. That understanding derived both from what the WG was told and from text in the Unicode Standard and UAX #15 (see draft-klensin-idna-5892upd-unicode70-02, especially Section 2.1, for details and references). =20 But, while U+08A1 is abstract-character-identical and even plausible-name-identical to U+0628 U+0654, it does _not_ decompose into the latter. Instead, NFD(U+08A1) =3D NFC(U+08A1) = =3D U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would expect from the stability rules; from that perspective, it is the failure of U+08A1 to have a (non-identity) decomposition that is the issue. john From nobody Wed Jan 21 11:32:17 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CDA1A871C; Wed, 21 Jan 2015 11:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V93bjWfuanr9; Wed, 21 Jan 2015 11:26:51 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890641A86FF; Wed, 21 Jan 2015 11:26:51 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YE0vF-000Jkd-84; Wed, 21 Jan 2015 14:26:37 -0500 Date: Wed, 21 Jan 2015 14:26:32 -0500 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Eliot Lear , Tim Bray , Pete Resnick Message-ID: <882717E0412866628323024E@JcK-HP8200.jck.com> In-Reply-To: <54BF2546.9030006@it.aoyama.ac.jp> References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> <54BF2546.9030006@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 11:32:03 -0800 Cc: linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , idna-update@alvestrand.no, The IESG , draft-ietf-json-i-json.all@tools.ietf.org, Barry Leiba , json-chairs@tools.ietf.org Subject: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 19:26:56 -0000 (Changing subject line per Barry's request and addressing that one issue only.) --On Wednesday, January 21, 2015 13:04 +0900 "\"Martin J. D=C3=BCrst\"" wrote: >... >> outside the context of a locale. >=20 > There's no guarantee that all text in a Fula locale (e.g. on a > computer with a Fula OS, if there ever is such a thing) Note that isn't "a Fula locale", but "a Fula locale that uses the Arabic script to write the language". There are no known such locales of even country-scope; Fula is normally written in Latin characters and has been for at least a few centuries. There are lots of problems with the analogy, but thinking about Fula-in-Arabic in ordinary locale terms is a little bit like thinking about Japanese-exclusively-in-Romanji (and Romanji with a few characters that don't appear anywhere else in Latin script) as a locale. Probably possible to make it work, but not the way most of us usually think about things. > will > have Behs with Hamzas above represented with U+08A1 (composed) > rather than decomposed. > =D8=A8=D9=94 U+0628 U+0654 (decomposed) may get in there from = Arabic > text easily. I presume that is one of the reasons TUS 7.0 says "preferentially" should use the precombined (composed) form rather than the decomposed one rather than something we would recognize as "MUST". >> John Klensin >> has explained the problem well in Section 2 of >> draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to >> review that work, and ask i8n program for a copy of the draft >> statement, because it may have security implications on your >> work, in as much as i-json is used to pass identifiers. >=20 > Given that JSON implementations, in contrast to IDNA, compare > object member names codepoint-by-codepoint, the much more > obvious addition to the security section would be to point out > the potential consequences for precomposed/decomposed > confusions in general. The chance that this becomes an actual > issue is much much higher (although still rather low) in e.g. > French or German than in Fula, where Arabic isn't even the > main script used for writing the language. Agreed. And, fwiw, that would be my preferred solution. I think Fula and U+08A1 are important only as illustrative examples of what appears to me to be a very nasty situation when the nature of the identifier(s) or their uses does not provide a reliable language context. > P.S.: Please note that the comments above don't mean that I'm > happy with the inclusion of U+08A1 in Unicode 7.0.0, and that > I sincerely hope the Unicode Consortium will weight the > problems of identifier confusability higher in their future > decisions. Agreed, although the way in which the U+08A1 decision has been defended, and the antecedents for it, do not predict to that result. See below. --On Wednesday, January 21, 2015 10:22 -0600 Nico Williams wrote: > I thought that NFC was closed to new precompositions though = new > precompositions might be added to Unicode. That is, the NFC > form of U+08A1 must be the same as the NFD form of U+08A1, > which is to say: U+0628 U+0654. >=20 > Is my memory wrong about that? That is the understanding that several -- I dare to say most or all of the IDNAbis WG participants -- of us had. What has actually occurred either violates that assumption or introduces an extra case, depending on how one looks at the problem. We understood that, if precompositions (your term) are added, they would have decompositions and NFC of the character would yield the decomposed form. That understanding derived both from what the WG was told and from text in the Unicode Standard and UAX #15 (see draft-klensin-idna-5892upd-unicode70-02, especially Section 2.1, for details and references). =20 But, while U+08A1 is abstract-character-identical and even plausible-name-identical to U+0628 U+0654, it does _not_ decompose into the latter. Instead, NFD(U+08A1) =3D NFC(U+08A1) = =3D U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would expect from the stability rules; from that perspective, it is the failure of U+08A1 to have a (non-identity) decomposition that is the issue. john From nobody Wed Jan 21 11:35:40 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18FC1A871B; Wed, 21 Jan 2015 11:35:37 -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 6S08KxqPZ0zU; Wed, 21 Jan 2015 11:35:36 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2496E1A871A; Wed, 21 Jan 2015 11:35:36 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0LJZVKu023712 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 12:35:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Wed, 21 Jan 2015 11:35:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E99E249-923C-46BF-BB78-C9E736C93182@vpnc.org> References: To: John C Klensin X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IDNA update work , The IESG , IETF JSON WG Subject: Re: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 19:35:38 -0000 I see nothing here about JSON. As pointed out, JSON implementations = compare codepoint by codepoint. Please clarify, or please let's drop = this from the JSON WG list. --Paul Hoffman > On Jan 21, 2015, at 11:29 AM, John C Klensin = wrote: >=20 > (Resending from my IETF address, which did not appear in the > first version I received but that doesn't work on some of the > multiple mailing lists copied) > (Changing subject line per Barry's request and addressing that > one issue only.) >=20 > --On Wednesday, January 21, 2015 13:04 +0900 "\"Martin J. > D=C3=BCrst\"" wrote: >=20 >> ... >>> outside the context of a locale. >>=20 >> There's no guarantee that all text in a Fula locale (e.g. on a >> computer with a Fula OS, if there ever is such a thing) >=20 > Note that isn't "a Fula locale", but "a Fula locale that uses > the Arabic script to write the language". There are no known > such locales of even country-scope; Fula is normally written in > Latin characters and has been for at least a few centuries. > There are lots of problems with the analogy, but thinking about > Fula-in-Arabic in ordinary locale terms is a little bit like > thinking about Japanese-exclusively-in-Romanji (and Romanji with > a few characters that don't appear anywhere else in Latin > script) as a locale. Probably possible to make it work, but not > the way most of us usually think about things. >=20 >> will >> have Behs with Hamzas above represented with U+08A1 (composed) >> rather than decomposed. >> =D8=A8=D9=94 U+0628 U+0654 (decomposed) may get in there from Arabic >> text easily. >=20 > I presume that is one of the reasons TUS 7.0 says > "preferentially" should use the precombined (composed) form > rather than the decomposed one rather than something we would > recognize as "MUST". >=20 >>> John Klensin >>> has explained the problem well in Section 2 of >>> draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to >>> review that work, and ask i8n program for a copy of the draft >>> statement, because it may have security implications on your >>> work, in as much as i-json is used to pass identifiers. >>=20 >> Given that JSON implementations, in contrast to IDNA, compare >> object member names codepoint-by-codepoint, the much more >> obvious addition to the security section would be to point out >> the potential consequences for precomposed/decomposed >> confusions in general. The chance that this becomes an actual >> issue is much much higher (although still rather low) in e.g. >> French or German than in Fula, where Arabic isn't even the >> main script used for writing the language. >=20 > Agreed. And, fwiw, that would be my preferred solution. I > think Fula and U+08A1 are important only as illustrative > examples of what appears to me to be a very nasty situation when > the nature of the identifier(s) or their uses does not provide a > reliable language context. >=20 >> P.S.: Please note that the comments above don't mean that I'm >> happy with the inclusion of U+08A1 in Unicode 7.0.0, and that >> I sincerely hope the Unicode Consortium will weight the >> problems of identifier confusability higher in their future >> decisions. >=20 > Agreed, although the way in which the U+08A1 decision has been > defended, and the antecedents for it, do not predict to that > result. See below. >=20 >=20 > --On Wednesday, January 21, 2015 10:22 -0600 Nico Williams > wrote: >=20 >> I thought that NFC was closed to new precompositions though new >> precompositions might be added to Unicode. That is, the NFC >> form of U+08A1 must be the same as the NFD form of U+08A1, >> which is to say: U+0628 U+0654. >>=20 >> Is my memory wrong about that? >=20 > That is the understanding that several -- I dare to say most or > all of the IDNAbis WG participants -- of us had. What has > actually occurred either violates that assumption or introduces > an extra case, depending on how one looks at the problem. We > understood that, if precompositions (your term) are added, they > would have decompositions and NFC of the character would yield > the decomposed form. That understanding derived both from what > the WG was told and from text in the Unicode Standard and UAX > #15 (see draft-klensin-idna-5892upd-unicode70-02, especially > Section 2.1, for details and references). =20 >=20 > But, while U+08A1 is abstract-character-identical and even > plausible-name-identical to U+0628 U+0654, it does _not_ > decompose into the latter. Instead, NFD(U+08A1) =3D NFC(U+08A1) =3D > U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would > expect from the stability rules; from that perspective, it is > the failure of U+08A1 to have a (non-identity) decomposition > that is the issue. >=20 > john >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From nobody Wed Jan 21 12:46:33 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92631A8728; Wed, 21 Jan 2015 11:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 txbr8x5-sPMq; Wed, 21 Jan 2015 11:43:02 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF7281A86F5; Wed, 21 Jan 2015 11:43:02 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id A220094065; Wed, 21 Jan 2015 11:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=sy7e4WkTd1+7vh fV/gr0ZI2Zw08=; b=DTY4Ckc7VPqwkH4nEPt+iUxFOlPkTopSoIwYsJg8xGsf9r cmfC9EDTGsG5RnYmAgL2hBZJfqf/Dj+syGcyN5CE5wtZ+7sA6X41I51begxb0rOc R4Rj/ACTdZKlnl55MdIRL+SL2di8tYnT8pkvrC9Yzi1OG3ML1e0Z8TgxuouRo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 5AF5F9405C; Wed, 21 Jan 2015 11:43:01 -0800 (PST) Date: Wed, 21 Jan 2015 13:42:54 -0600 From: Nico Williams To: John C Klensin Message-ID: <20150121194249.GT2350@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 12:46:31 -0800 Cc: Eliot Lear , Pete Resnick , linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , Tim Bray , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, idna-update@alvestrand.no, =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= , Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 19:43:03 -0000 On Wed, Jan 21, 2015 at 02:29:22PM -0500, John C Klensin wrote: > --On Wednesday, January 21, 2015 10:22 -0600 Nico Williams > wrote: > > I thought that NFC was closed to new precompositions though new > > precompositions might be added to Unicode. That is, the NFC > > form of U+08A1 must be the same as the NFD form of U+08A1, > > which is to say: U+0628 U+0654. > > > > Is my memory wrong about that? > > That is the understanding that several -- I dare to say most or > all of the IDNAbis WG participants -- of us had. What has > actually occurred either violates that assumption or introduces > an extra case, depending on how one looks at the problem. [...] Because... > But, while U+08A1 is abstract-character-identical and even > plausible-name-identical to U+0628 U+0654, it does _not_ > decompose into the latter. Instead, NFD(U+08A1) = NFC(U+08A1) = ...this is a desirable property of that particular character, or because the UC screwed up? See below. > U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would > expect from the stability rules; from that perspective, it is > the failure of U+08A1 to have a (non-identity) decomposition > that is the issue. Is it identical, as rendered as well as semantically, to U+0628 U+0654? If U+08A1 identical to U+0628 U+0654 in every way then I think the UC erred. If it is not, then U+08A1 strikes me as a new case that IDNA should treat as though NFC(U+08A1) == U+0628 U+0654 (because what else could IDNA reasonably do??). In what ways is U+08A1 not identical to U+0628 U+0654? (besides, of course, being a different codepoint sequence) Nico -- From nobody Wed Jan 21 12:46:34 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3ED1A87BA; Wed, 21 Jan 2015 12:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-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 hKg5GBnaxoYO; Wed, 21 Jan 2015 12:07:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759A91A87AD; Wed, 21 Jan 2015 12:07:48 -0800 (PST) Received: from BY2PR0301MB0728.namprd03.prod.outlook.com (25.160.63.18) by BY2PR0301MB0725.namprd03.prod.outlook.com (25.160.63.155) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 20:07:25 +0000 Received: from BY2PR0301MB0728.namprd03.prod.outlook.com ([25.160.63.18]) by BY2PR0301MB0728.namprd03.prod.outlook.com ([25.160.63.18]) with mapi id 15.01.0059.007; Wed, 21 Jan 2015 20:07:25 +0000 From: Shawn Steele To: John C Klensin , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Eliot Lear , Tim Bray , Pete Resnick Thread-Topic: Json and U+08A1 and related cases (was: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) Thread-Index: AQHQNbGJ7LXG9CxIJkyVjR8s4xAJJpzK+1AA Date: Wed, 21 Jan 2015 20:07:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BY2PR0301MB0725; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0725; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(52314003)(51704005)(199003)(102836002)(2656002)(87936001)(122556002)(2950100001)(2900100001)(40100003)(68736005)(86612001)(46102003)(54606007)(50986999)(54356999)(105586002)(99286002)(106356001)(106116001)(97736003)(230783001)(76176999)(92566002)(101416001)(33656002)(54206007)(77156002)(64706001)(86362001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0725; H:BY2PR0301MB0728.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2015 20:07:25.5852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0725 Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 12:46:31 -0800 Cc: "linuxwolf@outer-planes.net" , "json@ietf.org" , Andrew Sullivan , "idna-update@alvestrand.no" , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , =?utf-8?B?TWFyayBEYXZpcyDimJXvuI8=?= , Barry Leiba , "json-chairs@tools.ietf.org" Subject: Re: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 20:07:50 -0000 Pj4gSSB0aG91Z2h0IHRoYXQgTkZDIHdhcyBjbG9zZWQgdG8gbmV3IHByZWNvbXBvc2l0aW9ucyB0 aG91Z2ggbmV3IA0KPj4gcHJlY29tcG9zaXRpb25zIG1pZ2h0IGJlIGFkZGVkIHRvIFVuaWNvZGUu ICBUaGF0IGlzLCB0aGUgTkZDIGZvcm0gb2YgDQo+PiBVKzA4QTEgbXVzdCBiZSB0aGUgc2FtZSBh cyB0aGUgTkZEIGZvcm0gb2YgVSswOEExLCB3aGljaCBpcyB0byBzYXk6IA0KPj4gVSswNjI4IFUr MDY1NC4NCj4gDQo+ID5JcyBteSBtZW1vcnkgd3JvbmcgYWJvdXQgdGhhdD8NCg0KPiBUaGF0IGlz IHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgc2V2ZXJhbCAtLSBJIGRhcmUgdG8gc2F5IG1vc3Qgb3Ig YWxsIG9mICB0aGUgSUROQWJpcyBXRyBwYXJ0aWNpcGFudHMgLS0gb2YgdXMgaGFkLiAgDQoNCk15 IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHJ1bGVzIGlzIHRoYXQgbm8gbmV3IGNoYXJhY3RlcnMgY291 bGQgYmUgYWRkZWQgdGhhdCB3b3VsZCBjYXVzZSBub3JtYWxpemF0aW9uIG9mIGV4aXN0aW5nIGNv ZGVwb2ludHMgdG8gY2hhbmdlLiAgKFRoZXkgY291bGQgYmUgYWRkZWQgd2l0aCBib3RoIHByZWNv bXBvc2VkIGFuZCBkZWNvbXBvc2VkIGZvcm1zLCBidXQgb25seSBpZiBhbGwgb2YgdGhlIGNvZGVw b2ludHMgd2VyZSBuZXcsIHdoaWNoIHNlZW1zIHVubGlrZWx5IGFzIG5ldyBzY3JpcHQgYWRkaXRp b25zIHNlZW0gdG8gbm90IGxpa2UgdG8gaGF2ZSBib3RoIGZvcm1zKS4NCg0KQW55d2F5LCBzbyB0 aGUgYmVoYXZpb3Igd291bGQgYmUgdGhhdCBhbnkgY2hhcmFjdGVyIHRoYXQgaXMgYWRkZWQgdGhh dCBoYXBwZW5zIHRvIGxvb2sgbGlrZSBhIGRpZmZlcmVudCBjaGFyYWN0ZXIgc2VxdWVuY2UgaXMg dGhlcmVmb3JlIG5vdCB0aGUgc2FtZSBhcyB0aGUgb3RoZXIgY2hhcmFjdGVyLiAgSW4gb3RoZXIg d29yZHMsIGJ5IGRlZmluaXRpb24sIFUrMDhBMSBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgVSsw NjI4IFUrMDY1NCwgd2hldGhlciB0aGV5IGxvb2sgYWxpa2Ugb3Igbm90Lg0KDQpUaGlzIGlzIHNp bWlsYXIgdG8gc3BlbGxpbmcgSGF3YWknSSB3aXRoIG9yIHdpdGhvdXQgYW4gyrtva2luYSAoSGF3 YWnKu2kpLiAgQSBodW1hbiB0aGlua3MgdGhleSBsb29rIHRoZSBzYW1lLCBidXQgdGhleSBhcmVu J3QgdGhlIHNhbWUuICANCg0KSSBkb24ndCBrbm93IHRoZSBoaXN0b3J5IG9mIHdoeSB0aGlzIGNv ZGUgcG9pbnQgd2FzIGFkZGVkLCBhbmQgY2Fubm90IGFyZ3VlIGFib3V0IHdoZXRoZXIgb3Igbm90 IGl0ICJzaG91bGQiIGhhdmUganVzdCB1c2VkIHRoZSBleGlzdGluZyBjb2RlIHBvaW50cywgaG93 ZXZlciBJJ20gaGFwcHkgdGhhdCBzbWFydCBwZW9wbGUgdGhhdCBrbm93IGEgbG90IG1vcmUgYWJv dXQgc2NyaXB0cyB0aGFuIEkgZG8gZmVsdCB0aGF0IHRoaXMgd2FzIHRoZSByaWdodCB3YXkgdG8g aGFuZGxlIHRoaXMgY2hhcmFjdGVyLiAgQW5kLCBldmVuIGlmIHRoZXkgZ290IGl0ICJ3cm9uZyIg KGZvciB3aGF0ZXZlciB2YWx1ZSBvZiAid3JvbmciKSwgcmVhbGx5IHRoZXJlIGFyZSBhIGxvdCBv ZiBxdWlya3MgYWJvdXQgVW5pY29kZSB0aGF0IGFyZSBmYXIgbW9yZSBpbnRlcmVzdGluZyB0aGFu IHRoaXMgY2hhcmFjdGVyLCBzbyBJJ20gbm90IGdvaW5nIHRvIHNlY29uZCBndWVzcyB0aGUgVVRD Lg0KDQpUaGUgVW5pY29kZSBwcm9jZXNzIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgSUVURiBwcm9j ZXNzLCBob3dldmVyIGl0IGlzIHBvc3NpYmxlIHRvIHBhcnRpY2lwYXRlLiAgSWYgcGVvcGxlIHJl YWxseSBmZWVsIHRoaXMgc3Ryb25nbHkgYWJvdXQgaG93IFVuaWNvZGUgZW5jb2RlcyBjaGFyYWN0 ZXJzLCB0aGVuIHRoZXkgc2hvdWxkIHBhcnRpY2lwYXRlIGluIHRoZSBwcm9jZXNzLiAgSXQncyBu b3QgaGVscGZ1bCB0byBzZWNvbmQgZ3Vlc3Mgd2hhdCB0aGV5IGRpZC4gIEl0J3MgZXZlbiBsZXNz IGhlbHBmdWwgZm9yIElETiB0byB0cnkgdG8gYXR0ZW1wdCB0byB3b3JrIGFyb3VuZCBhIHByb2Js ZW0gYnkgdXNpbmcgY29kZXBvaW50cyBpbiBhIG1hbm5lciB0aGF0IGRvZXNuJ3QgY29uZm9ybSB0 byBUaGUgVW5pY29kZSBTdGFuZGFyZC4gIChTZWUgWmF3Z3lpIGZvciBhbiBleHRyZW1lIGV4YW1w bGUpLiAgDQoNClRoZSBVVEMvVW5pY29kZS9VVFIxNSBkZWNpZGVkIHRoYXQgVSswOEExIGRvZXNu J3QgZGVjb21wb3NlIHRvIFUrMDYyOCBVKzA2NTQuICBJRE4gc2hvdWxkbid0IHRyeSB0byBjaGFu Z2UgdGhhdCBiZWhhdmlvci4gIEF0IHRoaXMgcG9pbnQgaWYgZm9sa3MgcmVhbGx5IGZlZWwgc3Ry b25nbHkgdGhhdCBVbmljb2RlIGRpZCB0aGUgd3JvbmcgdGhpbmcsIHRoZW4gdGhleSBzaG91bGQg d29yayB3aXRoIHRoZSBVVEMgdG8gdHJ5IHRvIGNvbnZpbmNlIHRoZW0gKHJlYWxpemluZyB0aGF0 IGF0IHRoaXMgcG9pbnQgaXQgd291bGQgbmVlZCBhbiBhbWF6aW5nIGNhc2UgdG8gZWl0aGVyIGJy ZWFrIHRoZSBzdGFiaWxpdHkgcnVsZXMsIGRlcHJlY2F0ZSB0aGUgbmV3IGNvZGUgcG9pbnQsICYv b3IgcHVibGlzaCBzb21lIHNvcnQgb2YgYWRkZW5kdW0vZXJyYXRhKS4NCg0KLVNoYXduDQoNCg== From nobody Wed Jan 21 12:46:36 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4351A87CD; Wed, 21 Jan 2015 12:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guthRlbbHQN7; Wed, 21 Jan 2015 12:33:30 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E34F1A87CC; Wed, 21 Jan 2015 12:33:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=www.ccil.org ident=www-data) by earth.ccil.org with esmtp (Exim 4.72) (envelope-from ) id 1YE1xg-0000t9-0j; Wed, 21 Jan 2015 15:33:12 -0500 Received: from 171.159.192.10 (SquirrelMail authenticated user cowan) by www.ccil.org with HTTP; Wed, 21 Jan 2015 15:33:12 -0500 Message-ID: <133d6a2ef20b3ab18f0fcd211c78cae5.squirrel@www.ccil.org> In-Reply-To: References: Date: Wed, 21 Jan 2015 15:33:12 -0500 From: cowan@ccil.org To: "John C Klensin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: ClamAV 0.98.1 on earth.ccil.org; Wed, 21 Jan 2015 15:33:12 -0500 Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 12:46:31 -0800 Cc: Eliot Lear , Pete Resnick , linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , Tim Bray , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, idna-update@alvestrand.no, "=?iso-8859-1?Q?=22Martin_J._D=C3=BCrst=22?=" , Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 20:33:32 -0000 John C Klensin scripsit: > But, while U+08A1 is abstract-character-identical and even > plausible-name-identical to U+0628 U+0654, it does _not_ > decompose into the latter. Instead, NFD(U+08A1) = NFC(U+08A1) = > U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would > expect from the stability rules; from that perspective, it is > the failure of U+08A1 to have a (non-identity) decomposition > that is the issue. If U+08A1 had such a decomposition, it would violate Unicode's no-new-NFC rule. What it violates is the (false) assumption that base1 + combining is never confusable with a canonically non-equivalent base2. Even outside Arabic there are already such cases: U+1D92 LATIN SMALL LETTER E WITH RETROFLEX HOOK is not canonically equivalent to U+0065 LATIN SMALL LETTER E plus U+0322 COMBINING RETROFLEX HOOK BELOW (and ditto for some other Latin letters). U+047D CYRILLIC SMALL LETTER OMEGA WITH TITLO is not canonically equivalent to U+0461 CYRILLIC SMALL LETTER OMEGA plus U+0483 COMBINING CYRILLIC TITLO (and ditto for capital omega) U+2A25 PLUS SIGN WITH DOT BELOW is not canonically equivalent to U+002B PLUS SIGN plus U+0323 COMBINING DOT BELOW (and ditto for many other math symbols). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org What is the sound of Perl? Is it not the sound of a [Ww]all that people have stopped banging their head against? --Larry From nobody Wed Jan 21 12:46:37 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0801A87B2; Wed, 21 Jan 2015 12:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP0g4IrEfwgN; Wed, 21 Jan 2015 12:36:25 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id D38EF1A1B1C; Wed, 21 Jan 2015 12:36:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=G8ZSGOV/Mqttp1PGLdRjW/wSm4CuR4KBWNZeJbEud9z7GxiZO7P8fVxZ0q5pDA7p; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [72.244.200.92] (helo=[192.168.0.101]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YE20S-00053U-TU; Wed, 21 Jan 2015 15:36:05 -0500 Message-ID: <54C00DB4.9080806@ix.netcom.com> Date: Wed, 21 Jan 2015 12:36:04 -0800 From: Asmus Freytag User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Eliot Lear , Tim Bray , Pete Resnick References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> <54BF2546.9030006@it.aoyama.ac.jp> In-Reply-To: <54BF2546.9030006@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="------------030604070802050102080500" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b65b6112f89115374305fa825bf6ffb54008e95e4a6eca4b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.244.200.92 Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 12:46:31 -0800 Cc: linuxwolf@outer-planes.net, json@ietf.org, Andrew Sullivan , John C Klensin , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, idna-update@alvestrand.no, Barry Leiba , json-chairs@tools.ietf.org Subject: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 20:36:27 -0000 This is a multi-part message in MIME format. --------------030604070802050102080500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/20/2015 8:04 PM, "Martin J. Dürst" wrote: > P.S.: Please note that the comments above don't mean that I'm happy > with the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely > hope the Unicode Consortium will weight the problems of identifier > confusability higher in their future decisions. Given that an almost exactly parallel issue existed for a code point used in several Western European languages from Unicode 1.0, I think it would be wrong for Unicode to suddenly change the way non-Western scripts are encoded. Treating this particular case in isolation obscures the real issue and will possibly prevent or delay a proper design of identifier repertoires. To put the issue in general terms, it concerns the fact that there are homographs in Unicode. These are two distinct code point sequences with normally identical appearance. In particular, the concern is with homographs that are present after normalization. I'm very much on board with highlighting that issue, which is that*applying **NFC does not eliminate homographs*. And, having just finished the exercise of reviewing the full repertoire of modern scripts for suitability for the DNS root zone, I can attest that there are more homographs than people might initially suspect, and quite a few of them in Latin. In most, but not all cases, one of the two is a code point or code point sequence that exists for a very specialized purpose. Often only one of the forms is actually used in general orthographies and only one of the forms would therefore be expected to occur in a set of mnemonic identifiers. Unfortunately, it is not always the composite one that should be supported. For example, Unicode has several non-normalizable Latin digraphs that are encoded for special usage scenarios; in these cases the individual code points must be supported. In some cases, a letter and digit may be homographs (the example of க and ௧ (Tamil 'ka' and '1') as mentioned in the preceding post). Both would be supported for different purposes. Finally, in some cases, there's a combining mark that (given its name and general appearance) might be expected to yield the same appearance when applied to some base letters, as certain precomposed forms. In Latin, this applies to combining overlays, because, on principle, the Unicode standard does not decompose orthographic characters for which the shape is derived by striking through part or all of the letter form. Like the case of the Arabic script, any such characters needed for an as yet unencoded Latin orthography, would be encoded with a composite glyph shape, but without decomposition. *The proper response for IDNA2008* would be to inventorize these cases and *strongly warn* that they not be incorporated unexamined into general repertoires; or, if they have to be supported, that Label Generation Rulesets (aka IDN tables) support context or variant rules that prevent these from co-occurring in any minimal pair of labels. For language-specific IDN tables, it's often possible to eliminate one or the other alternative. For example, a Danish IDN table would rule out 0338 (combining slash), so that cannot exist alongside o-slash. For a Fula-specific IDN table, one would rule out the combining Hamza - it has not place in that orthography. Eliminating any particular homographs on an ad-hoc basis in IDN2008 by making one of the code points INVALID does not solve the general problem, but unnecessarily prevents language-specific solutions in a way that is at best inconsistent and at worst discriminatory. The Fula character is a good example of a pseudo-decomposable character that is needed for consistent encoding of a hitherto not fully supported orthography, while the code point sequence serves a specialized purpose elsewhere. It is very important, that whatever the solution is decided on for IDNA2008, that IETF not haphazardly single out a particular instance of a general pattern. A./ --------------030604070802050102080500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/20/2015 8:04 PM, "Martin J. Dürst" wrote:
P.S.: Please note that the comments above don't mean that I'm happy with the inclusion of U+08A1 in Unicode 7.0.0, and that I sincerely hope the Unicode Consortium will weight the problems of identifier confusability higher in their future decisions.

Given that an almost exactly parallel issue existed for a code point used in several Western European languages from Unicode 1.0, I think it would be wrong for Unicode to suddenly change the way non-Western scripts are encoded. Treating this particular case in isolation obscures the real issue and will possibly prevent or delay a proper design of identifier repertoires.

To put the issue in general terms, it concerns the fact that there are homographs in Unicode. These are two distinct code point sequences with normally identical appearance. In particular, the concern is with homographs that are present after normalization.

I'm very much on board with highlighting that issue, which is that applying NFC does not eliminate homographs. And, having just finished the exercise of reviewing the full repertoire of modern scripts for suitability for the DNS root zone, I can attest that there are more homographs than people might initially suspect, and quite a few of them in Latin.

In most, but not all cases, one of the two is a code point or code point sequence that exists for a very specialized purpose. Often only one of the forms is actually used in general orthographies and only one of the forms would therefore be expected to occur in a set of mnemonic identifiers.

Unfortunately, it is not always the composite one that should be supported. For example, Unicode has several non-normalizable Latin digraphs that are encoded for special usage scenarios; in these cases the individual code points must be supported.  In some cases, a letter and digit may be homographs (the example of க and ௧ (Tamil 'ka' and '1') as mentioned in the preceding post). Both would be supported for different purposes. Finally, in some cases, there's a combining mark that (given its name and general appearance) might be expected to yield the same appearance when applied to some base letters, as certain precomposed forms. In Latin, this applies to combining overlays, because, on principle, the Unicode standard does not decompose orthographic characters for which the shape is derived by striking through part or all of the letter form.

Like the case of the Arabic script, any such characters needed for an as yet unencoded Latin orthography, would be encoded with a composite glyph shape, but without decomposition.

The proper response for IDNA2008 would be to inventorize these cases and strongly warn that they not be incorporated unexamined into general repertoires; or, if they have to be supported, that Label Generation Rulesets (aka IDN tables) support context or variant rules that prevent these from co-occurring in any minimal pair of labels.

For language-specific IDN tables, it's often possible to eliminate one or the other alternative.

For example, a Danish IDN table would rule out 0338 (combining slash), so that <o, 0338> cannot exist alongside o-slash. For a Fula-specific IDN table, one would rule out the combining Hamza - it has not place in that orthography.

Eliminating any particular homographs on an ad-hoc basis in IDN2008 by making one of the code points INVALID does not solve the general problem, but unnecessarily prevents language-specific solutions in a way that is at best inconsistent and at worst discriminatory.

The Fula character is a good example of a pseudo-decomposable character that is needed for consistent encoding of a hitherto not fully supported orthography, while the code point sequence serves a specialized purpose elsewhere.

It is very important, that whatever the solution is decided on for IDNA2008, that IETF not haphazardly single out a particular instance of a general pattern.

A./
--------------030604070802050102080500-- From nobody Wed Jan 21 12:46:39 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17AE1A87DB for ; Wed, 21 Jan 2015 12:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 78TbumeSfG4c for ; Wed, 21 Jan 2015 12:43:23 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4A21A87A7 for ; Wed, 21 Jan 2015 12:43:23 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id fa1so3599253pad.8 for ; Wed, 21 Jan 2015 12:43:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9j95TjZ508xcZhG0zERD6Hh+6T8az+MD3a9wpucfocE=; b=MfeBZ6FycnccpgeRexVTsz/Is48BhWO84MfwbU1Gv0RGsy9IWfAcVRJay+3+e/sLsp hXVXqumYuXUYh3xM6i3TPSEhpk2MLvn8hLK/q4W/qaPlXv549/Zs4u9xVwlW+SZjVO/8 erqYgGvcY6hY82Z/SlCAbnFSdQxQ3/JtrmRjYWS+3Dchj2sPzD/+BgAYrTZVrCKwJq2V zLp+LhcCMam8LbdWPS1HqrMRS3jug6i+kxi+2WdPMm2+gUNkl7VT3J4TOlwZwghYqcmb 7KlTS6OAVzbvn7TNwCFMeFkjZFUyw40jMR6d1QPQHlcXX8mg//q+RIVlxFhM1DemU1ox eMLQ== X-Gm-Message-State: ALoCoQnkMI52UR/qIj+siL8of0NPXMUFI8/2SfP1Xvxo1DbmD4lHZGiTtkSthlgY1TlYWuakwsQQ X-Received: by 10.68.241.35 with SMTP id wf3mr66734217pbc.22.1421873002643; Wed, 21 Jan 2015 12:43:22 -0800 (PST) Received: from ?IPv6:2001:420:a44:1300:20e2:4832:18d3:c0d3? ([2001:420:a44:1300:20e2:4832:18d3:c0d3]) by mx.google.com with ESMTPSA id rl10sm6763957pbb.67.2015.01.21.12.43.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 12:43:22 -0800 (PST) Message-ID: <54C00F67.5050206@outer-planes.net> Date: Wed, 21 Jan 2015 13:43:19 -0700 From: "Matthew A. Miller" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Eliot Lear References: <20150119224357.16254.18122.idtracker@ietfa.amsl.com> <54BDC9E3.2050507@qti.qualcomm.com> <54BE029F.2090709@cisco.com> <54BF2546.9030006@it.aoyama.ac.jp> <882717E0412866628323024E@JcK-HP8200.jck.com> In-Reply-To: <882717E0412866628323024E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 21 Jan 2015 12:46:31 -0800 Cc: Barry Leiba , idna-update@alvestrand.no, Asmus Freytag , IETF JSON WG Subject: Re: [Json] Json and U+08A1 and related cases X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Jan 2015 20:43:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Replying in the (hopefully not vain) attempt to strip the recipient list to something our poor system can handle. Continue the conversation on this thread. Thanks, - -- your JSON WG co-chair On 1/21/15 12:26 PM, John C Klensin wrote: > (Changing subject line per Barry's request and addressing that > one issue only.) > > --On Wednesday, January 21, 2015 13:04 +0900 "\"Martin J. > Dürst\"" wrote: > >> ... >>> outside the context of a locale. >> >> There's no guarantee that all text in a Fula locale (e.g. on a >> computer with a Fula OS, if there ever is such a thing) > > Note that isn't "a Fula locale", but "a Fula locale that uses > the Arabic script to write the language". There are no known > such locales of even country-scope; Fula is normally written in > Latin characters and has been for at least a few centuries. > There are lots of problems with the analogy, but thinking about > Fula-in-Arabic in ordinary locale terms is a little bit like > thinking about Japanese-exclusively-in-Romanji (and Romanji with > a few characters that don't appear anywhere else in Latin > script) as a locale. Probably possible to make it work, but not > the way most of us usually think about things. > >> will >> have Behs with Hamzas above represented with U+08A1 (composed) >> rather than decomposed. >> بٔ U+0628 U+0654 (decomposed) may get in there from Arabic >> text easily. > > I presume that is one of the reasons TUS 7.0 says > "preferentially" should use the precombined (composed) form > rather than the decomposed one rather than something we would > recognize as "MUST". > >>> John Klensin >>> has explained the problem well in Section 2 of >>> draft-klensin-idna-5892upd-unicode70-03.txt. You may wish to >>> review that work, and ask i8n program for a copy of the draft >>> statement, because it may have security implications on your >>> work, in as much as i-json is used to pass identifiers. >> >> Given that JSON implementations, in contrast to IDNA, compare >> object member names codepoint-by-codepoint, the much more >> obvious addition to the security section would be to point out >> the potential consequences for precomposed/decomposed >> confusions in general. The chance that this becomes an actual >> issue is much much higher (although still rather low) in e.g. >> French or German than in Fula, where Arabic isn't even the >> main script used for writing the language. > > Agreed. And, fwiw, that would be my preferred solution. I > think Fula and U+08A1 are important only as illustrative > examples of what appears to me to be a very nasty situation when > the nature of the identifier(s) or their uses does not provide a > reliable language context. > >> P.S.: Please note that the comments above don't mean that I'm >> happy with the inclusion of U+08A1 in Unicode 7.0.0, and that >> I sincerely hope the Unicode Consortium will weight the >> problems of identifier confusability higher in their future >> decisions. > > Agreed, although the way in which the U+08A1 decision has been > defended, and the antecedents for it, do not predict to that > result. See below. > > > --On Wednesday, January 21, 2015 10:22 -0600 Nico Williams > wrote: > >> I thought that NFC was closed to new precompositions though new >> precompositions might be added to Unicode. That is, the NFC >> form of U+08A1 must be the same as the NFD form of U+08A1, >> which is to say: U+0628 U+0654. >> >> Is my memory wrong about that? > > That is the understanding that several -- I dare to say most or > all of the IDNAbis WG participants -- of us had. What has > actually occurred either violates that assumption or introduces > an extra case, depending on how one looks at the problem. We > understood that, if precompositions (your term) are added, they > would have decompositions and NFC of the character would yield > the decomposed form. That understanding derived both from what > the WG was told and from text in the Unicode Standard and UAX > #15 (see draft-klensin-idna-5892upd-unicode70-02, especially > Section 2.1, for details and references). > > But, while U+08A1 is abstract-character-identical and even > plausible-name-identical to U+0628 U+0654, it does _not_ > decompose into the latter. Instead, NFD(U+08A1) = NFC(U+08A1) = > U+08A1. NFC (U+0628 U+0654) is U+0628 U+0654 as one would > expect from the stability rules; from that perspective, it is > the failure of U+08A1 to have a (non-identity) decomposition > that is the issue. > > john > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUwA9mAAoJEOz0ck4QngW7rNwH/jaHvHhiz7UOUSr2ZcXLPdbg DvcA68c11dnPIAQ4Rx9QzRZB1RpPnukYWqanvh7wc+9nhd6oAhW2524b2PYDu20h ZPFcrz6ZBynrpXBCGoQIzCHX/1MLlc5Kk6miqaqJDSMwk9RbAqhpzqqpXBCQ/x2N +9M7gJ30V5/v+7f08nlqPsnobDGaOZGjlVn9V9GYkuFqGvP6eoHujYjoaYYKPxbZ ceRrrFkcGWTVQQZzO9Ft26grrB3e0sM7pklQ7hj6O/sqoi1UVEYCdB6PgqeptMnr IdVNNxhiYhruVaRGF9Y5UMd6YZh3yiAjB4XBwqg447r9mFy0q5s5m1wnBzp2jgg= =iIu4 -----END PGP SIGNATURE----- From nobody Thu Jan 22 05:01:16 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7981ACCE3; Thu, 22 Jan 2015 05:01:04 -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 xcWoxKNFqOfM; Thu, 22 Jan 2015 05:00:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E03331ACC8B; Thu, 22 Jan 2015 05:00:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122130054.7525.60159.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 05:00:54 -0800 Archived-At: Cc: meral.shirazipour@ericsson.com, json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Jari Arkko's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:01:07 -0000 Jari Arkko has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I should note that there was a Gen-ART review from Meral with some minor editorial observations. For instance, the first sentence of Section 3 could use improvement. These could be handled by the RFC Editor, too. From nobody Thu Jan 22 06:39:08 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049CD1ACC80; Thu, 22 Jan 2015 06:39:05 -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 zu8hSVsDmTHa; Thu, 22 Jan 2015 06:39:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE31A1ABF; Thu, 22 Jan 2015 06:39:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 06:39:03 -0800 Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 14:39:05 -0000 Ted Lemon has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is an editorial nit, which the RFC editor might catch, but they'd have to know about the distinction between double precision floating point and fixnums, so I figured I'd just mention it to be safe: In particular, an I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. The "in particular" at the beginning of this sentence has no antecedent, so it doesn't make sense to say it. You should just delete "in particular". I wonder if there was some text prior to this that got deleted in a previous revision... For applications which require the exact interchange of numbers with greater magnitude or precision (one example would be 64-bit integers), it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. What was the rationale for this? I don't know of a lot of platforms that don't support 64-bit integers, so this seems overly restrictive. I'm not raising this as a major issue because I am sure there _was_ a rationale, but I'd like to hear it. From nobody Thu Jan 22 07:07:33 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6141A044D; Thu, 22 Jan 2015 00:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, SPF_HELO_PASS=-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 11pxGUSU40DO; Thu, 22 Jan 2015 00:31:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BF91A0439; Thu, 22 Jan 2015 00:31:34 -0800 (PST) Received: from CY1PR0301MB0731.namprd03.prod.outlook.com (25.160.159.149) by CY1PR0301MB0731.namprd03.prod.outlook.com (25.160.159.149) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 08:31:11 +0000 Received: from CY1PR0301MB0731.namprd03.prod.outlook.com ([25.160.159.149]) by CY1PR0301MB0731.namprd03.prod.outlook.com ([25.160.159.149]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 08:31:11 +0000 From: Shawn Steele To: Andrew Sullivan Thread-Topic: Json and U+08A1 and related cases (was: Re: [Json] Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) Thread-Index: AQHQNbGJ7LXG9CxIJkyVjR8s4xAJJpzK+1AAgACTmoCAADyAYA== Date: Thu, 22 Jan 2015 08:31:10 +0000 Message-ID: References: <20150122043739.GE409@crankycanuck.ca> In-Reply-To: <20150122043739.GE409@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.34.94.236] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CY1PR0301MB0731; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0731; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(51444003)(189002)(106116001)(106356001)(62966003)(2900100001)(76576001)(40100003)(77156002)(105586002)(99286002)(76176999)(50986999)(54606007)(54356999)(54206007)(122556002)(102836002)(2950100001)(68736005)(46102003)(110136001)(230783001)(33656002)(2656002)(86362001)(74316001)(101416001)(92566002)(97736003)(87936001)(64706001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0731; H:CY1PR0301MB0731.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 08:31:10.5020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0731 Archived-At: X-Mailman-Approved-At: Thu, 22 Jan 2015 07:07:26 -0800 Cc: Eliot Lear , Pete Resnick , =?utf-8?B?TWFyayBEYXZpcyA/77iP?= , "linuxwolf@outer-planes.net" , "json@ietf.org" , Tim Bray , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , John C Klensin , "idna-update@alvestrand.no" , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Barry Leiba , "json-chairs@tools.ietf.org" Subject: Re: [Json] Json and U+08A1 and related cases (was: Re: Barry Leiba's Discuss on draft-ietf-json-i-json-05: (with DISCUSS and COMMENT)) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 08:31:36 -0000 PiA+IFRoaXMgaXMgc2ltaWxhciB0byBzcGVsbGluZyBIYXdhaSdJIHdpdGggb3Igd2l0aG91dCBh biDKu29raW5hIChIYXdhacq7aSkuICBBIGh1bWFuIHRoaW5rcyB0aGV5IGxvb2sgdGhlIHNhbWUs IGJ1dCB0aGV5IGFyZW4ndCB0aGUgc2FtZS4gIA0KDQo+IEkgZG8gbm90IHRoaW5rIGl0IGlzIHNp bWlsYXIgdG8gdGhhdCBjYXNlLiAgYXMgSSB1bmRlcnN0YW5kIGl0LCB0aGVyZSBpcyBubyBfaW4g cHJpbmNpcGxlXyB3YXkgb25lIGNvdWxkIGRpc3Rpbmd1aXNoIHRoZXNlIGNoYXJhY3Rlci9jaGFy YWN0ZXIgc2VxdWVuY2VzIGluIHByYWN0aWNlLCBldmVuIHdpdGggYXR0ZW50aW9uIHRvIHRoZSBh cHBlYXJhbmNlIG9mIGNoYXJhY3RlcnMuDQoNCkknbSBjb25mdXNlZCBvbmUgaXMgdXNlZCBmb3Ig b25lIHRoaW5nIGFuZCB0aGUgb3RoZXIgaXMgdXNlZCBmb3IgYW5vdGhlciB0aGluZy4gIFNvIHRo ZXkncmUgZGlzdGluZ3Vpc2hhYmxlLiAgQW5kIHlvdSBjYW4gdGVsbCB0aGUgZGlmZmVyZW5jZSBi eSBjb250ZXh0LiAgVGhleSBtYXkgbG9vayB0aGUgc2FtZSwgYnV0IHRoZXJlIGFyZSBudW1lcm91 cyBvdGhlciBob21vZ3JhcGhzLg0KDQpJJ2QgYWxzbyBhcmd1ZSB0aGF0IGVzemV0dCBhbmQgc3Mg aXMgYW4gZXZlbiAid29yc2UiIGNhc2UgKGZyb20gbXkgdW5kZXJzdGFuZGluZykuICBBdCBsZWFz dCBldmVyeW9uZSBrbm93cyB0aGF0IHRob3VnaCBzb21lIHdvcmRzIGhhdmUgcHJlZmVycmVkIGZv cm1zLCB0aGUgc3MgaXMgb2Z0ZW4gYWx0ZXJuYXRlIHNwZWxsaW5nIGZvciBlc3pldHQuICBUaGV5 J3JlIHRoZSBzYW1lIHNjcmlwdCwgYW5kIGVpdGhlciBjb3VsZCBhcHBlYXIgaW4gYSB3b3JkLiAg QXQgbGVhc3QgaW4gdGhlIFUrMDhBMSBjYXNlIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBz aG91bGQgbm90IGFwcGVhciBpbnRlcmNoYW5nZWFibHkgd2l0aCB0aGUgaG9tb2dyYXBoLCBzbyBv bmx5IG1hbGljaW91cyB1c2VycyB3b3VsZCB1c2UgdGhlIHdyb25nIG9uZSBpbiB0aGUgd3Jvbmcg cGxhY2UsIHdoZXJlYXMgaW4gR2VybWFuIHRoZXJlIGFyZSBsZWdpdGltYXRlIHJlYXNvbnMgZm9y IGNvbmZ1c2luZyB0aGUgdHdvIGZvcm1zLiAgSWYgd2UgY2FuIHNvbHZlIEdlcm1hbiAoYnVuZGxl IG9yIGJsb2NrKSwgdGhlbiB3ZSBjYW4gc29sdmUgdGhpcyBjYXNlLg0KDQo+IFdlJ3JlIGp1c3Qg dHJ5aW5nIHRvIHVuZGVyc3RhbmQuICANCg0KSXQgc2VlbXMgdG8gZ28gYmV5b25kIHVuZGVyc3Rh bmRpbmcuICBPdmVyc2ltcGxpZnlpbmcsIGJ1dCBVbmljb2RlIGZvbGtzIGhhdmUgc2FpZCAidGhl eSdyZSBkaWZmZXJlbnQsIHRoZXkncmUgdXNlZCBpbiBkaWZmZXJlbnQgY29udGV4dHMuICBZZXMg dGhleSBsb29rIHRoZSBzYW1lLCBidXQgdGhleSdyZSBkaWZmZXJlbnQgYW5kIGl0J3Mgbm90IGFw cHJvcHJpYXRlIHRvIG1peCB0aGVtLiIgIFRoYXQgc2VlbXMgZmFpcmx5IGVhc3kgdG8gdW5kZXJz dGFuZCwgaG93ZXZlciB0aGVyZSBpcyBzdGlsbCBkaXNhZ3JlZW1lbnQgYWJvdXQgd2hldGhlciBv ciBub3QgdGhleSBzaG91bGQgYmUgInRoZSBzYW1lIi4gDQoNCj4gVGhlIHJlcG9ydHMga2VlcCBn ZXR0aW5nIHdvcnNlLCBob3dldmVyLg0KDQpUaGVuIHBhcnRpY2lwYXRlIDopICBUaGVyZSBhcmUg dmVyeSBzbWFydCBwZW9wbGUgaW4gdGhlIFVUQy4gIFRoZXJlIGhhdmUgYmVlbiBzb21lIHVuZm9y dHVuYXRlIHRoaW5ncyBpbiBoaW5kc2lnaHQsIGhvd2V2ZXIgVW5pY29kZSBsZWFybnMgYW5kIGRv ZXMgYmV0dGVyLiAgSSdtIHJlYXNvbmFibHkgY29uZmlkZW50IHRoYXQgdGhleSdyZSBkb2luZyB0 aGUgYmVzdCBwb3NzaWJsZSBqb2Igb2YgYWNjb21tb2RhdGluZyB0aGUgcmVxdWVzdHMgYW5kIHJl cXVpcmVtZW50cyB3aXRoIHRoZSBhcHByb3ByaWF0ZSBhbW91bnQgb2YgY29uc2lkZXJhdGlvbi4g IFNvbWV0aW1lcyBJIGhhdmUgZGlmZmVyZW50IG9waW5pb25zLCBidXQgdGhpcyBpc24ndCBhbiBl YXN5IHNwYWNlLCBhbmQgdGhlIG1vcmUgcmVndWxhciBVVEMgcGFydGljaXBhbnRzIGtub3cgd2F5 IG1vcmUgdGhhbiBJIGFib3V0IGhvdyBzY3JpcHRzIHdvcmsuDQoNCk9uZSBvZiB0aGUgb3RoZXIg Y29tbWVudHMgc3RhcnRlZCB0byBtb3ZlIGJleW9uZCB0aGUgIml0IHNob3VsZG4ndCBiZSB0aGlz IHdheSwgd2h5IGlzIGl0IHRoaXMgd2F5PyIgYW5kIHN0YXJ0ZWQgYXNraW5nIGhvdyB0byBoYW5k bGUgaXQgYXMgaXQgaXMgb2J2aW91c2x5IGEgaG9tb2dyYXBoIGFuZCB0aGF0IGNvdWxkIGJlIGNv bmZ1c2luZyB0byB1c2Vycy4gIEkgdGhpbmsgdGhhdCB0aGlzIHNob3VsZCBiZSBoYW5kbGVkIGFz IGFueSBvdGhlciBob21vZ3JhcGgsIHdoaWNoIHNlZW1zIHRvIGxlYWQgdG8gcHJvaGliaXQgKGlu YXBwcm9wcmlhdGUgaW4gdGhpcyBjYXNlIGJlY2F1c2UgaXQgd291bGQgcHJldmVudCB3b3JkcyBm cm9tIGJlaW5nIHNwZWxsZWQgYXMgZGVzaWduZWQpLCBidW5kbGUsIG9yIGJsb2NrIG9uZSBpZiB0 aGUgb3RoZXIgaXMgcmVnaXN0ZXJlZCBmaXJzdC4gIA0KDQotU2hhd24NCg== From nobody Thu Jan 22 07:22:01 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BE31ACCD8; Thu, 22 Jan 2015 07:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUa01O2dylEv; Thu, 22 Jan 2015 07:21:45 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90881A8BB4; Thu, 22 Jan 2015 07:21:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=www.ccil.org ident=www-data) by earth.ccil.org with esmtp (Exim 4.72) (envelope-from ) id 1YEJZn-0001Ds-Px; Thu, 22 Jan 2015 10:21:43 -0500 Received: from 171.159.194.11 (SquirrelMail authenticated user cowan) by www.ccil.org with HTTP; Thu, 22 Jan 2015 10:21:43 -0500 Message-ID: <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> In-Reply-To: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 10:21:43 -0500 From: cowan@ccil.org To: "Ted Lemon" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: ClamAV 0.98.1 on earth.ccil.org; Thu, 22 Jan 2015 10:21:43 -0500 Archived-At: Cc: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 15:21:49 -0000 Ted Lemon scripsit: > In particular, an I-JSON sender cannot expect a receiver to treat an > integer whose absolute value is greater than 9007199254740991 (i.e., > that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. > > The "in particular" at the beginning of this sentence has no antecedent, > so it doesn't make sense to say it. The antecedent is the previous paragraph: the restriction on integers is a direct consequence of the restriction to IEEE doubles. > What was the rationale for this? I don't know of a lot of platforms > that don't support 64-bit integers, so this seems overly restrictive. > I'm not raising this as a major issue because I am sure there _was_ a > rationale, but I'd like to hear it. In a word: JavaScript, because it has only IEEE doubles. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "Hacking is the true football." --F.W. Campbell (1863) in response to a successful attempt to ban shin-kicking from soccer. Today, it's biting. From nobody Thu Jan 22 07:38:53 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1911ACCF6; Thu, 22 Jan 2015 07:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDaHQlUPaKpT; Thu, 22 Jan 2015 07:38:42 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDDA1ACCF2; Thu, 22 Jan 2015 07:38:42 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 0608CDA0350; Thu, 22 Jan 2015 15:38:42 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DE8E853E080; Thu, 22 Jan 2015 07:38:41 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 22 Jan 2015 07:38:41 -0800 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset="iso-8859-1" From: Ted Lemon X-Priority: 3 (Normal) In-Reply-To: <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> Date: Thu, 22 Jan 2015 10:38:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <52AD794B-B264-4722-9509-4CD37E75F09C@nominum.com> References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> To: X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 15:38:44 -0000 On Jan 22, 2015, at 10:21 AM, wrote: > In a word: JavaScript, because it has only IEEE doubles. D'oh, right. Javascript's data model is so absurd that its limitations = tend of slip out of my recollection when I haven't been using it = recently. I suppose most readers of this document would not fail to = see this connection, but it might be worth saying "In particular, since = Javascript JSON readers only support floating point, ..." But that's up to you--I'm fine either way. From nobody Thu Jan 22 07:52:30 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F241A1AC9 for ; Thu, 22 Jan 2015 07:52:28 -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] 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 CPmQq5f4SeQB for ; Thu, 22 Jan 2015 07:52:27 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC2D1A1AD0 for ; Thu, 22 Jan 2015 07:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t0MFqJWo010148; Thu, 22 Jan 2015 16:52:19 +0100 (CET) Received: from alma.local (p5DCCCF76.dip0.t-ipconnect.de [93.204.207.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kSp5H2w82z83TF; Thu, 22 Jan 2015 16:52:19 +0100 (CET) Message-ID: <54C11CB2.2020709@tzi.org> Date: Thu, 22 Jan 2015 16:52:18 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ted Lemon , cowan@ccil.org References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> <52AD794B-B264-4722-9509-4CD37E75F09C@nominum.com> In-Reply-To: <52AD794B-B264-4722-9509-4CD37E75F09C@nominum.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: json-chairs@tools.ietf.org, json@ietf.org, linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 15:52:29 -0000 On 2015-01-22 16:38, Ted Lemon wrote: > Javascript's data model is so absurd Off-IESG comment: The working group does have a vocal minority that doesn't think all JSON considerations should be overridden by the quirks of JavaScript. However, I-JSON specifically is meant to be inclusive, and thus lowest-common denominator, so there is rough consensus on what it should be. The collateral damage that is happening however is that I-JSON is starting to influence other documents that it maybe shouldn't. E.g. YANG for JSON -- is it really necessary to represent 64-bit YANG counters as JSON strings instead of numbers? Gre, Carsten From nobody Thu Jan 22 09:02:43 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D171ACD2E for ; Thu, 22 Jan 2015 09:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEYtx-kKpJMN for ; Thu, 22 Jan 2015 09:02:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B341ACD31 for ; Thu, 22 Jan 2015 09:02:31 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id EA50613F7CA; Thu, 22 Jan 2015 18:02:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421946150; bh=OwHL8tg/sYeMGNnuDO3utn93KHrzh6Kf7SHHexk0CyI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N7FKF5nJgJNVQIcWqjT53+rkFI+LRouXTwDEcrG8DmQkFQtc2RTx+RKyeIAZVLZVN PQ7UvhetB+uEI7w3iiMg5GHoQYFepOG1kLwBA/dFQvtHEZQztAfBbNkJ5glnsMwpy6 0UDGyM3JrVPXLtLxRdDGG7imizFZj1eGzhQRDgfI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <54C11CB2.2020709@tzi.org> Date: Thu, 22 Jan 2015 18:02:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> <52AD794B-B264-4722-9509-4CD37E75F09C@nominum.com> <54C11CB2.2020709@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: cowan@ccil.org, linuxwolf@outer-planes.net, JSON WG , Ted Lemon , draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 22 Jan 2015 17:02:34 -0000 > On 22 Jan 2015, at 16:52, Carsten Bormann wrote: >=20 > On 2015-01-22 16:38, Ted Lemon wrote: >> Javascript's data model is so absurd >=20 > Off-IESG comment: >=20 > The working group does have a vocal minority that doesn't think all = JSON > considerations should be overridden by the quirks of JavaScript. >=20 > However, I-JSON specifically is meant to be inclusive, and thus > lowest-common denominator, so there is rough consensus on what it = should be. >=20 > The collateral damage that is happening however is that I-JSON is > starting to influence other documents that it maybe shouldn't. > E.g. YANG for JSON -- is it really necessary to represent 64-bit YANG > counters as JSON strings instead of numbers? Right, and the result is that *all* receiving applications have to parse = such string-encoded numbers separately even though their JSON parser is = fully capable to do it for them straight away. Lada >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 22 10:20:07 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9AD1ACEDC for ; Thu, 22 Jan 2015 10:19:59 -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 ZokCxXl8yuKN; Thu, 22 Jan 2015 10:19:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D541ACEF0; Thu, 22 Jan 2015 10:19:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122181956.9433.22443.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 10:19:56 -0800 From: IETF Secretariat Archived-At: Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:19:59 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ From nobody Thu Jan 22 18:00:02 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622BC1A8945 for ; Thu, 22 Jan 2015 18:00:00 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9YRltdxdkdo for ; Thu, 22 Jan 2015 17:59:57 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E643B1A1A5E for ; Thu, 22 Jan 2015 17:59:56 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so446693lbv.4 for ; Thu, 22 Jan 2015 17:59:55 -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:from:date :message-id:subject:to:cc:content-type; bh=0kMOGMn7ud/4jUWm6VC4Xdn3UI5MYEI2p+U8MPW76ik=; b=YnEifQj0EunCpvj5h7KTlZh9rx8Q4Z6ZCI2DCusLHBlpFbEp0X0m8W7DlKe+0Wb0c7 JCpXMSgxBS3g1rrkpVESYoVvhIF4mFoj16XWILcnIekefoksQvnse3OPBXGllN4BMwCN 0kc9Lf/nnndZvY8bXwBIIynMGo2b1bc0ouRLOLARVpPmh6RjeRZvcCyrb/pCWroaWLiK 2p/4NQ9sI89jbCG3nOxlbISbPAuaVHigiQl37Sxl67JVjQeO1JrL3iLgOoeAMdgAICb5 QbusxWTlq4wVqov4rvsVWJ4zfO5EnTGXzOaqsNq69y78dQi8wUEhNiX1K6mXGt/Bh3Gs Aqyg== X-Gm-Message-State: ALoCoQlIkDl8FSYVg0TBHZLEFceOvstJgM3WEeQbT7Ul03geU33/Kf/+BmZ7Hkyz7goBAy7kC0Gv X-Received: by 10.152.198.200 with SMTP id je8mr4703614lac.93.1421978395404; Thu, 22 Jan 2015 17:59:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Thu, 22 Jan 2015 17:59:35 -0800 (PST) X-Originating-IP: [173.160.171.253] In-Reply-To: <20150119140118.824.91479.idtracker@ietfa.amsl.com> References: <20150119140118.824.91479.idtracker@ietfa.amsl.com> From: Tim Bray Date: Thu, 22 Jan 2015 17:59:35 -0800 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11348a4a2303ad050d48257d Archived-At: Cc: Juergen Schoenwaelder , Matt Miller , "json@ietf.org" , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" Subject: Re: [Json] Benoit Claise's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 02:00:00 -0000 --001a11348a4a2303ad050d48257d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My opinion is that while it is perhaps a little unusual not to define conformance, I don=E2=80=99t think doing so would increase the *usefulness*= of the draft. The intent is that the draft provide a complete, crisp definition of an entity called an =E2=80=9CI-JSON message=E2=80=9D and protocol design= ers make use of it by saying that their message payloads =E2=80=9CMUST be I-JSON messages= =E2=80=9D. It honestly hadn=E2=80=99t crossed my mind that people might want to claim = official conformance with the protocol-design recommendations. If there=E2=80=99s a perception that this is a likely scenario, it would not be that difficult to include a definition of the notion of conformance. On Mon, Jan 19, 2015 at 6:01 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-json-i-json-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There is still a ongoing discussion between J. Sch=C3=B6nw=C3=A4lder (OPS= -DIR) and > Tim Bray. > > On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote: > > On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> My understanding is that compliance to I-JSON means compliance to > >> section 2 of this document. Perhaps it makese sense to clarify this > >> (in particular if my interpretation is wrong). > >> > > > > Hmm, good point. =E2=80=8BThe draft currently doesn=E2=80=99t mention = compliance; all > it > > does is give a syntactic definition of something called an =E2=80=9CI-J= SON > > message=E2=80=9D. The notion was that other specs which wanted to requ= ire the > use > > of I-JSON should say something like =E2=80=9CThe message body must be a= n > I-JSON > > message [RFCXXXX]=E2=80=9D. I think that would work fine, but I wonder= if > others, > > like you, will be bothered by the absence of a specification of > > =E2=80=9Ccompliance=E2=80=9D. > > > > I am raising this question since I think the draft goes somewhat > beyond simply defining I-JSON (which I believe is the material > contained in section 2). > > In particular, the I-D uses RFC 2119 language in a section titled > "Protocol-design Recommendations". It is not clear to me how these > recommendations have been selected or why they are part of an I-JSON > specification. This applies mostly to sections 4.3 and 4.4. Anyway, > since these sections use RFC 2119 requirements language, I am > wondering what happens if a protocol complies to section 2 but not all > of section 4 - is it using I-JSON? I hope so, but it might be good to > make this clear. > > /js > > > ---------------------------------------------------- > > Editorial nit: > > - s/values in in ISO 8601/values in ISO 8601/ > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11348a4a2303ad050d48257d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= ;editor-hat>

My opinio= n is that while it is perhaps a little unusual not to define conformance, I= don=E2=80=99t think doing so would increase the *usefulness* of the draft.= =C2=A0 The intent is that the draft provide a complete, crisp definition of= an entity called an =E2=80=9CI-JSON message=E2=80=9D and protocol designer= s make use of it by saying that their message payloads =E2=80=9CMUST be I-J= SON messages=E2=80=9D. =C2=A0

It honestly hadn=E2=80=99t crossed my mind that people might want to c= laim official conformance with the protocol-design recommendations.=C2=A0 I= f there=E2=80=99s a perception that this is a likely scenario, it would not= be that difficult to include a definition of the notion of conformance.

On Mon, = Jan 19, 2015 at 6:01 AM, Benoit Claise <bclaise@cisco.com> w= rote:
Benoit Claise has entered the follo= wing ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is still a ongoing discussion between J. Sch=C3=B6nw=C3=A4lder (OPS-D= IR) and
Tim Bray.

On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote:
> On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
>
>> My understanding is that compliance to I-JSON means compliance to<= br> >> section 2 of this document. Perhaps it makese sense to clarify thi= s
>> (in particular if my interpretation is wrong).
>>
>
> Hmm, good point.=C2=A0 =E2=80=8BThe draft currently doesn=E2=80=99t me= ntion compliance; all
it
> does is give a syntactic definition of something called an =E2=80=9CI-= JSON
> message=E2=80=9D.=C2=A0 The notion was that other specs which wanted t= o require the
use
> of I-JSON should say something like =E2=80=9CThe message body must be = an
I-JSON
> message [RFCXXXX]=E2=80=9D.=C2=A0 I think that would work fine, but I = wonder if
others,
> like you, will be bothered by the absence of a specification of
> =E2=80=9Ccompliance=E2=80=9D.
>

I am raising this question since I think the draft goes somewhat
beyond simply defining I-JSON (which I believe is the material
contained in section 2).

In particular, the I-D uses RFC 2119 language in a section titled
"Protocol-design Recommendations". It is not clear to me how thes= e
recommendations have been selected or why they are part of an I-JSON
specification. This applies mostly to sections 4.3 and 4.4. Anyway,
since these sections use RFC 2119 requirements language, I am
wondering what happens if a protocol complies to section 2 but not all
of section 4 - is it using I-JSON? I hope so, but it might be good to
make this clear.

/js


----------------------------------------------------

Editorial nit:

- s/values in in ISO 8601/values in ISO 8601/


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



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11348a4a2303ad050d48257d-- From nobody Thu Jan 22 18:02:39 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7994F1A8945 for ; Thu, 22 Jan 2015 18:02:33 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ooWh4t-2QPm for ; Thu, 22 Jan 2015 18:02:31 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4581A1A9C for ; Thu, 22 Jan 2015 18:02:31 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so4765811lbd.2 for ; Thu, 22 Jan 2015 18:02: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:from:date :message-id:subject:to:cc:content-type; bh=DgiZYfPJ7GxTs/+Bi60ymt4CQjP6YY6HQEUSFcBFGQk=; b=VtuSrO2RWkj6IYwxh+t9hnltcoPlVaeqcMyo3lU4UAq/tcReSG8mLnZ1INpoQZd8Qe 3CTs2EQBbro2doQmXmrgJoHVxwJZ/zvka64nH95fcO3/P9EKjiYvGoer0qxRuQ2ZF7vT XE23sV7iN2f/agq9etNegBbqgVqS44oKx+jmhcG5NSo7oMx0Xc7SvLOL0USyanR/yQS1 ESN6FWIwRmdk+JaRZBNOdp3THZfqVg8y529nG+aVzusZAiyDJZxLRGoepUCjQC/TpmY1 2Dn4YT56W+SL3ehz6szs9V5E4JpPnzpswU0D3vso6xV/RVIFohHRIVBhRtxWewiF8HnF +hWQ== X-Gm-Message-State: ALoCoQmOD3zAxCJK92v3iAx5nkHg4kMePj7mSVuUlTwDrl9Elf+1ir/JyU+AC0vs3hPqR2rCYCt/ X-Received: by 10.152.21.134 with SMTP id v6mr4809492lae.13.1421978549571; Thu, 22 Jan 2015 18:02:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Thu, 22 Jan 2015 18:02:09 -0800 (PST) X-Originating-IP: [173.160.171.253] In-Reply-To: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> From: Tim Bray Date: Thu, 22 Jan 2015 18:02:09 -0800 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e0158b74e5367b2050d482e5e Archived-At: Cc: "json-chairs@tools.ietf.org" , "json@ietf.org" , Matt Miller , The IESG , draft-ietf-json-i-json.all@tools.ietf.org Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 02:02:33 -0000 --089e0158b74e5367b2050d482e5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought that claiming that I-JSON offered qualitatively better security was a little immodest. If there=E2=80=99s general agreement with Kathleen = and SecDir, I=E2=80=99d be happy to introduce such language. There are two opti= ons: 1. Note that =E2=80=9C I-JSON restricts and limits some of =E2=80=8B=E2=80=8B the danger =E2=80=8B=E2=80=8B ous formats of the original JSON, therefore it might be considered =E2=80=8B=E2=80=8B more secure =E2=80=8B=E2=80=8B=E2=80=9D 2. Assert that security-critical usages of JSON should (or SHOULD?) use I-JSON On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-json-i-json-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with the SecDir reviewer in his assessment of this draft after > reading it. I'm putting this in as comments/suggestions to be considered > as the security considerations really should be in the JSON document. If > any considerations are missing, that is where I'd expect to see them. > The JSON format is not simple, so agree with the SecDir reviewer that > one would have expected additional handling considerations for security > purposes to be in that document. They don't need to be listed in this > one. > > Having said that, it might be good idea to add text to the security > considerations section, to state that I-JSON restricts and limits some > of > the dangerous formats of the original JSON, therefore it might be > considered > more secure than the original JSON. Perhaps also mention that > security critical usages of the JSON should use I-JSON > (perhaps even provide references to the jose specifications). > https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html > > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e0158b74e5367b2050d482e5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= ;editor-hat>

I thought= that claiming that I-JSON offered qualitatively better security was a litt= le immodest.=C2=A0 If there=E2=80=99s general agreement with Kathleen and S= ecDir, I=E2=80=99d be happy to introduce such language. There are two optio= ns:
1. Note tha= t =E2=80=9C=C2=A0I-JSON=C2=A0restricts and limits some=C2=A0of
=E2=80=8B=E2=80=8B=C2=A0
t= he danger
=E2=80=8B=E2=80=8B
ous formats of the original=C2=A0JSON, therefore it might be=C2=A0consid= ered
=E2=80=8B= =E2=80=8B=C2=A0
more secure
=E2=80=8B=E2=80=8B=E2=80= =9D
2. Assert that security-cr= itical usages of JSON should (or SHOULD?) use I-JSON

On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Mor= iarty <Kathleen.Moriarty.ietf@gmail.com> wrot= e:
Kathleen Moriarty has entered the foll= owing ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir reviewer in his assessment of this draft after
reading it.=C2=A0 I'm putting this in as comments/suggestions to be con= sidered
as the security considerations really should be in the JSON document.=C2=A0= If
any considerations are missing, that is where I'd expect to see them. The JSON format is not simple, so=C2=A0 agree with the SecDir reviewer that=
one would have expected additional handling considerations for security
purposes to be in that document.=C2=A0 They don't need to be listed in = this
one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some
of
the dangerous formats of the original JSON, therefore it might be
considered
more secure than the original JSON.=C2=A0 Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/= msg05380.html





--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--089e0158b74e5367b2050d482e5e-- From nobody Thu Jan 22 18:09:05 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3072E1A00C6 for ; Thu, 22 Jan 2015 18:08:52 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INby5xNbp_Vh for ; Thu, 22 Jan 2015 18:08:49 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9E81A003B for ; Thu, 22 Jan 2015 18:08:48 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id em10so28260378wid.3 for ; Thu, 22 Jan 2015 18:08:47 -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:from:date :message-id:subject:to:cc:content-type; bh=FuabMT1VReMQG9AfN9OjWChiKp+libBRIGTMpQkcRLg=; b=V8lWN9yoFRXxaMAzBLl1RCZfPpalZ6S+veQbVo/r7KXAGtou0NTXhkTYdUyvBktETD r4BJEauR2E05HFKkbnAd5ZVPBoP7CLU3su1UoiLrS/Z0CwejETPxrQCUC2gHQElmUGz9 Y3bc/rhHp+sn5mhiHOpMnB/FRTWouuUqOvwLsBR+2yCBst7I+XrBZNMOsp1W2ifWvFRs V9EdEblXFxBFQ9BR93/g1c89ODhNtXT4F5iPFCCQocbjtYMDdCdYiIOY3nQai1nFpNUS twqpGXgHlBuIiE9q9n5eqV+p4RMn5bpYCLhs7TtoBxyhJqZ/vCes2W1Ja7B3lcUDY8um NKyw== X-Gm-Message-State: ALoCoQltycG25mUdWRCfAmn2A8WwLmk5utSbqgTP1vrBJ1upKbUw8A6OGD4UA2ZwCYf7ItcOujFG X-Received: by 10.194.200.1 with SMTP id jo1mr9252092wjc.64.1421978927358; Thu, 22 Jan 2015 18:08:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.11.100 with HTTP; Thu, 22 Jan 2015 18:08:27 -0800 (PST) X-Originating-IP: [173.160.171.253] In-Reply-To: <20150119232839.19662.13834.idtracker@ietfa.amsl.com> References: <20150119232839.19662.13834.idtracker@ietfa.amsl.com> From: Tim Bray Date: Thu, 22 Jan 2015 18:08:27 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b87501cd7fac5050d484433 Archived-At: Cc: Matt Miller , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 02:08:52 -0000 --047d7b87501cd7fac5050d484433 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 19, 2015 at 3:28 PM, Stephen Farrell wrote: > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > - 2.1: I've > =E2=80=8B=E2=80=8B > no idea what Surrogate or Noncharacter > =E2=80=8B=E2=80=8B > means he > =E2=80=8B=E2=80=8B > re - a precise reference would be good for me. > =E2=80=8B=E2=80=8B > And the e > =E2=80=8B=E2=80=8B > xamples don't help me. So I agree with > =E2=80=8B=E2=80=8B > Barry's di > =E2=80=8B=E2=80=8B > scuss. > =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BYes. I have an action item to introduce the appropriate r= eferences from [UNICODE]=E2=80=8B =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > - 4.3: Did the WG discuss whether to require/encourage > =E2=80=8B=E2=80=8B > inclusion/exclusion of 00 values and timezones in > =E2=80=8B=E2=80=8B > times? E.g. is there a preference for 20150119T2304Z or > =E2=80=8B=E2=80=8B > 20150119T230400Z which represent the same time. > =E2=80=8B=E2=80=8B =E2=80=8BNot terribly much. The recommendation is pretty well a straight c= opy from RFC4287, where that was intensively discussed, on the grounds that it was probably a best practice.=E2=80=8B =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > - 4.3: I'm also a bit surprised you don't say that UTC > =E2=80=8B=E2=80=8B > is the default TZ. I think those time rules do help > =E2=80=8B=E2=80=8B > interoperability so defining defaults would have been > =E2=80=8B=E2=80=8B > an improvement. Why is that? (I don't think 3339 does > =E2=80=8B=E2=80=8B > that or does it?) > =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8BI=E2=80=99m pretty sure that this discussion never happened. Whic= h is leading me to the conclusion that it would be useful for there to be some AppsArea discussion on best practices for RFC3339 dates. However, I=E2=80=99m not c= onvinced that asserting the default timezone would noticeably help interoperability. > > - 4.4: I don't recall them so have had to track down > the difference between base64 and base64url and check > I'm using the right APIs over and over. That might be > because I only write code sporadically (and badly:-) > and forget stuff in between, but an example of the > difference (possibly parenthetical) would help me a > bit, just so's I could look at a value I generate and > spot I've done it wrong again. > =E2=80=8BBase64url is pretty widely used because the characters that are re= moved from the repertoire are troublesome in a variety of contexts and, well, hey, *anything* might show up in a URI these days. You don=E2=80=99t reall= y have to track down the difference - every base64 library these days has an option saying =E2=80=9Cgenerate URL form=E2=80=9D.=E2=80=8B --047d7b87501cd7fac5050d484433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= ;editor-hat>

On Mon, J= an 19, 2015 at 3:28 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:
=E2=80=8B=E2=80=8B

=E2= =80=8B=E2=80=8B
- 2.1: I've
=E2=80=8B=E2=80=8B
no idea what Surrog= ate or Noncharacter
=E2= =80=8B=E2=80=8B
means he
=E2=80=8B=E2=80=8B
re - a precise reference wo= uld be good for me.
=E2= =80=8B=E2=80=8B
And the e
=E2=80=8B=E2=80=8B
xamples don't help me.= So I agree with
=E2= =80=8B=E2=80=8B
Barry's di
=E2=80=8B=E2=80=8B
scuss.
=E2=80=8B=E2= =80=8B
=E2=80= =8B=E2=80=8B
= =E2=80=8B=E2=80=8BYes. I have an action item to introduce the appropriate r= eferences from [UNICODE]=E2=80=8B
=E2=80=8B=E2=80=8B

=E2= =80=8B=E2=80=8B
- 4.3: Did the WG discuss whether to require/encourage=
=E2= =80=8B=E2=80=8B
inclusion/exclusion of 00 values and timezones in
=E2= =80=8B=E2=80=8B
times? E.g. is there a preference for 20150119T2304Z o= r
=E2= =80=8B=E2=80=8B
20150119T230400Z which represent the same time.
=E2= =80=8B=E2=80=8B

=E2=80=8BNot terribly much.=C2=A0 The recommendation is pre= tty well a straight copy from RFC4287, where that was intensively discussed= , on the grounds that it was probably a best practice.=E2=80=8B
=
=E2=80=8B=E2=80= =8B
=E2= =80=8B=E2=80=8B

=E2= =80=8B=E2=80=8B
- 4.3: I'm also a bit surprised you don't say = that UTC
=E2= =80=8B=E2=80=8B
is the default TZ. I think those time rules do help
=E2= =80=8B=E2=80=8B
interoperability so defining defaults would have been<= br>
=E2= =80=8B=E2=80=8B
an improvement. Why is that? (I don't think 3339 d= oes
=E2= =80=8B=E2=80=8B
that or does it?)
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8BI=E2=80=99m prett= y sure that this discussion never happened.=C2=A0 Which is leading me to th= e conclusion that it would be useful for there to be some AppsArea discussi= on on best practices for RFC3339 dates.=C2=A0 However, I=E2=80=99m not conv= inced that asserting the default timezone would noticeably help interoperab= ility. =C2=A0

- 4.4: I don't recall them so have had to track down
the difference between base64 and base64url and check
I'm using the right APIs over and over.=C2=A0 That might be
because I only write code sporadically (and badly:-)
and forget stuff in between, but an example of the
difference (possibly parenthetical) would help me a
bit, just so's I could look at a value I generate and
spot I've done it wrong again.

=E2=80=8BBase64url is pr= etty widely used because the characters that are removed from the repertoir= e are troublesome in a variety of contexts and, well, hey, *anything* might= show up in a URI these days.=C2=A0 You don=E2=80=99t really have to track = down the difference - every base64 library these days has an option saying = =E2=80=9Cgenerate URL form=E2=80=9D.=E2=80=8B

--047d7b87501cd7fac5050d484433-- From nobody Thu Jan 22 18:15:47 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8611A00CD for ; Thu, 22 Jan 2015 18:15:46 -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 zwtldH12X6EH for ; Thu, 22 Jan 2015 18:15:45 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242831A1A87 for ; Thu, 22 Jan 2015 18:15:45 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id bs8so318810wib.0 for ; Thu, 22 Jan 2015 18:15:44 -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:from:date :message-id:subject:to:cc:content-type; bh=IXG2Wi2V1yIcoN66inYrpBEqM96lNVg78dGXVU00l9I=; b=a8dvsV/veNOvKN9rWufjbF43EAJshH5ZjOudSh1BBt7udXwCQM3VQqwogzsVoBLHy0 kb78Zf+j7kWrCZjrVzwjwYW9QvZz7DKHB88FBD5WgS3uB1ifPMF5pkoBWFnMZe7ix/hj 78TpBd4abOtWGZWz9u862c8Kq8XNxJqeGV4xPu85nBwEM5TzmZGItovTWKlk0GJyhfSO 6gn0pFmo2fqFSRSX9SHnHeSL1k+bD+X4B/0I5omc+YpPybMHLImxzcFNcyrX1Js6PqrL ceZc3cyaq3F7AUYOWkSQELZO2WkLZlsRHMpbiECGEqcEkHS0CaAzKNxDAMey8Z+cDeeH iADA== X-Gm-Message-State: ALoCoQn/OeGRn1a38J5czSlN+DltRvlolm4TpGJjHuSgTHV4LYmCmnZEXq6XpL8FUIbfcKcxv8FU X-Received: by 10.180.39.35 with SMTP id m3mr10701929wik.3.1421979342508; Thu, 22 Jan 2015 18:15:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.11.100 with HTTP; Thu, 22 Jan 2015 18:15:21 -0800 (PST) X-Originating-IP: [173.160.171.253] In-Reply-To: <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> From: Tim Bray Date: Thu, 22 Jan 2015 18:15:21 -0800 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary=001a1134c90296abb4050d485d8a Archived-At: Cc: Matt Miller , "json@ietf.org" , Ted Lemon , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" , The IESG Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 02:15:46 -0000 --001a1134c90296abb4050d485d8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 22, 2015 at 7:21 AM, wrote: > =E2=80=8B=E2=80=8B > > The "in particular" at the beginning of this sentence has no antecedent= , > =E2=80=8B=E2=80=8B > > so it doesn't make sense to say it. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > The antecedent is the previous paragraph: the restriction on integers > =E2=80=8B=E2=80=8B > is a direct consequence of the restriction to IEEE doubles. > =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s leave it = to the RFC editor. > --001a1134c90296abb4050d485d8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Thu, Jan 22, 2015 at 7:21 AM, <cowan@ccil.org> wrote:
=E2=80=8B=E2=80=8B
> The "in particular= " at the beginning of this sentence has no antecedent,
=E2= =80=8B=E2=80=8B
> so it doesn't make sense to say it.
=E2= =80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
The antecedent is the previous paragraph:=C2=A0 t= he restriction on integers
=E2= =80=8B=E2=80=8B
is a direct consequence of the restriction to IEEE dou= bles.

=E2=80=8BYay, grammar fight! I agree with John, but l= et=E2=80=99s leave it to the RFC editor.


--001a1134c90296abb4050d485d8a-- From nobody Thu Jan 22 18:27:27 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2231B2BB1; Thu, 22 Jan 2015 18:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMeAWJPEPi34; Thu, 22 Jan 2015 18:27:20 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC0D1B2B98; Thu, 22 Jan 2015 18:27:20 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id E932CDA0361; Fri, 23 Jan 2015 02:27:19 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B436053E080; Thu, 22 Jan 2015 18:27:19 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 22 Jan 2015 18:27:19 -0800 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 22 Jan 2015 21:27:11 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <908CB399-2E9A-4B9F-A0F2-6532C0054651@nominum.com> References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: John Cowan , Matt Miller , "json@ietf.org" , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 02:27:21 -0000 On Jan 22, 2015, at 9:15 PM, Tim Bray wrote: > =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s = leave it to the RFC editor. No, I didn't complain about it because of a grammar issue. I complained = about it because it didn't make sense. It's great that John explained = it to me, and it's fine with me if you really think everybody who reads = this will understand why 64-bit integers are related to 54-bit floating = point mantissae, but I am really skeptical that that's so. It seems to = me that part of your intended audience here are people who are _not_ = Javascript programmers, and they will not understand how the two = paragraphs are connected, because no-one who has not programmed in = Javascript would ever imagine that a programming language would only = support integers as inexact numbers. So of course you are free to just leave it the way it is, but please be = clear on what you are doing: you are not leaving a grammar error for the = RFC editor to think about. From nobody Fri Jan 23 04:04:47 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046C51A9094; Fri, 23 Jan 2015 04:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoHMJalash2Y; Fri, 23 Jan 2015 04:04:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ECA1A19FA; Fri, 23 Jan 2015 04:04:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C256BEA1; Fri, 23 Jan 2015 12:04:38 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbnuVSbrHLGh; Fri, 23 Jan 2015 12:04:38 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 27D5CBED4; Fri, 23 Jan 2015 12:04:38 +0000 (GMT) Message-ID: <54C238D6.1030101@cs.tcd.ie> Date: Fri, 23 Jan 2015 12:04:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tim Bray References: <20150119232839.19662.13834.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Matt Miller , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 12:04:42 -0000 Hiya, Coupla bits'n'pieces below, nothing alarming:-) On 23/01/15 02:08, Tim Bray wrote: > > > On Mon, Jan 19, 2015 at 3:28 PM, Stephen Farrell > wrote: > >> ​​ >> >> ​​ >> - 2.1: I've >> ​​ >> no idea what Surrogate or Noncharacter >> ​​ >> means he >> ​​ >> re - a precise reference would be good for me. >> ​​ >> And the e >> ​​ >> xamples don't help me. So I agree with >> ​​ >> Barry's di >> ​​ >> scuss. >> > ​​ > ​​ > ​​Yes. I have an action item to introduce the appropriate references from > [UNICODE]​ > ​​ > >> >> ​​ >> - 4.3: Did the WG discuss whether to require/encourage >> ​​ >> inclusion/exclusion of 00 values and timezones in >> ​​ >> times? E.g. is there a preference for 20150119T2304Z or >> ​​ >> 20150119T230400Z which represent the same time. >> > ​​ > > ​Not terribly much. The recommendation is pretty well a straight copy from > RFC4287, where that was intensively discussed, on the grounds that it was > probably a best practice.​ So, ASN.1 DER rules do mandate inclusion of 00 seconds and minutes and Z on the basis that people otherwise get signatures wrong now and then if the value is round-tripped between signing and verification. In practice, I think that'd now be a really rare screw-up though as most implementers have learned to not round-trip stuff that has been signed. And insisting on including or excluding 00 seconds can cause bogus interop issues if one side is too anal. (I recall some code that we had always set seconds to a non-zero value, sometimes by waiting a secondm of fibbing and saying 01, just to avoid this:-) BTW, by round-trip here I mean decode the json-string into some data structure and then re-encode to json, perhaps with a different implementation after a visit to a database maybe. Anyway, you could point out the issue here and maybe at most add a SHOULD but it's probably good enough now. > ​​ > >> ​​ >> >> ​​ >> - 4.3: I'm also a bit surprised you don't say that UTC >> ​​ >> is the default TZ. I think those time rules do help >> ​​ >> interoperability so defining defaults would have been >> ​​ >> an improvement. Why is that? (I don't think 3339 does >> ​​ >> that or does it?) >> > ​​ > ​​ > ​I’m pretty sure that this discussion never happened. Which is leading me > to the conclusion that it would be useful for there to be some AppsArea > discussion on best practices for RFC3339 dates. However, I’m not convinced > that asserting the default timezone would noticeably help interoperability. Not include a TZ can lead to interop problems though if a producer and consumer make different assumptions about how that maps to local time. And it re-creates the potential for a classic access control screw up as well of course. So, in this case, I'd have thought that at least a SHOULD for including a TZ would be a good addition, esp. if you are going to take the approach of recommending that this profile be used for security sensitive uses of JSON. Yes, that could be punted to a 3339bis (or profile) maybe but that'd take ages and angst and probably just amount to just adding that one sentence:-) Doing it here should save others the trouble of constantly adding to to things that reference this RFC though. That said, there may be arguments against a SHOULD for including a TZ, but I don't know what they are. Cheers, S. > > >> >> - 4.4: I don't recall them so have had to track down >> the difference between base64 and base64url and check >> I'm using the right APIs over and over. That might be >> because I only write code sporadically (and badly:-) >> and forget stuff in between, but an example of the >> difference (possibly parenthetical) would help me a >> bit, just so's I could look at a value I generate and >> spot I've done it wrong again. >> > > ​Base64url is pretty widely used because the characters that are removed > from the repertoire are troublesome in a variety of contexts and, well, > hey, *anything* might show up in a URI these days. You don’t really have > to track down the difference - every base64 library these days has an > option saying “generate URL form”.​ > From nobody Fri Jan 23 04:35:09 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5521A90AF; Fri, 23 Jan 2015 04:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q67H8jArMxsj; Fri, 23 Jan 2015 04:35:01 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09101A90AE; Fri, 23 Jan 2015 04:35:00 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so5991306qcw.9; Fri, 23 Jan 2015 04:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dkSTleCH5eW93ahs/UjlP9DbvHC2/5NCQY0d7gfgwyI=; b=JK9yfGNoFjSnZYO+bUOQQHYnmyPF6w7+HfWiwkNnDBYuIM+1rofB4gezSQMYizYppe 3Sm7eeoZ7B8CdSazoTRf9BjUpCxV2U1hSRQcL2H8mtHsSj+i2KMJb+UOspG67I0YutYz sa3/UEI3QW5dDNf2r7QPoyuJVftXgPTR1NNqmMEHXOqfi0EmyZ1Nd61/cPezo/xb2OIu sjT/5y8bLgnUyrZXnvpv3YquhFyEW8mhoHw3hx+fOwT5jjfz7MBICcT/VSii8J73pVoj 8Vhw3sCFjQowiNX2+a4ymobcv9nLrMErZy2HiaWTOmZo6W9kemcpXynmh0HdK6f1Pg/w U4oQ== X-Received: by 10.224.79.137 with SMTP id p9mr7118996qak.32.1422016499819; Fri, 23 Jan 2015 04:34:59 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 7sm1325284qak.20.2015.01.23.04.34.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 04:34:56 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-429B76F2-35AF-4355-BDB0-79D18516AA4C Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 23 Jan 2015 07:34:56 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8153A076-798F-412A-94EF-543848607C9B@gmail.com> References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> To: Tim Bray Archived-At: Cc: "json-chairs@tools.ietf.org" , "json@ietf.org" , Matt Miller , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 23 Jan 2015 12:35:03 -0000 --Apple-Mail-429B76F2-35AF-4355-BDB0-79D18516AA4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Sent from my iPhone > On Jan 22, 2015, at 9:02 PM, Tim Bray wrote: >=20 > >=20 > I thought that claiming that I-JSON offered qualitatively better security w= as a little immodest. If there=E2=80=99s general agreement with Kathleen an= d SecDir, I=E2=80=99d be happy to introduce such language. There are two opt= ions: > 1. Note that =E2=80=9C I-JSON restricts and limits some of=E2=80=8B=E2=80=8B= the danger=E2=80=8B=E2=80=8Bous formats of the original JSON, therefore it m= ight be considered=E2=80=8B=E2=80=8B more secure=E2=80=8B=E2=80=8B=E2=80=9D > 2. Assert that security-critical usages of JSON should (or SHOULD?) use I-= JSON For coding related issues, security is a bit better when there are limits/re= strictions for parsers. I think Stephen pointed out a few things he thought= were going to happen to further restrict, that didn't. However, your propo= sed language looks good to me and leaves a little leeway. Thanks, Kathleen >=20 >=20 >> On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-json-i-json-05: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> I agree with the SecDir reviewer in his assessment of this draft after >> reading it. I'm putting this in as comments/suggestions to be considered= >> as the security considerations really should be in the JSON document. If= >> any considerations are missing, that is where I'd expect to see them. >> The JSON format is not simple, so agree with the SecDir reviewer that >> one would have expected additional handling considerations for security >> purposes to be in that document. They don't need to be listed in this >> one. >>=20 >> Having said that, it might be good idea to add text to the security >> considerations section, to state that I-JSON restricts and limits some >> of >> the dangerous formats of the original JSON, therefore it might be >> considered >> more secure than the original JSON. Perhaps also mention that >> security critical usages of the JSON should use I-JSON >> (perhaps even provide references to the jose specifications). >> https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html >=20 >=20 >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see https:= //keybase.io/timbray) --Apple-Mail-429B76F2-35AF-4355-BDB0-79D18516AA4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Sent from my iPhone

On Jan 22, 2015, at 9:02 PM, Tim Bray <tbray@textuality.com> wrote:

<editor-hat>

I thought that claiming that I-JSON offered qualitatively better secu= rity was a little immodest.  If there=E2=80=99s general agreement with K= athleen and SecDir, I=E2=80=99d be happy to introduce such language. There a= re two options:
= 1. Note that =E2=80=9C I-JSON restricts and limits some of
=E2=80=8B=E2=80=8B 
the danger
=E2=80=8B=E2=80=8B
ous formats of the original JSON, therefore it might be cons= idered
=E2=80=8B= =E2=80=8B 
more secure
=E2=80=8B=E2=80=8B=E2=80=9D<= /div>
2. Assert that security-critical= usages of JSON should (or SHOULD?) use I-JSON

For coding related issues, security is a bit better wh= en there are limits/restrictions for parsers.  I think Stephen pointed o= ut a few things he thought were going to happen to further restrict, that di= dn't.  However, your proposed language looks good to me and leaves a li= ttle leeway.

Thanks,
Kathleen


On Mo= n, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty <Kathleen.Mori= arty.ietf@gmail.com> wrote:
K= athleen Moriarty has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criter= ia.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir reviewer in his assessment of this draft after
reading it.  I'm putting this in as comments/suggestions to be consider= ed
as the security considerations really should be in the JSON document.  I= f
any considerations are missing, that is where I'd expect to see them.
The JSON format is not simple, so  agree with the SecDir reviewer that<= br> one would have expected additional handling considerations for security
purposes to be in that document.  They don't need to be listed in this<= br> one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some
of
the dangerous formats of the original JSON, therefore it might be
considered
more secure than the original JSON.  Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/ms= g05380.html





--
- Tim Bray (If you=E2=80=99d like to= send me a private message, see https://keybase.io/timbray)
= --Apple-Mail-429B76F2-35AF-4355-BDB0-79D18516AA4C-- From nobody Fri Jan 23 08:01:09 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670791A8912; Fri, 23 Jan 2015 00:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiBNjluwFw2K; Fri, 23 Jan 2015 00:15:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD151A1A9C; Fri, 23 Jan 2015 00:15:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2F606AC2; Fri, 23 Jan 2015 09:15:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kqg5XedbB17v; Fri, 23 Jan 2015 09:15:11 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Jan 2015 09:15:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21CE220036; Fri, 23 Jan 2015 09:15:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ks_vXMDup4n0; Fri, 23 Jan 2015 09:15:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC64220035; Fri, 23 Jan 2015 09:15:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5E15530E4BB6; Fri, 23 Jan 2015 09:15:33 +0100 (CET) Date: Fri, 23 Jan 2015 09:15:32 +0100 From: Juergen Schoenwaelder To: Tim Bray Message-ID: <20150123081532.GC37850@elstar.local> References: <20150119140118.824.91479.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Fri, 23 Jan 2015 08:01:08 -0800 Cc: Matt Miller , "json@ietf.org" , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, Benoit Claise , "json-chairs@tools.ietf.org" Subject: Re: [Json] Benoit Claise's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:15:41 -0000 Tim, if a protocol designer writes "MUST be I-JSON messages" (to use your wording) then I like to know what exactly that means. Is support of section 2 sufficient for that? /js On Thu, Jan 22, 2015 at 05:59:35PM -0800, Tim Bray wrote: > > > My opinion is that while it is perhaps a little unusual not to define > conformance, I don’t think doing so would increase the *usefulness* of the > draft. The intent is that the draft provide a complete, crisp definition > of an entity called an “I-JSON message” and protocol designers make use of > it by saying that their message payloads “MUST be I-JSON messages”. > > It honestly hadn’t crossed my mind that people might want to claim official > conformance with the protocol-design recommendations. If there’s a > perception that this is a likely scenario, it would not be that difficult > to include a definition of the notion of conformance. > > On Mon, Jan 19, 2015 at 6:01 AM, Benoit Claise wrote: > > > Benoit Claise has entered the following ballot position for > > draft-ietf-json-i-json-05: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > There is still a ongoing discussion between J. Schönwälder (OPS-DIR) and > > Tim Bray. > > > > On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote: > > > On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > >> My understanding is that compliance to I-JSON means compliance to > > >> section 2 of this document. Perhaps it makese sense to clarify this > > >> (in particular if my interpretation is wrong). > > >> > > > > > > Hmm, good point. ​The draft currently doesn’t mention compliance; all > > it > > > does is give a syntactic definition of something called an “I-JSON > > > message”. The notion was that other specs which wanted to require the > > use > > > of I-JSON should say something like “The message body must be an > > I-JSON > > > message [RFCXXXX]”. I think that would work fine, but I wonder if > > others, > > > like you, will be bothered by the absence of a specification of > > > “compliance”. > > > > > > > I am raising this question since I think the draft goes somewhat > > beyond simply defining I-JSON (which I believe is the material > > contained in section 2). > > > > In particular, the I-D uses RFC 2119 language in a section titled > > "Protocol-design Recommendations". It is not clear to me how these > > recommendations have been selected or why they are part of an I-JSON > > specification. This applies mostly to sections 4.3 and 4.4. Anyway, > > since these sections use RFC 2119 requirements language, I am > > wondering what happens if a protocol complies to section 2 but not all > > of section 4 - is it using I-JSON? I hope so, but it might be good to > > make this clear. > > > > /js > > > > > > ---------------------------------------------------- > > > > Editorial nit: > > > > - s/values in in ISO 8601/values in ISO 8601/ > > > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > > > > -- > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jan 25 10:10:14 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F351A1A2C for ; Sun, 25 Jan 2015 10:10:12 -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 duvYapHa6zoq for ; Sun, 25 Jan 2015 10:10:10 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6131A1A23 for ; Sun, 25 Jan 2015 10:10:09 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so4606201lam.5 for ; Sun, 25 Jan 2015 10:10:08 -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:from:date :message-id:subject:to:cc:content-type; bh=7RB7H26D1FnJYOWMe/qOmvL3Y9Jplm/mMmAAvegt7fA=; b=EE20iyuHf1iwGNJK6dVGhiNWzHoo4P4OcgJrGHAB6lQKrLWbodGrtHLgTbhWPeiAE0 dX7WjAx10e8ulwyAK04I/i+y4m2qvz2UeOTjFtLKzRbq0Z/rYHgsViMVTpmCmajnWoVE DsrX9X3AVDJFBG0Lj8zsdJ8MAmawKjhWiUJ/OlGK7IxCN7344bfRqgE9EbjXzZ5n1x8m iG4kL6o57QZLtGkhgLWimBmXXV7bPTLKXruWLeXUsK/64TGQxcobGrIIr3UuHkk/O4c+ zrjbsAIqz46JXXvwvKxOtOy4CZngXF5p9dRM7x99kgGVrup/dkCkxXU0R/MEGqRJcryZ lEeg== X-Gm-Message-State: ALoCoQk6FT6wsyuy0w/WFmFspqfbePuV0fi1Fjb3bMuLLCOCA4Esyed6ADcOyQXZJ8iicgGVbVsO X-Received: by 10.152.9.41 with SMTP id w9mr241046laa.17.1422209408148; Sun, 25 Jan 2015 10:10:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Sun, 25 Jan 2015 10:09:47 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <908CB399-2E9A-4B9F-A0F2-6532C0054651@nominum.com> References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> <908CB399-2E9A-4B9F-A0F2-6532C0054651@nominum.com> From: Tim Bray Date: Sun, 25 Jan 2015 10:09:47 -0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=089e0158b6f891bb67050d7dee4f Archived-At: Cc: John Cowan , Matt Miller , "json@ietf.org" , The IESG , draft-ietf-json-i-json.all@tools.ietf.org, "json-chairs@tools.ietf.org" Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 18:10:12 -0000 --089e0158b6f891bb67050d7dee4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair enough. There are a few minor edits built up now as a result of this conversation. Matt, what=E2=80=99s the process, should I do another draft t= hat=E2=80=99s responsive to them? On Thu, Jan 22, 2015 at 6:27 PM, Ted Lemon wrote: > On Jan 22, 2015, at 9:15 PM, Tim Bray wrote: > > =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s leave= it to the RFC > editor. > > No, I didn't complain about it because of a grammar issue. I complained > about it because it didn't make sense. It's great that John explained i= t > to me, and it's fine with me if you really think everybody who reads this > will understand why 64-bit integers are related to 54-bit floating point > mantissae, but I am really skeptical that that's so. It seems to me tha= t > part of your intended audience here are people who are _not_ Javascript > programmers, and they will not understand how the two paragraphs are > connected, because no-one who has not programmed in Javascript would ever > imagine that a programming language would only support integers as inexac= t > numbers. > > So of course you are free to just leave it the way it is, but please be > clear on what you are doing: you are not leaving a grammar error for the > RFC editor to think about. > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e0158b6f891bb67050d7dee4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fai= r enough.=C2=A0 There are a few minor edits built up now as a result of thi= s conversation. Matt, what=E2=80=99s the process, should I do another draft= that=E2=80=99s responsive to them?
<= br>
On Thu, Jan 22, 2015 at 6:27 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Jan 22, 2015, at 9:15 PM, Tim Bray <tbray@textuality.com> wrote:
> =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s leav= e it to the RFC editor.

No, I didn't complain about it because of a grammar issue.=C2=A0= I complained about it because it didn't make sense.=C2=A0 =C2=A0It'= ;s great that John explained it to me, and it's fine with me if you rea= lly think everybody who reads this will understand why 64-bit integers are = related to 54-bit floating point mantissae, but I am really skeptical that = that's so.=C2=A0 =C2=A0It seems to me that part of your intended audien= ce here are people who are _not_ Javascript programmers, and they will not = understand how the two paragraphs are connected, because no-one who has not= programmed in Javascript would ever imagine that a programming language wo= uld only support integers as inexact numbers.

So of course you are free to just leave it the way it is, but please be cle= ar on what you are doing: you are not leaving a grammar error for the RFC e= ditor to think about.




--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--089e0158b6f891bb67050d7dee4f-- From nobody Sun Jan 25 10:12:55 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6A1A1A4F for ; Sun, 25 Jan 2015 10:12:53 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHVjseiqcX6J for ; Sun, 25 Jan 2015 10:12:51 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582751A1A23 for ; Sun, 25 Jan 2015 10:12:50 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so4605369lbj.0 for ; Sun, 25 Jan 2015 10:12:48 -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:from:date :message-id:subject:to:cc:content-type; bh=+4wBQJD0o5BvBl9AMPXjxHcf6tjwWVvM3+rLEa5hFrQ=; b=VIDqzHC8za5I2mnKOR2+7Oen+GpKxN+42aJ+q5l+W4uTncv23Y6Jszni75F6BzS/4r 71K0RMk/3mGYcKtWBHJ8lfuzKl+gYGKThyekgQa6LRE7qJjZXgQIJR4rWbriqTtn7tFg jfowvRitQueGJyIJGdVvCXaJ3j7a1IA+B1HyWl6meCF7gItzb1h9m5FFUlRDa113RRYB GPXNdCe8Gp3OSDpMwdBBWpUjAxOUq3S/1xY7OAERccHBFEqpefZd+LO5QvEh7khwnS19 Fp36S3TercdafmxQs8sJNpglLTWgp0/u1wnOKZL8tY6TQrE/M9t7vZ03knDqIDdwJuGq niOQ== X-Gm-Message-State: ALoCoQkfvYdkIcuSsWDhrrMQ5vHaz63UrJapvTPJgZDpETbG94bLA+9WCHVGHVik2pCtFqibB+Im X-Received: by 10.112.17.197 with SMTP id q5mr17530373lbd.30.1422209568701; Sun, 25 Jan 2015 10:12:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Sun, 25 Jan 2015 10:12:28 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <20150123081532.GC37850@elstar.local> References: <20150119140118.824.91479.idtracker@ietfa.amsl.com> <20150123081532.GC37850@elstar.local> From: Tim Bray Date: Sun, 25 Jan 2015 10:12:28 -0800 Message-ID: To: Juergen Schoenwaelder Content-Type: multipart/alternative; boundary=001a1135f77823957e050d7df881 Archived-At: Cc: Matt Miller , "json@ietf.org" , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , Benoit Claise , "json-chairs@tools.ietf.org" Subject: Re: [Json] Benoit Claise's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 18:12:54 -0000 --001a1135f77823957e050d7df881 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BThe WG claim is that Section 2 - http://www.tbray.org/tmp/draft-ietf-json-i-json-05.html#rfc.section.2=E2=80= =8B - provides sufficient detail that a referring spec can say MUST be I-JSON Messages, with a reference to that, and this should provide sufficient clarity. If it doesn=E2=80=99t, I think the WG would agree that that=E2=80= =99s a bug. On Fri, Jan 23, 2015 at 12:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Tim, > > if a protocol designer writes "MUST be I-JSON messages" (to use your > wording) then I like to know what exactly that means. Is support of > section 2 sufficient for that? > > /js > > On Thu, Jan 22, 2015 at 05:59:35PM -0800, Tim Bray wrote: > > > > > > My opinion is that while it is perhaps a little unusual not to define > > conformance, I don=E2=80=99t think doing so would increase the *usefuln= ess* of > the > > draft. The intent is that the draft provide a complete, crisp definiti= on > > of an entity called an =E2=80=9CI-JSON message=E2=80=9D and protocol de= signers make use > of > > it by saying that their message payloads =E2=80=9CMUST be I-JSON messag= es=E2=80=9D. > > > > It honestly hadn=E2=80=99t crossed my mind that people might want to cl= aim > official > > conformance with the protocol-design recommendations. If there=E2=80= =99s a > > perception that this is a likely scenario, it would not be that difficu= lt > > to include a definition of the notion of conformance. > > > > On Mon, Jan 19, 2015 at 6:01 AM, Benoit Claise > wrote: > > > > > Benoit Claise has entered the following ballot position for > > > draft-ietf-json-i-json-05: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > There is still a ongoing discussion between J. Sch=C3=B6nw=C3=A4lder = (OPS-DIR) > and > > > Tim Bray. > > > > > > On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote: > > > > On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > >> My understanding is that compliance to I-JSON means compliance to > > > >> section 2 of this document. Perhaps it makese sense to clarify thi= s > > > >> (in particular if my interpretation is wrong). > > > >> > > > > > > > > Hmm, good point. =E2=80=8BThe draft currently doesn=E2=80=99t ment= ion compliance; > all > > > it > > > > does is give a syntactic definition of something called an =E2=80= =9CI-JSON > > > > message=E2=80=9D. The notion was that other specs which wanted to = require > the > > > use > > > > of I-JSON should say something like =E2=80=9CThe message body must = be an > > > I-JSON > > > > message [RFCXXXX]=E2=80=9D. I think that would work fine, but I wo= nder if > > > others, > > > > like you, will be bothered by the absence of a specification of > > > > =E2=80=9Ccompliance=E2=80=9D. > > > > > > > > > > I am raising this question since I think the draft goes somewhat > > > beyond simply defining I-JSON (which I believe is the material > > > contained in section 2). > > > > > > In particular, the I-D uses RFC 2119 language in a section titled > > > "Protocol-design Recommendations". It is not clear to me how these > > > recommendations have been selected or why they are part of an I-JSON > > > specification. This applies mostly to sections 4.3 and 4.4. Anyway, > > > since these sections use RFC 2119 requirements language, I am > > > wondering what happens if a protocol complies to section 2 but not al= l > > > of section 4 - is it using I-JSON? I hope so, but it might be good to > > > make this clear. > > > > > > /js > > > > > > > > > ---------------------------------------------------- > > > > > > Editorial nit: > > > > > > - s/values in in ISO 8601/values in ISO 8601/ > > > > > > > > > _______________________________________________ > > > json mailing list > > > json@ietf.org > > > https://www.ietf.org/mailman/listinfo/json > > > > > > > > > > > -- > > - Tim Bray (If you=E2=80=99d like to send me a private message, see > > https://keybase.io/timbray) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1135f77823957e050d7df881 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2= =80=8BThe WG claim is that Section 2 - http://www.tbray.org/tmp/draf= t-ietf-json-i-json-05.html#rfc.section.2=E2=80=8B - provides sufficient= detail that a referring spec can say MUST be I-JSON Messages, with a refer= ence to that, and this should provide sufficient clarity.=C2=A0 If it doesn= =E2=80=99t, I think the WG would agree that that=E2=80=99s a bug.

On Fri, Jan 23,= 2015 at 12:15 AM, Juergen Schoenwaelder <j.schoenwaeld= er@jacobs-university.de> wrote:
Tim,

if a protocol designer writes "MUST be I-JSON messages" (to use y= our
wording) then I like to know what exactly that means. Is support of
section 2 sufficient for that?

/js

On Thu, Jan 22, 2015 at 05:59:35PM -0800, Tim Bray wrote:
> <editor-hat>
>
> My opinion is that while it is perhaps a little unusual not to define<= br> > conformance, I don=E2=80=99t think doing so would increase the *useful= ness* of the
> draft.=C2=A0 The intent is that the draft provide a complete, crisp de= finition
> of an entity called an =E2=80=9CI-JSON message=E2=80=9D and protocol d= esigners make use of
> it by saying that their message payloads =E2=80=9CMUST be I-JSON messa= ges=E2=80=9D.
>
> It honestly hadn=E2=80=99t crossed my mind that people might want to c= laim official
> conformance with the protocol-design recommendations.=C2=A0 If there= =E2=80=99s a
> perception that this is a likely scenario, it would not be that diffic= ult
> to include a definition of the notion of conformance.
>
> On Mon, Jan 19, 2015 at 6:01 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
> > Benoit Claise has entered the following ballot position for
> > draft-ietf-json-i-json-05: No Objection
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/di= scuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > http://datatracker.ietf.org/doc/draft-ietf-json-i-json= /
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > There is still a ongoing discussion between J. Sch=C3=B6nw=C3=A4l= der (OPS-DIR) and
> > Tim Bray.
> >
> > On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote:
> > > On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > >
> > >> My understanding is that compliance to I-JSON means comp= liance to
> > >> section 2 of this document. Perhaps it makese sense to c= larify this
> > >> (in particular if my interpretation is wrong).
> > >>
> > >
> > > Hmm, good point.=C2=A0 =E2=80=8BThe draft currently doesn=E2= =80=99t mention compliance; all
> > it
> > > does is give a syntactic definition of something called an = =E2=80=9CI-JSON
> > > message=E2=80=9D.=C2=A0 The notion was that other specs whic= h wanted to require the
> > use
> > > of I-JSON should say something like =E2=80=9CThe message bod= y must be an
> > I-JSON
> > > message [RFCXXXX]=E2=80=9D.=C2=A0 I think that would work fi= ne, but I wonder if
> > others,
> > > like you, will be bothered by the absence of a specification= of
> > > =E2=80=9Ccompliance=E2=80=9D.
> > >
> >
> > I am raising this question since I think the draft goes somewhat<= br> > > beyond simply defining I-JSON (which I believe is the material > > contained in section 2).
> >
> > In particular, the I-D uses RFC 2119 language in a section titled=
> > "Protocol-design Recommendations". It is not clear to m= e how these
> > recommendations have been selected or why they are part of an I-J= SON
> > specification. This applies mostly to sections 4.3 and 4.4. Anywa= y,
> > since these sections use RFC 2119 requirements language, I am
> > wondering what happens if a protocol complies to section 2 but no= t all
> > of section 4 - is it using I-JSON? I hope so, but it might be goo= d to
> > make this clear.
> >
> > /js
> >
> >
> > ----------------------------------------------------
> >
> > Editorial nit:
> >
> > - s/values in in ISO 8601/values in ISO 8601/
> >
> >
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
> >
>
>
>
> --
> - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keyba= se.io/timbray)

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1, 28759 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--001a1135f77823957e050d7df881-- From nobody Sun Jan 25 10:16:43 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266731A1AB8 for ; Sun, 25 Jan 2015 10:16:35 -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 Y4U_gE3w6Vq7 for ; Sun, 25 Jan 2015 10:16:33 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D091A1A2C for ; Sun, 25 Jan 2015 10:16:33 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id hv19so4558890lab.13 for ; Sun, 25 Jan 2015 10:16:31 -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:from:date :message-id:subject:to:cc:content-type; bh=kzV6ofX5prdq0ZxrE79+F73BsCQfN+EVc9APd2FrpXc=; b=iCeNMOzPBxymrx0yyO9ABz4VAMDf5/hlVZl7jdSt2EK4Veo+D3T3lesQJ03AKK84MV DfhIspmcML5urHikHm+1ZW4udb7hDGUgKrIJ0AlGhANvfHr1lek0qdEEh/9X/v7N8/xp o+wIehZPa0XMlrNYLSECfSYsZz+pevmWdLDYLnvfnqjIpNLwtIMQOg5PGHvlEyvL3tJP 9VostAkpjAki3y7FAgVKSIhEHSLAq5WcXTJ28dMEubxyWnVqX2zpcxQ9UP2cSNuaR2a9 l3xAYTXc2VtK4azJ5cQq1RVIftBtyxeacBOBXHRQEe/GKAsaemrx+W11eS4c+5ySy027 aJsQ== X-Gm-Message-State: ALoCoQnn9LJhIfkqU4T/7Pf75ZvGHoxGAhGAyNDRRKeQnuwc2Hl/syb4iEz1ca7gYn7MsW/0vlue X-Received: by 10.112.166.73 with SMTP id ze9mr17221076lbb.38.1422209791810; Sun, 25 Jan 2015 10:16:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Sun, 25 Jan 2015 10:16:11 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <54C238D6.1030101@cs.tcd.ie> References: <20150119232839.19662.13834.idtracker@ietfa.amsl.com> <54C238D6.1030101@cs.tcd.ie> From: Tim Bray Date: Sun, 25 Jan 2015 10:16:11 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c328986fe56e050d7e058b Archived-At: Cc: Matt Miller , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 18:16:35 -0000 --001a11c328986fe56e050d7e058b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2015 at 4:04 AM, Stephen Farrell wrote: > > So, in this case, I'd have thought that at least a SHOULD for > including a TZ would be a good addition, esp. if you are going to > take the approach of recommending that this profile be used > for security sensitive uses of JSON. > =E2=80=8BUnless someone screams STOP I=E2=80=99ll put such a recommendation= in a revised draft unless it=E2=80=99s best to leave that to the RFC Ed.=E2=80=8B --001a11c328986fe56e050d7e058b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Fri, Jan 23, 2015 at 4:04 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

So, in this case, I'= ;d have thought that at least a SHOULD for
including a TZ would be a good addition, esp. if you are going to
take the approach of recommending that this profile be used
for security sensitive uses of JSON.

=E2=80=8BUnless someon= e screams STOP I=E2=80=99ll put such a recommendation in a revised draft un= less it=E2=80=99s best to leave that to the RFC Ed.=E2=80=8B

--001a11c328986fe56e050d7e058b-- From nobody Sun Jan 25 10:17:48 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141801A1A2C for ; Sun, 25 Jan 2015 10:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 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, SPF_SOFTFAIL=0.665] 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 uPEWvj-Nm1-j for ; Sun, 25 Jan 2015 10:15:38 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175251A1A23 for ; Sun, 25 Jan 2015 10:15:38 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id nt9so4719158obb.9 for ; Sun, 25 Jan 2015 10:15:37 -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=QWw8pQazGYAK+98PUpol2pe4mhNNp4HHiI/LgUApYQ4=; b=f6U4IDFXOr3qvsx6tQazcYfwOUA9KSqfWNQGjGNSvF3bgsU5AtytK+cc4crdp05co8 aXZbOERQcq7kojCBxF5sMX78q746y4opzyV8YtnuRm0Ukege+mjeE/14IH94aulv3goD VEiFkVBA5+LLRM+OIsoKfOjXzwSWZWoivOFRftrj9O237JJEXVrpYqxaSzvz3CiT+Emh SVSjYY/RZsuza9oB7ZHuqoByHIeb55IG0fJe8GCx9PLPOHkM7UfgYgPRsGku61FMyoTU Iwtuzo/7zuNvDPGfyrvbn0PexKLLvhL+YIsKT+UywH/gprTugb8e4ooHsHtxzVx/SyIv Ijxw== X-Gm-Message-State: ALoCoQnYn+0GHpLohd+C6PIZ4rsTYIbI1Oku1O0mSgbfcD+wa35yzQMNsoBjQr//kPnJ5qUHM2ky MIME-Version: 1.0 X-Received: by 10.60.155.195 with SMTP id vy3mr10786601oeb.62.1422209737474; Sun, 25 Jan 2015 10:15:37 -0800 (PST) Received: by 10.76.103.37 with HTTP; Sun, 25 Jan 2015 10:15:37 -0800 (PST) X-Originating-IP: [24.8.87.210] Received: by 10.76.103.37 with HTTP; Sun, 25 Jan 2015 10:15:37 -0800 (PST) In-Reply-To: References: <20150122143903.6120.87716.idtracker@ietfa.amsl.com> <855425235f1661a31f32ae68b18dc3a2.squirrel@www.ccil.org> <908CB399-2E9A-4B9F-A0F2-6532C0054651@nominum.com> Date: Sun, 25 Jan 2015 11:15:37 -0700 Message-ID: From: Matthew Miller To: Tim Bray Content-Type: multipart/alternative; boundary=089e0102dc3232d9d5050d7e02ce Archived-At: X-Mailman-Approved-At: Sun, 25 Jan 2015 10:17:45 -0800 Cc: John Cowan , "json@ietf.org" , Ted Lemon , draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, The IESG Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 18:15:40 -0000 --089e0102dc3232d9d5050d7e02ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, go ahead and publish an update when you can. Thanks, - m&m {mobile} On Jan 25, 2015 11:10 AM, "Tim Bray" wrote: > Fair enough. There are a few minor edits built up now as a result of thi= s > conversation. Matt, what=E2=80=99s the process, should I do another draft= that=E2=80=99s > responsive to them? > > On Thu, Jan 22, 2015 at 6:27 PM, Ted Lemon wrote: > >> On Jan 22, 2015, at 9:15 PM, Tim Bray wrote: >> > =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s leav= e it to the RFC >> editor. >> >> No, I didn't complain about it because of a grammar issue. I complained >> about it because it didn't make sense. It's great that John explained = it >> to me, and it's fine with me if you really think everybody who reads thi= s >> will understand why 64-bit integers are related to 54-bit floating point >> mantissae, but I am really skeptical that that's so. It seems to me th= at >> part of your intended audience here are people who are _not_ Javascript >> programmers, and they will not understand how the two paragraphs are >> connected, because no-one who has not programmed in Javascript would eve= r >> imagine that a programming language would only support integers as inexa= ct >> numbers. >> >> So of course you are free to just leave it the way it is, but please be >> clear on what you are doing: you are not leaving a grammar error for the >> RFC editor to think about. >> >> > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --089e0102dc3232d9d5050d7e02ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, go ahead and publish an update when you can.

Thanks,

- m&m
{mobile}

On Jan 25, 2015 11:10 AM, "Tim Bray" &= lt;tbray@textuality.com> wro= te:
Fair enough.=C2=A0 = There are a few minor edits built up now as a result of this conversation. = Matt, what=E2=80=99s the process, should I do another draft that=E2=80=99s = responsive to them?

On Thu, Jan 22, 2015 at 6:27 PM, Ted Lemon = <Ted.Lemon@no= minum.com> wrote:
On= Jan 22, 2015, at 9:15 PM, Tim Bray <tbray@textuality.com> wrote:
> =E2=80=8BYay, grammar fight! I agree with John, but let=E2=80=99s leav= e it to the RFC editor.

No, I didn't complain about it because of a grammar issue.=C2=A0= I complained about it because it didn't make sense.=C2=A0 =C2=A0It'= ;s great that John explained it to me, and it's fine with me if you rea= lly think everybody who reads this will understand why 64-bit integers are = related to 54-bit floating point mantissae, but I am really skeptical that = that's so.=C2=A0 =C2=A0It seems to me that part of your intended audien= ce here are people who are _not_ Javascript programmers, and they will not = understand how the two paragraphs are connected, because no-one who has not= programmed in Javascript would ever imagine that a programming language wo= uld only support integers as inexact numbers.

So of course you are free to just leave it the way it is, but please be cle= ar on what you are doing: you are not leaving a grammar error for the RFC e= ditor to think about.




--
- Tim Bray (If you=E2=80=99d like to send me a private messa= ge, see https://ke= ybase.io/timbray)
--089e0102dc3232d9d5050d7e02ce-- From nobody Sun Jan 25 10:18:13 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBC91A1A2C for ; Sun, 25 Jan 2015 10:18: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 kX_oagRzsCxG for ; Sun, 25 Jan 2015 10:18:07 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB7E1A1B55 for ; Sun, 25 Jan 2015 10:18:06 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u10so4564117lbd.9 for ; Sun, 25 Jan 2015 10:18: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:from:date :message-id:subject:to:cc:content-type; bh=nubjxD/Yt+DherLHFG+wYfopDq/9D3A8IBaV8p/XzZQ=; b=bV2gdF3eMgMDcc7C5dYClMFNaa+tqGXZZDEA0qj8ENTX4S0R4/Xxv6QqmIYxLnEZSD 9ZttgrgSW83/Pt0YbrY1sl+7GVeTqmZaLr86d+xWXls79H2FGB4UnFGgk+t9RuDFI9rC vPLiENs1v5Uj6K/rTuNmJQ4wIRW3sn9+18MAYSZJKMHCrSD7JvnXIsohCn8LJU7+NTu3 0s2wyGXC7rpx8xvtewtZ7orRauQYrt+nMVCD/BzZNzFSa59nWb9YqTcAGBuFZebn7Umt wltPSwWvFfwyDoygG2GAmoSGvBFTf3iim8sK5aM3coTGKiM0tCBG2eVKvEtiJPacnZmK s28g== X-Gm-Message-State: ALoCoQkZ5wmCIrPTAWfZQgi8g6mRjuVX5RCjxboHtR47Nc23DJPLPmhrC76r3LH/GCjmW2qsfQ7R X-Received: by 10.152.115.230 with SMTP id jr6mr17664008lab.2.1422209885193; Sun, 25 Jan 2015 10:18:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Sun, 25 Jan 2015 10:17:45 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <8153A076-798F-412A-94EF-543848607C9B@gmail.com> References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> From: Tim Bray Date: Sun, 25 Jan 2015 10:17:45 -0800 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a11c3674200ceaa050d7e0b30 Archived-At: Cc: "json-chairs@tools.ietf.org" , "json@ietf.org" , Matt Miller , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 18:18:11 -0000 --001a11c3674200ceaa050d7e0b30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > I thought that claiming that I-JSON offered qualitatively better security > was a little immodest. If there=E2=80=99s general agreement with Kathlee= n and > SecDir, I=E2=80=99d be happy to introduce such language. There are two op= tions: > 1. Note that =E2=80=9C I-JSON restricts and limits some of > =E2=80=8B=E2=80=8B > the danger > =E2=80=8B=E2=80=8B > ous formats of the original JSON, therefore it might be considered > =E2=80=8B=E2=80=8B > more secure > =E2=80=8B=E2=80=8B=E2=80=9D > 2. Assert that security-critical usages of JSON should (or SHOULD?) use > I-JSON > > > For coding related issues, security is a bit better when there are > limits/restrictions for parsers. I think Stephen pointed out a few thing= s > he thought were going to happen to further restrict, that didn't. Howeve= r, > your proposed language looks good to me and leaves a little leeway. > > =E2=80=8BUm, which of the two, or both? Seriously, an IETF-consensus asser= tion that security-sensitive people SHOULD use I-JSON feels like a big deal to me. However, I think that=E2=80=99s what I=E2=80=99m hearing, so unless th= ere are screams I=E2=80=99ll go put some combo of #1 and #2 above in the next revision.=E2= =80=8B > Thanks, > Kathleen > > > > On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.com> wrote: > >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-json-i-json-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with the SecDir reviewer in his assessment of this draft after >> reading it. I'm putting this in as comments/suggestions to be considere= d >> as the security considerations really should be in the JSON document. I= f >> any considerations are missing, that is where I'd expect to see them. >> The JSON format is not simple, so agree with the SecDir reviewer that >> one would have expected additional handling considerations for security >> purposes to be in that document. They don't need to be listed in this >> one. >> >> Having said that, it might be good idea to add text to the security >> considerations section, to state that I-JSON restricts and limits some >> of >> the dangerous formats of the original JSON, therefore it might be >> considered >> more secure than the original JSON. Perhaps also mention that >> security critical usages of the JSON should use I-JSON >> (perhaps even provide references to the jose specifications). >> https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html >> >> >> > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3674200ceaa050d7e0b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty <kathleen.m= oriarty.ietf@gmail.com> wrote:
<editor-hat>

I thought that claiming th= at I-JSON offered qualitatively better security was a little immodest.=C2= =A0 If there=E2=80=99s general agreement with Kathleen and SecDir, I=E2=80= =99d be happy to introduce such language. There are two options:
1. Note that =E2=80=9C=C2=A0I-JSON=C2=A0restricts and limi= ts some=C2=A0of
=E2=80=8B=E2=80=8B=C2=A0
the danger
=E2=80=8B=E2=80=8B=
ous formats of the original=C2=A0JSON, therefore it might be=C2=A0considered
=E2=80=8B=E2=80=8B=C2=A0
more s= ecure
=E2=80=8B=E2=80=8B=E2=80=9D
=
2. Asser= t that security-critical usages of JSON should (or SHOULD?) use I-JSON

For coding related is= sues, security is a bit better when there are limits/restrictions for parse= rs.=C2=A0 I think Stephen pointed out a few things he thought were going to= happen to further restrict, that didn't.=C2=A0 However, your proposed = language looks good to me and leaves a little leeway.

<= /blockquote>

=E2=80=8BUm, which of the two, or both?=C2=A0 Seriously, an IET= F-consensus assertion that security-sensitive people SHOULD use I-JSON feel= s like a big deal to me.=C2=A0 However, I think that=E2=80=99s what I=E2=80= =99m hearing, so unless there are screams I=E2=80=99ll go put some combo of= #1 and #2 above in the next revision.=E2=80=8B


=C2=A0
<= /div>
Thanks,
Kathleen



=
On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moria= rty <Kathleen.Moriarty.ietf@gmail.com> wrote:=
Kathleen Moriarty has entered the follow= ing ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir reviewer in his assessment of this draft after
reading it.=C2=A0 I'm putting this in as comments/suggestions to be con= sidered
as the security considerations really should be in the JSON document.=C2=A0= If
any considerations are missing, that is where I'd expect to see them. The JSON format is not simple, so=C2=A0 agree with the SecDir reviewer that=
one would have expected additional handling considerations for security
purposes to be in that document.=C2=A0 They don't need to be listed in = this
one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some
of
the dangerous formats of the original JSON, therefore it might be
considered
more secure than the original JSON.=C2=A0 Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/= msg05380.html





--
- Tim Bray (If you=E2=80=99d like to send me a private messa= ge, see https://ke= ybase.io/timbray)



--
- Tim Bray (If you=E2=80=99d like to send me a private message, se= e https://keybase.= io/timbray)
--001a11c3674200ceaa050d7e0b30-- From nobody Sun Jan 25 11:41:34 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29041A1A8F; Sun, 25 Jan 2015 11:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfzC9rj85XLB; Sun, 25 Jan 2015 11:41:31 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC751A1A4E; Sun, 25 Jan 2015 11:41:31 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id n8so4385717qaq.4; Sun, 25 Jan 2015 11:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UgZB/giH/rJU590YiwSzoa+Yxw7JKK7RNE/Cbs2JFN0=; b=glU/9u2nJ09ovhKbY3OzOmLvkp5vdOo3vBIZfcqdLuCPaffy1dMgZnlrqrE8fworVB QbQ+2LP9/YcfBtg22ed+oiFieZ0Kzf131CsnDLfyhoydEPxIYLTOSptkb4MRp2Ug7czP UkwUkl2c+MdEW7jroPJXUlW2ko1nvB4Xu2nYlV30YVRJ5qEfWFTYJC6fa+YokF+SCpTY WIyfO7ifcX6otJQYb7AsDNk5D2L0t5v5gPNyuJ67tBF+WHzaeBsB7Kujt833HmctR/PJ wbmVvBZgj87Py4Ir+irZiCo8ldYieTpBDQbKOxqUOleIfaZmcst2wqfHdK3GlUJe5Gw+ D2Rw== X-Received: by 10.140.96.33 with SMTP id j30mr33101618qge.92.1422214889964; Sun, 25 Jan 2015 11:41:29 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id a6sm704142qgf.13.2015.01.25.11.41.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Jan 2015 11:41:28 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-DB589694-8540-43F6-865B-C9413FF61C2E Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 25 Jan 2015 14:41:28 -0500 Content-Transfer-Encoding: 7bit Message-Id: <93075CD3-6864-4A0B-8E37-DB25ED0FB1A0@gmail.com> References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> To: Tim Bray Archived-At: Cc: "json-chairs@tools.ietf.org" , "json@ietf.org" , Matt Miller , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 19:41:33 -0000 --Apple-Mail-DB589694-8540-43F6-865B-C9413FF61C2E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Sent from my iPhone > On Jan 25, 2015, at 1:17 PM, Tim Bray wrote: >=20 > On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty wrote: >>> >>>=20 >>> I thought that claiming that I-JSON offered qualitatively better securit= y was a little immodest. If there=E2=80=99s general agreement with Kathleen= and SecDir, I=E2=80=99d be happy to introduce such language. There are two o= ptions: >>> 1. Note that =E2=80=9C I-JSON restricts and limits some of=E2=80=8B=E2=80= =8B the danger=E2=80=8B=E2=80=8Bous formats of the original JSON, therefore i= t might be considered=E2=80=8B=E2=80=8B more secure=E2=80=8B=E2=80=8B=E2=80=9D= >>> 2. Assert that security-critical usages of JSON should (or SHOULD?) use I= -JSON >>=20 >> For coding related issues, security is a bit better when there are limits= /restrictions for parsers. I think Stephen pointed out a few things he thou= ght were going to happen to further restrict, that didn't. However, your pr= oposed language looks good to me and leaves a little leeway. >=20 > =E2=80=8BUm, which of the two, or both? Seriously, an IETF-consensus asse= rtion that security-sensitive people SHOULD use I-JSON feels like a big deal= to me. However, I think that=E2=80=99s what I=E2=80=99m hearing, so unless= there are screams I=E2=80=99ll go put some combo of #1 and #2 above in the n= ext revision.=E2=80=8B I meant to say #1 as the language wasn't strong, but said enough to be helpf= ul. Thanks, Kathleen=20 >=20 >=20 > =20 >> Thanks, >> Kathleen >>=20 >>>=20 >>>=20 >>>> On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty wrote: >>>> Kathleen Moriarty has entered the following ballot position for >>>> draft-ietf-json-i-json-05: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this= >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ >>>>=20 >>>>=20 >>>>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> I agree with the SecDir reviewer in his assessment of this draft after >>>> reading it. I'm putting this in as comments/suggestions to be consider= ed >>>> as the security considerations really should be in the JSON document. I= f >>>> any considerations are missing, that is where I'd expect to see them. >>>> The JSON format is not simple, so agree with the SecDir reviewer that >>>> one would have expected additional handling considerations for security= >>>> purposes to be in that document. They don't need to be listed in this >>>> one. >>>>=20 >>>> Having said that, it might be good idea to add text to the security >>>> considerations section, to state that I-JSON restricts and limits some >>>> of >>>> the dangerous formats of the original JSON, therefore it might be >>>> considered >>>> more secure than the original JSON. Perhaps also mention that >>>> security critical usages of the JSON should use I-JSON >>>> (perhaps even provide references to the jose specifications). >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html >>>=20 >>>=20 >>>=20 >>> --=20 >>> - Tim Bray (If you=E2=80=99d like to send me a private message, see http= s://keybase.io/timbray) >=20 >=20 >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see https:= //keybase.io/timbray) --Apple-Mail-DB589694-8540-43F6-865B-C9413FF61C2E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Sent from my iPhone

On Jan 25, 2015, at 1:17 PM, Tim Bray <tbray@textuality.com> wrote:

On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
<editor-hat>

I thought that= claiming that I-JSON offered qualitatively better security was a little imm= odest.  If there=E2=80=99s general agreement with Kathleen and SecDir, I= =E2=80=99d be happy to introduce such language. There are two options:
=
1. Note that =E2=80=9C I-JSON restricts and li= mits some of
=E2=80=8B=E2=80=8B 
the danger
=E2=80=8B=E2=80=8B<= /div>ous formats of the original = JSON, therefore it might be considered
=E2=80=8B=E2=80=8B 
more secure=
=E2=80=8B=E2=80=8B=E2=80=9D
=
2. Assert that s= ecurity-critical usages of JSON should (or SHOULD?) use I-JSON

For coding related issues, secu= rity is a bit better when there are limits/restrictions for parsers.  I= think Stephen pointed out a few things he thought were going to happen to f= urther restrict, that didn't.  However, your proposed language looks go= od to me and leaves a little leeway.

<= br>
=E2=80=8B= Um, which of the two, or both?  Seriously, an IETF-consensus assertion t= hat security-sensitive people SHOULD use I-JSON feels like a big deal to me.=   However, I think that=E2=80=99s what I=E2=80=99m hearing, so unless t= here are screams I=E2=80=99ll go put some combo of #1 and #2 above in the ne= xt revision.=E2=80=8B
<= br>
I meant to say #1 as the language wasn't strong, but said enough to= be helpful.

Thanks,
Kathleen 


 
Thanks,
Kathl= een



On Mon, J= an 19, 2015 at 12:24 PM, Kathleen Moriarty <Kathleen.Moriarty= .ietf@gmail.com> wrote:
Kathl= een Moriarty has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criter= ia.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir reviewer in his assessment of this draft after
reading it.  I'm putting this in as comments/suggestions to be consider= ed
as the security considerations really should be in the JSON document.  I= f
any considerations are missing, that is where I'd expect to see them.
The JSON format is not simple, so  agree with the SecDir reviewer that<= br> one would have expected additional handling considerations for security
purposes to be in that document.  They don't need to be listed in this<= br> one.

Having said that, it might be good idea to add text to the security
considerations section, to state that I-JSON restricts and limits some
of
the dangerous formats of the original JSON, therefore it might be
considered
more secure than the original JSON.  Perhaps also mention that
security critical usages of the JSON should use I-JSON
(perhaps even provide references to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/ms= g05380.html





--
- Tim Bray (If you=E2=80=99d like to send me a private message= , see https://keyba= se.io/timbray)



--
=
- Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timb= ray)
= --Apple-Mail-DB589694-8540-43F6-865B-C9413FF61C2E-- From nobody Sun Jan 25 12:03:54 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB81A1BDA; Sun, 25 Jan 2015 12:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6s_Uub6LfaX; Sun, 25 Jan 2015 12:03:45 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D216F1A1B06; Sun, 25 Jan 2015 12:03:45 -0800 (PST) Received: from Philemon (173-164-94-161-Oregon.hfc.comcastbusiness.net [173.164.94.161]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9A1F038EF1; Sun, 25 Jan 2015 12:03:44 -0800 (PST) From: "Jim Schaad" To: "'Kathleen Moriarty'" , "'Tim Bray'" References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> <93075CD3-6864-4A0B-8E37-DB25ED0FB1A0@gmail.com> In-Reply-To: <93075CD3-6864-4A0B-8E37-DB25ED0FB1A0@gmail.com> Date: Sun, 25 Jan 2015 12:03:00 -0800 Message-ID: <079d01d038d9$ec317fb0$c4947f10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_079E_01D03896.DE123750" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGssBGtRW8rSnaMfTuMROiZSysdUANLCNzZAqE3muEC4qttSAGzw9hfnMQ+FEA= Archived-At: Cc: 'Matt Miller' , draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, 'The IESG' , json@ietf.org Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 20:03:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_079E_01D03896.DE123750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would agree with Kathleen on this. Its better but not everything is = there. =20 Jim =20 =20 From: json [mailto:json-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Sunday, January 25, 2015 11:41 AM To: Tim Bray Cc: json-chairs@tools.ietf.org; json@ietf.org; Matt Miller; The IESG; = draft-ietf-json-i-json.all@tools.ietf.org Subject: Re: [Json] Kathleen Moriarty's No Objection on = draft-ietf-json-i-json-05: (with COMMENT) =20 Hi Tim, Sent from my iPhone On Jan 25, 2015, at 1:17 PM, Tim Bray wrote: On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty = wrote: =20 I thought that claiming that I-JSON offered qualitatively better = security was a little immodest. If there=E2=80=99s general agreement = with Kathleen and SecDir, I=E2=80=99d be happy to introduce such = language. There are two options: 1. Note that =E2=80=9C I-JSON restricts and limits some of =E2=80=8B=E2=80=8B=20 the danger =E2=80=8B=E2=80=8B ous formats of the original JSON, therefore it might be considered =E2=80=8B=E2=80=8B=20 more secure =E2=80=8B=E2=80=8B=E2=80=9D 2. Assert that security-critical usages of JSON should (or SHOULD?) use = I-JSON =20 For coding related issues, security is a bit better when there are = limits/restrictions for parsers. I think Stephen pointed out a few = things he thought were going to happen to further restrict, that didn't. = However, your proposed language looks good to me and leaves a little = leeway. =20 =20 =E2=80=8BUm, which of the two, or both? Seriously, an IETF-consensus = assertion that security-sensitive people SHOULD use I-JSON feels like a = big deal to me. However, I think that=E2=80=99s what I=E2=80=99m = hearing, so unless there are screams I=E2=80=99ll go put some combo of = #1 and #2 above in the next revision.=E2=80=8B =20 I meant to say #1 as the language wasn't strong, but said enough to be = helpful. =20 Thanks, Kathleen=20 =20 =20 =20 Thanks, Kathleen =20 =20 On Mon, Jan 19, 2015 at 12:24 PM, Kathleen Moriarty = wrote: Kathleen Moriarty has entered the following ballot position for draft-ietf-json-i-json-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir reviewer in his assessment of this draft after reading it. I'm putting this in as comments/suggestions to be = considered as the security considerations really should be in the JSON document. = If any considerations are missing, that is where I'd expect to see them. The JSON format is not simple, so agree with the SecDir reviewer that one would have expected additional handling considerations for security purposes to be in that document. They don't need to be listed in this one. Having said that, it might be good idea to add text to the security considerations section, to state that I-JSON restricts and limits some of the dangerous formats of the original JSON, therefore it might be considered more secure than the original JSON. Perhaps also mention that security critical usages of the JSON should use I-JSON (perhaps even provide references to the jose specifications). https://www.ietf.org/mail-archive/web/secdir/current/msg05380.html =20 --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) =20 --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) ------=_NextPart_000_079E_01D03896.DE123750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would agree with Kathleen on this.=C2=A0 Its better but not = everything is there.

 

Jim

 

 

From:= = json [mailto:json-bounces@ietf.org] On Behalf Of Kathleen = Moriarty
Sent: Sunday, January 25, 2015 11:41 AM
To: = Tim Bray
Cc: json-chairs@tools.ietf.org; json@ietf.org; Matt = Miller; The IESG; = draft-ietf-json-i-json.all@tools.ietf.org
Subject: Re: [Json] = Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with = COMMENT)

 

Hi = Tim,

Sent from my iPhone


On Jan 25, 2015, at = 1:17 PM, Tim Bray <tbray@textuality.com> = wrote:

On Fri, Jan 23, 2015 at 4:34 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

<editor-hat>

 

I = thought that claiming that I-JSON offered qualitatively better security = was a little immodest.  If there=E2=80=99s general agreement with = Kathleen and SecDir, I=E2=80=99d be happy to introduce such language. = There are two options:

1. = Note that =E2=80=9C I-JSON restricts and limits = some of

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

the = danger

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

ous formats of the = original JSON, therefore it might = be considered

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

more = secure

=E2=80=8B=E2=80=8B=E2=80=9D

<= div>

2. Assert that security-critical usages of = JSON should (or SHOULD?) use = I-JSON

 

For = coding related issues, security is a bit better when there are = limits/restrictions for parsers.  I think Stephen pointed out a few = things he thought were going to happen to further restrict, that = didn't.  However, your proposed language looks good to me and = leaves a little leeway.

 

 

=E2=80=8BUm, which of the two, or both?  = Seriously, an IETF-consensus assertion that security-sensitive people = SHOULD use I-JSON feels like a big deal to me.  However, I think = that=E2=80=99s what I=E2=80=99m hearing, so unless there are screams = I=E2=80=99ll go put some combo of #1 and #2 above in the next = revision.=E2=80=8B

 

I meant to say #1 as the language wasn't strong, but = said enough to be helpful.

 

Thanks,

Kathleen 

 

 

 

Thanks,

Kathleen



 

 

On Mon, = Jan 19, 2015 at 12:24 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> = wrote:

Kathleen Moriarty has entered the = following ballot position for
draft-ietf-json-i-json-05: No = Objection

When responding, please keep the subject line intact = and reply to all
email addresses included in the To and CC lines. = (Feel free to cut this
introductory paragraph, = however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/=



-----------------------------------------------------= -----------------
COMMENT:
----------------------------------------= ------------------------------

I agree with the SecDir reviewer = in his assessment of this draft after
reading it.  I'm putting = this in as comments/suggestions to be considered
as the security = considerations really should be in the JSON document.  If
any = considerations are missing, that is where I'd expect to see them.
The = JSON format is not simple, so  agree with the SecDir reviewer = that
one would have expected additional handling considerations for = security
purposes to be in that document.  They don't need to be = listed in this
one.

Having said that, it might be good idea to = add text to the security
considerations section, to state that I-JSON = restricts and limits some
of
the dangerous formats of the original = JSON, therefore it might be
considered
more secure than the = original JSON.  Perhaps also mention that
security critical = usages of the JSON should use I-JSON
(perhaps even provide references = to the jose specifications).
https://www.ietf.org/mail-archive/web/secdir/current/ms= g05380.html



 

-- =

- Tim Bray (If = you=E2=80=99d like to send me a private message, see https://keybase.io/timbray)



 

-- =

- Tim Bray (If = you=E2=80=99d like to send me a private message, see https://keybase.io/timbray)

------=_NextPart_000_079E_01D03896.DE123750-- From nobody Sun Jan 25 13:09:11 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80641A6FF7; Sun, 25 Jan 2015 13:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgXI5ZZsm7ii; Sun, 25 Jan 2015 13:09:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC731A0075; Sun, 25 Jan 2015 13:09:07 -0800 (PST) Received: from netb ([89.204.138.128]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MYOCL-1YAlJY1er3-00V7M5; Sun, 25 Jan 2015 22:08:45 +0100 From: Bjoern Hoehrmann To: Tim Bray Date: Sun, 25 Jan 2015 22:07:58 +0100 Message-ID: References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:fQaIaIVyx0AgbxRi6F7hqT+fYjQtYPyM4JTLh9yjAB7hV1O51oi M1jqo3KIiPVGedvT3Sq71yYnTHpelNQYz2SWDZ+oX1xC+nP5Kzyb4mS6sCi3yyVCOKD21/G QlPzaBoQoDs2a03cKOTmaRF+G7pFqGqkv28hiZc+8l8APm0zRtHM7sLbIAKswhU/y+gX4u9 uAkk2edDC1eDzHXYRsEdw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Matt Miller , "json@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 21:09:09 -0000 * Tim Bray wrote: >Um, which of the two, or both? Seriously, an IETF-consensus assertion >that security-sensitive people SHOULD use I-JSON feels like a big deal to >me. However, I think that’s what I’m hearing, so unless there are screams >I’ll go put some combo of #1 and #2 above in the next revision.? That would pretty much give I-JSON BCP status for all future protocols. I think such a change requires another Last Call. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Sun Jan 25 13:19:27 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF9D1A7005; Sun, 25 Jan 2015 13:19:25 -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] 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 51pX-uhESDgP; Sun, 25 Jan 2015 13:19:24 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E7F1A001C; Sun, 25 Jan 2015 13:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t0PLJIOp002703; Sun, 25 Jan 2015 22:19:18 +0100 (CET) Received: from alma.local (p5DCCCF76.dip0.t-ipconnect.de [93.204.207.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kVnCB3QPsz84X7; Sun, 25 Jan 2015 22:19:18 +0100 (CET) Message-ID: <54C55DD5.6070202@tzi.org> Date: Sun, 25 Jan 2015 22:19:17 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Tim Bray References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Matt Miller , "json@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 21:19:25 -0000 On 2015-01-25 22:07, Bjoern Hoehrmann wrote: > * Tim Bray wrote: >> Um, which of the two, or both? Seriously, an IETF-consensus assertion >> that security-sensitive people SHOULD use I-JSON feels like a big deal to >> me. However, I think that’s what I’m hearing, so unless there are screams >> I’ll go put some combo of #1 and #2 above in the next revision.? > > That would pretty much give I-JSON BCP status for all future protocols. > I think such a change requires another Last Call. I don't think that would be right (or that we have consensus for that). (See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.) Grüße, Carsten From nobody Sun Jan 25 13:46:35 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BF1A0065; Sun, 25 Jan 2015 13:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 toltteO6Wx3T; Sun, 25 Jan 2015 13:46:25 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA7C1A003A; Sun, 25 Jan 2015 13:46:25 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id p6so4692129qcv.1; Sun, 25 Jan 2015 13:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RSzgzJ74Fz1Doo7SDN+jsqURFPX7ftecjibcf2WIunw=; b=nJSQ7xTOvXilswMpVyYNFe70P7lEJY94FnQKrZvf+YHxgzGivTwBQQzGX0uZN1WQYZ g3eVeoF7yfELCAcPW1AHxu8k3n71Z6NUouimFajgNjRhda7uQmvENSkBtO56E8f9G+Ot CMxMbzcCtS3JJAIwRrwvsIgV7hj32DspxzNiS6d/oxDvh9N5LHBLY7Inyl5ktg5toGrq 8cxandr35yUCdH9ZcVDkiwdj+n/W6bl6gpl/xFXYpwE29YieDO13wceslZERzAgis9AV 7sjE31iKzu5ch3fVxNpP1C+bVb1SA9TTPxihkESvBKCodZTkViT0mQ37b2y9D4b/ZHwj PDAQ== X-Received: by 10.229.35.74 with SMTP id o10mr35994127qcd.26.1422222384917; Sun, 25 Jan 2015 13:46:24 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id n4sm3530162qas.20.2015.01.25.13.46.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Jan 2015 13:46:23 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54C55DD5.6070202@tzi.org> Date: Sun, 25 Jan 2015 16:46:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A73174A-E71E-4A8A-9557-2DFD83D8B865@gmail.com> References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> <54C55DD5.6070202@tzi.org> To: Carsten Bormann Archived-At: Cc: Bjoern Hoehrmann , Matt Miller , "json@ietf.org" , Tim Bray , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 21:46:29 -0000 Sent from my iPhone > On Jan 25, 2015, at 4:19 PM, Carsten Bormann wrote: >=20 >> On 2015-01-25 22:07, Bjoern Hoehrmann wrote: >> * Tim Bray wrote: >>> Um, which of the two, or both? Seriously, an IETF-consensus assertion >>> that security-sensitive people SHOULD use I-JSON feels like a big deal t= o >>> me. However, I think that=E2=80=99s what I=E2=80=99m hearing, so unless= there are screams >>> I=E2=80=99ll go put some combo of #1 and #2 above in the next revision.?= >>=20 >> That would pretty much give I-JSON BCP status for all future protocols. >> I think such a change requires another Last Call. >=20 > I don't think that would be right (or that we have consensus for that). This is what we are talking about, a light statement that saying what's diff= erent and it might be more secure: 1. Note that =E2=80=9C I-JSON restricts and limits some of the dangerous for= mats of the original JSON, therefore it might be considered more secure. I don't think this is enough to be considered a BCP with the wired might, ho= wever it is well known that restrictions on formats for parsing helps to red= uce/prevent security issues. =20 >=20 > (See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.)= Do you have the link? Thanks, Kathleen >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Sun Jan 25 13:56:38 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE681A005D; Sun, 25 Jan 2015 13:56:32 -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] 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 rNNfxpqM33c8; Sun, 25 Jan 2015 13:56:31 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5D91A000C; Sun, 25 Jan 2015 13:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t0PLuQKn026821; Sun, 25 Jan 2015 22:56:26 +0100 (CET) Received: from alma.local (p5DCCCF76.dip0.t-ipconnect.de [93.204.207.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kVp223BLHz84XX; Sun, 25 Jan 2015 22:56:26 +0100 (CET) Message-ID: <54C56689.3070502@tzi.org> Date: Sun, 25 Jan 2015 22:56:25 +0100 From: Carsten Bormann User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150119202407.30240.3882.idtracker@ietfa.amsl.com> <8153A076-798F-412A-94EF-543848607C9B@gmail.com> <54C55DD5.6070202@tzi.org> <1A73174A-E71E-4A8A-9557-2DFD83D8B865@gmail.com> In-Reply-To: <1A73174A-E71E-4A8A-9557-2DFD83D8B865@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Bjoern Hoehrmann , Matt Miller , "json@ietf.org" , Tim Bray , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" Subject: Re: [Json] Kathleen Moriarty's No Objection on draft-ietf-json-i-json-05: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jan 2015 21:56:32 -0000 >> I don't think that would be right (or that we have consensus for that). > > This is what we are talking about, a light statement that saying what's different and it might be more secure: > > 1. Note that “ I-JSON restricts and limits some of the dangerous formats of the original JSON, therefore it might be considered more secure. I'm much more comfortable with that text than with Bjoern's hypothetical elevation to "BCP" (which is what I was reacting to). > I don't think this is enough to be considered a BCP with the wired might, however it is well known that restrictions on formats for parsing helps to reduce/prevent security issues. One problem is that when you add arbitrary restrictions to what parts of the data model you can express, this leads to having to add code to work around those restrictions, which work-arounds may have their own undesirable security properties. >> >> (See the off-IESG thread on the JSON mailing list on Ted Lemon's comment.) > > Do you have the link? http://www.ietf.org/mail-archive/web/json/current/msg03573.html Grüße, Carsten From nobody Mon Jan 26 23:18:10 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7E1B2BAB for ; Mon, 26 Jan 2015 23:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B890gG0GKYIe for ; Mon, 26 Jan 2015 23:18:02 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AF01B2BA8 for ; Mon, 26 Jan 2015 23:18:01 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so11737904lab.10 for ; Mon, 26 Jan 2015 23:18:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=SJ6pDEZi6cu6h8Y1MKp4z3kX7Us+KHaw/sNgUghrlHY=; b=TlBOcstY7hJGF1amfdAivnDMFN8PqaneJXVVPIjodazzNY8C/Wfuica5imFFte1kcQ syRkiPGJoYSazG/qThgN4NMQm7mkcon0KXvnSqAqwYJqRXsCFu7mv14aG6YfKnjkuaea YbRCRAOfKsdEeMqWprjPsxB6tFtd/RdmReN6RS53wDooznR2Ar/7fV65+HLQVTB/QMe5 Q4e7QE/zRWZOyukM7HodsqlsVV/SsHDlb4RFAU9yOssMCVYOfsEoVNppV2JI8+KxtLiL /Lq+9sFaovnAHLQE9+8u3m1aXjnBTTe3SZtZdc2RsH0yZAJYsfmbETVcm3CM9auCotQV SzJg== X-Gm-Message-State: ALoCoQkRYtw+vIlBFoz0tJ4NyMO3sf8BBHDT2AUFyscZkTDmIitFf+EONX4ohOblS24L6IpAiGHd X-Received: by 10.112.99.71 with SMTP id eo7mr2397543lbb.26.1422343080136; Mon, 26 Jan 2015 23:18:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Mon, 26 Jan 2015 23:17:39 -0800 (PST) X-Originating-IP: [24.84.235.32] From: Tim Bray Date: Mon, 26 Jan 2015 23:17:39 -0800 Message-ID: To: Matthew Miller Content-Type: multipart/alternative; boundary=001a113488a20a6765050d9d0e87 Archived-At: Cc: John Cowan , "json@ietf.org" , Ted Lemon , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" , The IESG Subject: [Json] I-JSON-06 draft notes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2015 07:18:04 -0000 --001a113488a20a6765050d9d0e87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 25, 2015 at 10:15 AM, Matthew Miller wrote: > =E2=80=8B=E2=80=8B > Yes, go ahead and publish an update when you can. > =E2=80=8BOmitting discussion of repairs to typo and thinkos, for which good= catches thanks to all. =E2=80=8B =E2=80=8BTaking notes as I work through https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ballot/ and following email threads - inserting Unicode sect. 2.4 reference for Noncharacter & Surrogate. I can never figure out how to make
On = Sun, Jan 25, 2015 at 10:15 AM, Matthew Miller <linuxwolf@outer-pl= anes.net> wrote:

=E2=80=8B=E2=80=8B
Y= es, go ahead and publish an update when you can.

<= /div>
=E2=80=8BOmitting discussion of repairs to typo and thinkos, for which= good catches thanks to all.
=E2=80=8B
=C2=A0
=E2=80=8BTaking notes a= s I work through https://datatracker.ietf.org/doc/draft-= ietf-json-i-json/ballot/=C2=A0and following email threads

- inserting Unicode sect. 2.4 referenc= e for Noncharacter & Surrogate. I can never figure out how to make <= xref mention a section nicely but I bet the RFC Ed can.

- Barry, but nobody else I think, wanted 211= 9 language removed from =E2=80=8Bsection 4.=C2=A0 Some of those uses are me= ta- as in =E2=80=9Chere=E2=80=99s how you=E2=80=99d use 2119 language to sp= ecify I-JSON=E2=80=9D; there remain three:

4.1 =E2=80=9CProtocol designers SHOULD NOT use top-level = JSON texts which are neither objects nor arrays=E2=80=9D
4.3 two SHOULDs in recommendation= s to stick to 8601/3339 for dates
4.4 =E2=80=9CWhen it is required that an I-JSON protoc= ol element contain arbitrary binary data, it is RECOMMENDED that this data = be encoded in a string value in base64url...=E2=80=9D

I=E2=80=99m pretty uncomfortable removing any = of these; they had strong WG consensus backing and are things that the IETF= should be comfortable saying.=C2=A0 Does the IESG or our AD want to insist= ?

- I don=E2=80=99t think= the draft needs to further define =E2=80=9Cconformance=E2=80=9D=C2=A0

- Added language along the li= nes suggested by Tero/Kathleen about I-JSON perhaps offering security advan= tages, without sounding BCP-ish

- Per Stephen, recommended that TZ be included not defaulted in date= s, and that trailing 00 seconds not be omitted

- Per Ted, nuked the unnecessary =E2=80=9CIn particul= ar=E2=80=9D about integers.

- Added a note about the irritating background to the 64-bit int mention= .

Absent big arguments, w= ill publish this in a day or so.

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

--001a113488a20a6765050d9d0e87-- From nobody Mon Jan 26 23:43:36 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99AB1B2BB2; Mon, 26 Jan 2015 23:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNJVsR5iH2a8; Mon, 26 Jan 2015 23:43:33 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACD01B2BB3; Mon, 26 Jan 2015 23:43:33 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so11795370lab.12; Mon, 26 Jan 2015 23:43:31 -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=N3gtq3/a20jzStd3lx2RAVh0vH1HJKa6DcIlvnG5XSc=; b=BQE1ECeR4TpG3ONw9zskG4vUP4rTNEa7D8o48SRcO5sd4YXRTkLZ6lFLwzpcn04n/1 v/zTyKqejCRf5CroYNV7qG0/4czWkC/4wTqwwx4YhEmsRd7ifLmcm8E7eW9fZZpSG9zg S3f0fJzgeS5BFbiAKJ78GqqIeLGyPWsHnkFnP3hi6dAKsGF6oZqshS9Vsf2w/oUjwrgt 7e6PYTZaI7FnBpZZphlK1vTNsrgK2Cc8l1T6IB9IgqUB5PcZ3FAEuwVyqJxQFO5VfpBS 44JUWglYVST9wF1I9wA8Gxu1GrLLniN+s7Ei7jcyyMYr2231t+36X2YCIcqs0beSvMVJ QWLQ== MIME-Version: 1.0 X-Received: by 10.152.87.210 with SMTP id ba18mr2431158lab.3.1422344611758; Mon, 26 Jan 2015 23:43:31 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 26 Jan 2015 23:43:31 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Jan 2015 08:43:31 +0100 X-Google-Sender-Auth: sb1E8U_QQ4illvIWaHlWqh9U4h8 Message-ID: From: Barry Leiba To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c23d64550c6e050d9d69db Archived-At: Cc: John Cowan , Matthew Miller , "json@ietf.org" , Ted Lemon , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" , The IESG Subject: Re: [Json] I-JSON-06 draft notes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2015 07:43:34 -0000 --001a11c23d64550c6e050d9d69db Content-Type: text/plain; charset=ISO-8859-1 > > - Barry, but nobody else I think, wanted 2119 language removed from > section 4. Some of those uses are meta- as in "here's how you'd use 2119 > language to specify I-JSON"; there remain three: > Barry, but nobody else, only mildly wanted that, and he is happy with the decision that WG consensus is to leave it in. Thanks for considering it again. Barry, but nobody else --001a11c23d64550c6e050d9d69db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=
- Barry, but nobody else I think, wanted 2119 language removed from = section 4.  Some of those uses are meta- as in “here’s how= you’d use 2119 language to specify I-JSON”; there remain three= :

Barry, but no= body else, only mildly wanted that, and he is happy with the decision that = WG consensus is to leave it in.  Thanks for considering it again.

Barry, but nobody else
 
--001a11c23d64550c6e050d9d69db-- From nobody Tue Jan 27 02:18:34 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016DE1A8766; Tue, 27 Jan 2015 02:18:28 -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 chYLZqkpHvCe; Tue, 27 Jan 2015 02:18:26 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 042781A8761; Tue, 27 Jan 2015 02:18:26 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AB2661CC03BB; Tue, 27 Jan 2015 11:18:27 +0100 (CET) From: Ladislav Lhotka To: Tim Bray , Matthew Miller In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 27 Jan 2015 11:18:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: John Cowan , "json@ietf.org" , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" , Ted Lemon Subject: Re: [Json] I-JSON-06 draft notes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2015 10:18:28 -0000 Tim Bray writes: > On Sun, Jan 25, 2015 at 10:15 AM, Matthew Miller > wrote: > >> =E2=80=8B=E2=80=8B >> Yes, go ahead and publish an update when you can. >> > > =E2=80=8BOmitting discussion of repairs to typo and thinkos, for which go= od catches > thanks to all. > =E2=80=8B > > =E2=80=8BTaking notes as I work through > https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ballot/ and > following email threads > > - inserting Unicode sect. 2.4 reference for Noncharacter & Surrogate. I c= an > never figure out how to make RFC Ed can. > > - Barry, but nobody else I think, wanted 2119 language removed from > =E2=80=8Bsection 4. Some of those uses are meta- as in =E2=80=9Chere=E2= =80=99s how you=E2=80=99d use 2119 > language to specify I-JSON=E2=80=9D; there remain three: > > 4.1 =E2=80=9CProtocol designers SHOULD NOT use top-level JSON texts which= are > neither objects nor arrays=E2=80=9D > 4.3 two SHOULDs in recommendations to stick to 8601/3339 for dates > 4.4 =E2=80=9CWhen it is required that an I-JSON protocol element contain = arbitrary > binary data, it is RECOMMENDED that this data be encoded in a string value > in base64url...=E2=80=9D Is it still I-JSON if another encoding is used for binary data, provided valid reasons for the choice exist? Or are some encodings incompatible with I-JSON? Thanks, Lada > > I=E2=80=99m pretty uncomfortable removing any of these; they had strong WG > consensus backing and are things that the IETF should be comfortable > saying. Does the IESG or our AD want to insist? > > - I don=E2=80=99t think the draft needs to further define =E2=80=9Cconfor= mance=E2=80=9D > > - Added language along the lines suggested by Tero/Kathleen about I-JSON > perhaps offering security advantages, without sounding BCP-ish > > - Per Stephen, recommended that TZ be included not defaulted in dates, and > that trailing 00 seconds not be omitted > > - Per Ted, nuked the unnecessary =E2=80=9CIn particular=E2=80=9D about in= tegers. > > - Added a note about the irritating background to the 64-bit int mention. > > Absent big arguments, will publish this in a day or so. > > =E2=80=8B=E2=80=8B > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 27 08:27:50 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479FE1A8892; Tue, 27 Jan 2015 08:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JxROyycAd_j; Tue, 27 Jan 2015 08:27:29 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA621A8864; Tue, 27 Jan 2015 08:27:28 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1YG8ye-0000cB-Fy; Tue, 27 Jan 2015 11:26:56 -0500 Date: Tue, 27 Jan 2015 11:26:56 -0500 From: John Cowan To: Ladislav Lhotka Message-ID: <20150127162656.GD23262@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: John Cowan , Matthew Miller , "json@ietf.org" , Tim Bray , The IESG , "draft-ietf-json-i-json.all@tools.ietf.org" , "json-chairs@tools.ietf.org" , Ted Lemon Subject: Re: [Json] I-JSON-06 draft notes X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jan 2015 16:27:32 -0000 Ladislav Lhotka scripsit: > Is it still I-JSON if another encoding is used for binary data, provided > valid reasons for the choice exist? Or are some encodings incompatible > with I-JSON? Of course. You can't look at a string "chat" and tell if it's encoded binary or a protocol element or English text or French text. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli From nobody Tue Jan 27 18:22:16 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2011ACC87; Tue, 27 Jan 2015 18:22:08 -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 rRWcH1Acc_Tf; Tue, 27 Jan 2015 18:22:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6C1ACCD8; Tue, 27 Jan 2015 18:22:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128022202.18746.54930.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 18:22:02 -0800 Archived-At: Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-i-json-06.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: Wed, 28 Jan 2015 02:22:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : The I-JSON Message Format Author : Tim Bray Filename : draft-ietf-json-i-json-06.txt Pages : 6 Date : 2015-01-27 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-i-json-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 27 18:22:18 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6B1ACC91 for ; Tue, 27 Jan 2015 18:22:10 -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 dxzjMQDQimAz; Tue, 27 Jan 2015 18:22:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F821ACCDA; Tue, 27 Jan 2015 18:22:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org, presnick@qti.qualcomm.com, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128022203.18746.6102.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 18:22:03 -0800 Archived-At: Subject: [Json] New Version Notification - draft-ietf-json-i-json-06.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: Wed, 28 Jan 2015 02:22:10 -0000 A new version (-06) has been submitted for draft-ietf-json-i-json: http://www.ietf.org/internet-drafts/draft-ietf-json-i-json-06.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-06 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. IETF Secretariat. From nobody Tue Jan 27 18:24:07 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA681ACC8A for ; Tue, 27 Jan 2015 18:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRoJ8BpuD6t3 for ; Tue, 27 Jan 2015 18:24:02 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4321ACC82 for ; Tue, 27 Jan 2015 18:24:01 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id p9so16317546lbv.8 for ; Tue, 27 Jan 2015 18:24:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SD3F+HXwxfPCEFP5u1Lg/t6wxV/wG2lc0m1C4e0haus=; b=IhM0noFPe1KplZQ0bYNk0mn408FGCFJUMliT23MwgU3revoIIfaJ+UHI+YQUIQd6pA D6+O9vqFazHY0xGG5EEz5LRuYzzuFqf6fok3rF2MFt05HHCVy/3213Yv+Ye2jymbhGDg 1KZoQmY1xJjFgFP2YKw+3LtgniXiKbK/a0kPuZQYDrBSpnhB0GPomx9pO0BgcVblqhbF alTCm1SJAjrFbaZOghjTrcKajtQrqezvbuzlkVvk1vloN7IWe9CKfjySIEeV68JvfE+I 8cAGcUaPGEu4Pg6JKhy4B5T8shkW+ivehHvJXrOYvVfC1mR4oVWNQOdGXctB/8KTeofq n62g== X-Gm-Message-State: ALoCoQl5Wv0hciQGnHeYS3LmXqnbOVx6ppGY1VqZ3GNeKjLmMSJLVRWZVUM0Y+Z+XmdL4KH2a9hC X-Received: by 10.112.134.74 with SMTP id pi10mr5212627lbb.67.1422411839897; Tue, 27 Jan 2015 18:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.28.98 with HTTP; Tue, 27 Jan 2015 18:23:39 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <20150128022203.18746.6102.idtracker@ietfa.amsl.com> References: <20150128022203.18746.6102.idtracker@ietfa.amsl.com> From: Tim Bray Date: Tue, 27 Jan 2015 18:23:39 -0800 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a8ff0711507050dad10aa Archived-At: Cc: Pete Resnick , Matt Miller , "json@ietf.org" , "draft-ietf-json-i-json.all@tools.ietf.org" , Barry Leiba , "json-chairs@tools.ietf.org" Subject: Re: [Json] New Version Notification - draft-ietf-json-i-json-06.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: Wed, 28 Jan 2015 02:24:04 -0000 --047d7b3a8ff0711507050dad10aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real HTML at http://www.tbray.org/tmp/draft-ietf-json-i-json-06.html On Tue, Jan 27, 2015 at 6:22 PM, wrote: > > A new version (-06) has been submitted for draft-ietf-json-i-json: > http://www.ietf.org/internet-drafts/draft-ietf-json-i-json-06.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-json-i-json/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-i-json-06 > > 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. > > IETF Secretariat. > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --047d7b3a8ff0711507050dad10aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rea= l HTML at=C2=A0http://www.tbray.org/tmp/draft-ietf-json-i-json-06.html

On Tue, Jan 2= 7, 2015 at 6:22 PM, <internet-drafts@ietf.org> wrote= :

A new version (-06) has been submitted for draft-ietf-json-i-json:
http://www.ietf.org/internet-drafts/draft-ietf-json-i-= json-06.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-i-json/
Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-i-json-0= 6

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.

IETF Secretariat.




--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--047d7b3a8ff0711507050dad10aa-- From nobody Wed Jan 28 10:20:12 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986911A8882; Wed, 28 Jan 2015 10:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqEYRHfX2HHU; Wed, 28 Jan 2015 10:14:59 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AD31A8880; Wed, 28 Jan 2015 10:14:59 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id i50so17816854qgf.5; Wed, 28 Jan 2015 10:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=9HLbTIrI7iS62akaHdulhZR8CkLcSN4Xs738HmgYUyw=; b=Zk+Ht1E5ODPiDD90+rb3wrnUDzDBudzzbI9dpkQrXzC4zEV6rnH1Y3NS7IUp3ZFqlO /bY7kqZeBWaof/3x7F41wYrji7VopF7aVrwyiwBIgfBXQX3MUXK/mvs//wix/1VI//ih LkDWfifO/MTD8ERgdubmCTUkyNevIQT68mEpn40QKQuz64sgRGk9z27+Pp7oCLNx8fIJ cI2LjHC4CHvDl/3nWdoNNUc0YswMJKpvA7xt+3Nt48mOWehFysE0po3djbWVgWOd+iV4 mXb/gc53WTf6kBJEm/PllqoYfNVY1hXNBGStMbyXIRA0zQJpdZ2FGwB3o+elg+hPqh8G wgCA== MIME-Version: 1.0 X-Received: by 10.224.23.6 with SMTP id p6mr16034851qab.55.1422468898210; Wed, 28 Jan 2015 10:14:58 -0800 (PST) Sender: hallam@gmail.com Received: by 10.140.92.135 with HTTP; Wed, 28 Jan 2015 10:14:58 -0800 (PST) Date: Wed, 28 Jan 2015 13:14:58 -0500 X-Google-Sender-Auth: WANXu9W7l2p3nQ-iU42BPHhz_4g Message-ID: From: Phillip Hallam-Baker To: JSON WG , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2b31c61cacc050dba596f Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 10:20:10 -0800 Subject: [Json] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 18:15:01 -0000 --001a11c2b31c61cacc050dba596f Content-Type: text/plain; charset=UTF-8 All, I would like to propose a spec similar to the JSON log file spec but with the purpose of being a container for JSON signatures. The immediate application for this might be for ACME or other JSON/Rest Web services. The elevator pitch for the idea is that a JSON Container would be a JSON Metadata blob with the content being described appended to the end in a way that makes the separation between content and metadata simple and unambiguous. [Separator] Advantages: * Can read the metadata for a file etc with a plain ASCII editor or command line tools like cat, more, etc. * Avoids the need to BASE64 armor the content. So if the content is JSON or other ASCII/Unicode text it remains readable in an ASCII/Unicode editor. * Can add signatures, digests and other metadata items to content in a simple regular fashion. * Content and metadata can be transported as a simple regular blob that is fully abstracted from and independent of the transport and without the need for canonicalization, XPath or other complications. Right now, the IETF spec for describing content metadata is based on RFC822. And by 'based on', I mean that it is a find the needle in the RFC haystack approach. RFC822 style content headers as currently used have several disadvantages: * It is a flat structure, headers can have attributes but trying to add more structure is painful. * It is a historical artifact and content metadata headers are mixed in with protocol metadata headers without rhyme or reason. * It is not JSON and JSON is the spec we are now converging on for this type of work. It has all the expressive capabilities of XML and ASM.1 without the insanities and stupid. It is as easy to read and write as RFC822 but without the limitations. The spec itself would be simple, its basically draft-ietf-json-text-sequence applied to a sequence of one json object and one content blob. JSON sequence specifies that "A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A)" This is not ideal for JSON Container. We would prefer that the character which is illegal in a JSON document be the one that is the separator between the header and content. All indexes used in the metadata header are calculated from the Record Separator byte, the first byte following being byte 0 and so on. Applying this in a Web Service is very simple, our messages now have the form: POST / HTTP/1.1 Host: example.com Content-Type: application/json-container Content-Length: 666 { "Signature" : "wefwkjefkljwehfjklwhejkflh" } <0x1E>{ "Service-Type" : "acme.ws", "Transaction-ID" : "2h23roih23oih23orh", "Register" : { .... ... } } Where <0x1E> is the record separator character. The scope of the signature is the content, the whole content, AND NOTHING BUT THE CONTENT. Signing headers is a mugs game. Put all the information that matters into one blob and sign the blob. Do not present developers with an IKEA self-assembly job. So to prevent protocol substitution attacks, the service identifier and the method name wrap the method parameters. In a response, the service identifier, response code and transaction ID wrap the response data for the same reason. Applying the scheme to stored data in a file system is a little different. First we have to develop a file extension convention: file.jpg becomes file.jpg.jsonc Many jsonc aware applications will have to share data with applications that are not aware. So we need the option of storing metadata in a separate file when that is convenient: The metadata for file.jpg is stored in file.jsonm In some circumstances we might want to keep the metadata for all the files in a directory or tree in one file, a metadata container. This could be jsonmc.jsonmc appearing in either the directory a file is in or one of the directories above it. A metadata container would be a JSON container and begin with the usual metadata header for that file followed by a JSON sequence of entries per file. If this contains a signature, the file entries can just be digests. Notice how we have just developed a format that allows us to sign a complete code distribution including content data very easily. This is obviously out of scope for ACME but the fact that an approach transfers so neatly to a completely different problem suggests that it is the right track. --001a11c2b31c61cacc050dba596f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

I would like to propose a sp= ec similar to the JSON log file spec but with the purpose of being a contai= ner for JSON signatures. The immediate application for this might be for AC= ME or other JSON/Rest Web services.

The elevator p= itch for the idea is that a JSON Container would be a JSON Metadata blob wi= th the content being described appended to the end in a way that makes the = separation between content and metadata simple and unambiguous.
<= br>
<JSON-BLOB> [Separator] <content-blob>
=
Advantages:

* Can read the metadata= for a file etc with a plain ASCII editor or command line tools like cat, m= ore, etc.

* Avoids the need to BASE64 armor the co= ntent. So if the content is JSON or other ASCII/Unicode text it remains rea= dable in an ASCII/Unicode editor.

* Can add signat= ures, digests and other metadata items to content in a simple regular fashi= on.

* Content and metadata can be transported as a= simple regular blob that is fully abstracted from and independent of the t= ransport and without the need for canonicalization, XPath or other complica= tions.


Right now, the IETF spec for= describing content metadata is based on RFC822. And by 'based on',= I mean that it is a find the needle in the RFC haystack approach. RFC822 s= tyle content headers as currently used have several disadvantages:

* It is a flat structure, headers can have attributes but = trying to add more structure is painful.

* It is a= historical artifact and content metadata headers are mixed in with protoco= l metadata headers without rhyme or reason.

* It i= s not JSON and JSON is the spec we are now converging on for this type of w= ork. It has all the expressive capabilities of XML and ASM.1 without the in= sanities and stupid. It is as easy to read and write as RFC822 but without = the limitations.


The spec itself wo= uld be simple, its basically=C2=A0draft-ietf-json-text-sequence applied to = a sequence of one json object and one content blob.

JSON sequence specifies that "A JSON text sequence consists of any n= umber of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record= Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A)= "

This is not ideal for JSON Container. We wo= uld prefer that the character which is illegal in a JSON document be the on= e that is the separator between the header and content.

All indexes used in the metadata header are calculated from the Recor= d Separator byte, the first byte following being byte 0 and so on.


Applying this in a Web Service is very simp= le, our messages now have the form:

POST / HTTP/1.= 1
= Content-Type: application/json-container
Content-Length: 666

{ "Signature" : "wefwkjefkljwehfjklwhej= kflh" }

<0x1E>{ "Service-Type"= ; : "acme.ws",
=C2=A0 = =C2=A0"Transaction-ID" : "2h23roih23oih23orh",
=C2=A0 =C2=A0"Register" : { ....<web service parameters here= > ... } }

Where <0x1E> is the record sepa= rator character.

The scope of the signature is the= content, the whole content, AND NOTHING BUT THE CONTENT. Signing headers i= s a mugs game. Put all the information that matters into one blob and sign = the blob. Do not present developers with an IKEA self-assembly job.

So to prevent protocol substitution attacks, the serv= ice identifier and the method name wrap the method parameters. In a respons= e, the service identifier, response code and transaction ID wrap the respon= se data for the same reason.


Applyi= ng the scheme to stored data in a file system is a little different. First = we have to develop a file extension convention:

fi= le.jpg =C2=A0becomes file.jpg.jsonc

Many jsonc awa= re applications will have to share data with applications that are not awar= e. So we need the option of storing metadata in a separate file when that i= s convenient:

The metadata for file.jpg is stored = in file.jsonm

In some circumstances we might w= ant to keep the metadata for all the files in a directory or tree in one fi= le, a metadata container. This could be jsonmc.jsonmc appearing in either t= he directory a file is in or one of the directories above it.
A metadata container would be a JSON container and begin with t= he usual metadata header for that file followed by a JSON sequence of entri= es per file. If this contains a signature, the file entries can just be dig= ests.


Notice how we have just devel= oped a format that allows us to sign a complete code distribution including= content data very easily. This is obviously out of scope for ACME but the = fact that an approach transfers so neatly to a completely different problem= suggests that it is the right track.


--001a11c2b31c61cacc050dba596f-- From nobody Wed Jan 28 14:31:17 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C251A1A4F for ; Wed, 28 Jan 2015 14:31:14 -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 NJjS1RYEOfGx for ; Wed, 28 Jan 2015 14:31:12 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D731E1A1A4E for ; Wed, 28 Jan 2015 14:31:11 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 66A1322E1F4; Wed, 28 Jan 2015 17:31:06 -0500 (EST) Message-ID: <54C9632A.2040204@seantek.com> Date: Wed, 28 Jan 2015 14:31:06 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nico Williams References: <54C28E3F.4040901@alum.mit.edu> <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> In-Reply-To: <20150128173229.GC3110@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rfc-interest@rfc-editor.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 22:31:14 -0000 On 1/28/2015 9:32 AM, Nico Williams wrote: > On Tue, Jan 27, 2015 at 09:16:37PM -0800, Sean Leonard wrote: >> Overall I still stand by my proposition that the RFC is the module >> for ABNF purposes. Honestly it just makes things a lot simpler. To >> the extent that you need to split things inside the RFC, you can >> refer to specific sections. Specific comments below. > Well, draft-ietf-json-text-sequence-13 will break this proposition. Hello--I took a look at draft-ietf-json-text-sequence-13. There are two typos: Abstract: ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A). ^^^^^^ should be 0x0A. Section 2.2 Note that on some systems it's possible to input RS by typing 'ctrl-^'; on some system or applications the correct sequence may be 'ctrl-v crtl-^'. This is helpful when constructing a sequence ^^^^^^ should be ctrl-^. An editorial point: why define LF in this I-D when it's already defined=20 in RFC 5234 Appendix B? Just sayin'. > It's on the RFC-Editor queue. We could "fix" the "problem" in AUTH48, > but I've no intention to. Well you might want to look at the problems above... > I doubt it's the first RFC that will break your assumption. It's not an RFC yet. :-) First of all, I don't see a "problem" because there are no "modules" in=20 draft-ietf-json-text-sequence, or any other Internet-Draft. It's all a=20 bunch of plain text. I am not trying to be flippant; it's simply the way = it is. I-Ds are just large reams of plain text punctuated with FF codes. = That is why extracting data out of RFCs is convoluted and fraught with=20 error. I am not stating an assumption so much as I am stating a workable=20 proposition that makes sense for authoring future RFCs in a structured=20 format, i.e., a format where ABNF is clearly distinguished from=20 specification text or other things. I too dealt with this exact problem in draft-josefsson-pkix-textual-10=20 (also in the RFC-Editor queue, btw). In that soon-to-be-RFC, I renamed=20 the rules to: textualmsg ; what most extant parsers and generators will=20 work with stricttextualmsg ; what compliant generators SHOULD emit laxtextualmsg ; the most relaxed input that parsers MAY accept Thus, consider renaming the rules to distinguish between inputs and=20 outputs, such as {JSON-sequence-in} and {JSON-sequence-out}. It is=20 clearer and more accurate. I note that the "meat" parts are named=20 differently: {possible-JSON} vs. {JSON-text}, presumably to indicate the = difference in strictness between generators and parsers. As a broader useful point (not directed specifically to=20 draft-ietf-json-text-sequence-13), I think it would be nice if future=20 RFC ABNF can assume that the symbols in RFC 20 for %x00-20 / %x7F are=20 rules that can be used as-is. Hence NUL =3D %x00, SUB =3D %x1A, DEL =3D %= x7F, etc. > Not that it matters. Suppose all RFCs with ABNF only had a *single* > ABNF module, so that each module could be said to be named rfc1234.abnf= =2E > Now what? You'd still be missing the machine-readable imports. Uh I already laid this out...I no longer ascribe to the premise of "ABNF = modules". It's just a bunch of ABNF text. You know, other symbolic systems such as ASN.1 have modules...and ASN.1=20 is seen as way too complicated. I doubt that anyone is going to=20 "compile" the ABNF in draft-ietf-json-text-sequence-13 anyway--they are=20 just going to hunt for RS bytes, which is the whole point. > We could say that every module exports every rule by default, so we > could get away with not having exports. But imports are absolutely > necessary in order to validate ABNF modules that import rules from > others. Unless you don't have ABNF modules... > We already have a mess on our hands. ABNF needs a module system. An > ad-hoc module system won't do. No modules =3D no messes. I would say that all the crazy importing and=20 exporting in ASN.1 modules (an in particular, the fact that the=20 definitions have changed over time, witness PKCS #7 1.0 -> PKCS #7 1.5=20 -> CMS '99 -> CMS '02 -> CMS '04 -> CMS '09) is much messier.=20 Significant tool support is required, which is one significant reason=20 why people hate on ASN.1 and are trying to do things with JSON instead. Sean From nobody Wed Jan 28 14:43:56 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41C41A1AD3; Wed, 28 Jan 2015 14:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 6nVJaxwQW4og; Wed, 28 Jan 2015 14:43:50 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B7CA71A1AB9; Wed, 28 Jan 2015 14:43:50 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 7F2BF2005E609; Wed, 28 Jan 2015 14:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iHi19S9EBgDxe8 fxfILPQABaB9M=; b=gyvPrQamHqg9DSW6YvzZQ+ZID3VEiUWDhBy0MDF0ShJhng 00HdW6JoDE+mEf7zc1IREkDGsAac/fM9EkJ8GlSZSh9wS+2niOGCqKRhLrrLDfKD wC+J/wHF6nxaHHM5uslM+Y/U520OmrHdC18b1/tRIWTIm9rP8uf6wUHEYPaUg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 21F3E2005E607; Wed, 28 Jan 2015 14:43:50 -0800 (PST) Date: Wed, 28 Jan 2015 16:43:49 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20150128224346.GF3110@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 22:43:52 -0000 On Wed, Jan 28, 2015 at 01:14:58PM -0500, Phillip Hallam-Baker wrote: > [Separator] I'll bite. Why not: > Advantages: > > * Can read the metadata for a file etc with a plain ASCII editor or command > line tools like cat, more, etc. > > * Avoids the need to BASE64 armor the content. So if the content is JSON or > other ASCII/Unicode text it remains readable in an ASCII/Unicode editor. Why even have to base64-encode the signature? > * Can add signatures, digests and other metadata items to content in a > simple regular fashion. Ah. Hmm, right! It'd have ot be: [] or [] or as you suggest, put the [base64-encoded] signatures in the metadata. > Right now, the IETF spec for describing content metadata is based on > RFC822. And by 'based on', I mean that it is a find the needle in the RFC > haystack approach. RFC822 style content headers as currently used have > several disadvantages: > > * It is a flat structure, headers can have attributes but trying to add > more structure is painful. Flat structure has its advantages. A while back I posted a list of kinds of encodings, asking if there was any I'd missed. I did miss one important one myself: Lustre's RPC. Lustre's RPC doesn't support seqeuences-within-sequences-within- sequences like all the others do. It's more like a single top-level sequence of fixed- and variable-length things, where the fixed-length ones contain C-like structs (with all-fixed-length fields), and the variable-length ones containing only things like filenames. (Bulk data is sent separately, via RDMA-like protocols.) The main advantage to this is that all the critical length checks go in one place in the code. Whereas a JSON blob is not flat. It could be arbitrarily deep. > * It is a historical artifact and content metadata headers are mixed in > with protocol metadata headers without rhyme or reason. > > * It is not JSON and JSON is the spec we are now converging on for this > type of work. It has all the expressive capabilities of XML and ASM.1 > without the insanities and stupid. It is as easy to read and write as > RFC822 but without the limitations. Meh. It's just one of many suitable encodings. Pick one, any one. > The spec itself would be simple, its > basically draft-ietf-json-text-sequence applied to a sequence of one json > object and one content blob. Pretty much, yes (but it's not the same: the blob would not be a JSON blob). > JSON sequence specifies that "A JSON text sequence consists of any number > of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record > Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A)" > > This is not ideal for JSON Container. We would prefer that the character > which is illegal in a JSON document be the one that is the separator > between the header and content. Just make it: RS JSON-blob LF FS content (That would be as close as this could get to being a JSON text sequence while also being sufficiently different.) > Applying this in a Web Service is very simple, our messages now have the > form: > > POST / HTTP/1.1 > Host: example.com > Content-Type: application/json-container > Content-Length: 666 > > { "Signature" : "wefwkjefkljwehfjklwhejkflh" } > > <0x1E>{ "Service-Type" : "acme.ws", > "Transaction-ID" : "2h23roih23oih23orh", > "Register" : { .... ... } } OK, but why not put all of this into the headers anyways? > Notice how we have just developed a format that allows us to sign a > complete code distribution including content data very easily. This is > obviously out of scope for ACME but the fact that an approach transfers so > neatly to a completely different problem suggests that it is the right > track. Wasn't JOSE about this sort of thing? Nico -- From nobody Wed Jan 28 15:02:36 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252BE1A1BE5 for ; Wed, 28 Jan 2015 15:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 pS7oezMt1xKj for ; Wed, 28 Jan 2015 15:02:33 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51C1A1BEC for ; Wed, 28 Jan 2015 15:02:33 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id ABC772005D007; Wed, 28 Jan 2015 15:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wI6ryoLSUiCqYY fmrAMItpB3+hw=; b=ZrZ7XdhsaUdqQztrwmBIluNYYEaDupEBhwEO3JEsh7e0Lx 9fYYDAR/V+HskV0IS83wUqNmXZuiLaK6aPMae1GQeSrrB9hchQ3cbUyhkwM4umt1 UiVJqpZsvr9cURsBwY1+tUZU8JqjjyQlu7R/ul5LNEeTFZhsMjzPZIRuf+pDA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 4195B2005D001; Wed, 28 Jan 2015 15:02:32 -0800 (PST) Date: Wed, 28 Jan 2015 17:02:31 -0600 From: Nico Williams To: Sean Leonard Message-ID: <20150128230227.GG3110@localhost> References: <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C9632A.2040204@seantek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: rfc-interest@rfc-editor.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 23:02:35 -0000 On Wed, Jan 28, 2015 at 02:31:06PM -0800, Sean Leonard wrote: > On 1/28/2015 9:32 AM, Nico Williams wrote: > >On Tue, Jan 27, 2015 at 09:16:37PM -0800, Sean Leonard wrote: > >>Overall I still stand by my proposition that the RFC is the module > >>for ABNF purposes. Honestly it just makes things a lot simpler. To > >>the extent that you need to split things inside the RFC, you can > >>refer to specific sections. Specific comments below. > >Well, draft-ietf-json-text-sequence-13 will break this proposition. > > Hello--I took a look at draft-ietf-json-text-sequence-13. > > There are two typos: Thanks. Those have already been noted and will be fixed before publication. > An editorial point: why define LF in this I-D when it's already > defined in RFC 5234 Appendix B? Just sayin'. Because RS isn't, and both RS and LF come from STD 80 (RFC 20). > >It's on the RFC-Editor queue. We could "fix" the "problem" in AUTH48, > >but I've no intention to. > > Well you might want to look at the problems above... Yes, but I'm asking about a more specific problem. > >I doubt it's the first RFC that will break your assumption. > It's not an RFC yet. :-) But this issue (two ABNF rules with the same name) was raised earlier, and no one thought it was a problem. Now there's a question about ABNF modules: must ABNF-using RFCs have a single ABNF "module" consisting of all ABNF rules extracted from their figures?? I don't think "yes" is really the right answer, but it would be convenient if no other RFC deviates from that. > First of all, I don't see a "problem" because there are no "modules" > in draft-ietf-json-text-sequence, or any other Internet-Draft. It's There are no ABNF modules in *any* RFCs. Because there are no ABNF modules at all. > all a bunch of plain text. I am not trying to be flippant; it's No, there's figures. > simply the way it is. I-Ds are just large reams of plain text > punctuated with FF codes. That is why extracting data out of RFCs is > convoluted and fraught with error. This is an I-D on the RFC-Editor queue. It will soon be an RFC. > I am not stating an assumption so much as I am stating a workable > proposition that makes sense for authoring future RFCs in a > structured format, i.e., a format where ABNF is clearly > distinguished from specification text or other things. > > I too dealt with this exact problem in > draft-josefsson-pkix-textual-10 (also in the RFC-Editor queue, btw). > In that soon-to-be-RFC, I renamed the rules to: > textualmsg ; what most extant parsers and generators > will work with > stricttextualmsg ; what compliant generators SHOULD emit > laxtextualmsg ; the most relaxed input that parsers MAY accept If ABNF has no modules and we don't insist on an 'RFCs contain at most one ABNF "module"' rule, then I don't need to consider this proposal at all. I'd rather we defined ABNF modules. A rule that RFCs must have at most one ABNF module does not get us past the need to know what rules get imported from what other modules. And it's not elegant. > Thus, consider renaming the rules to distinguish between inputs and > outputs, such as {JSON-sequence-in} and {JSON-sequence-out}. It is > clearer and more accurate. I note that the "meat" parts are named > differently: {possible-JSON} vs. {JSON-text}, presumably to indicate > the difference in strictness between generators and parsers. I'm inclined to continue rejecting this proposal. > As a broader useful point (not directed specifically to > draft-ietf-json-text-sequence-13), I think it would be nice if > future RFC ABNF can assume that the symbols in RFC 20 for %x00-20 / > %x7F are rules that can be used as-is. Hence NUL = %x00, SUB = %x1A, > DEL = %x7F, etc. I agree. These should be added to RFC5234 (i.e., we should publish an update RFC listing them). > >Not that it matters. Suppose all RFCs with ABNF only had a *single* > >ABNF module, so that each module could be said to be named rfc1234.abnf. > >Now what? You'd still be missing the machine-readable imports. > > Uh I already laid this out...I no longer ascribe to the premise of > "ABNF modules". It's just a bunch of ABNF text. But I'd like to have first-class ABNF modules. "Just a bunch of [ABNF] text" is not enough: because we can't validate it. > You know, other symbolic systems such as ASN.1 have modules...and > ASN.1 is seen as way too complicated. I doubt that anyone is going > to "compile" the ABNF in draft-ietf-json-text-sequence-13 > anyway--they are just going to hunt for RS bytes, which is the whole > point. We like to machine-validate ABNF modules. How should we do this as to imported rules? > >We already have a mess on our hands. ABNF needs a module system. An > >ad-hoc module system won't do. > > No modules = no messes. I would say that all the crazy importing and > [...] No modules -> No need to rename the conflicting rules in draft-ietf-json-text-sequence. Thanks, Nico -- From nobody Wed Jan 28 15:12:29 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315D21A1DBE; Wed, 28 Jan 2015 15:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkeGYY-PUa1q; Wed, 28 Jan 2015 15:12:13 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EF8F1A1C05; Wed, 28 Jan 2015 15:11:47 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id e89so20983405qgf.2; Wed, 28 Jan 2015 15:11:46 -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=IUL+IEcBquHXAvrM0Xi/raXVR+EqesKAloNSVJ2J+jQ=; b=yKLAoAF8ckvK0yaWlYkLT9eXz7R+TxspOwkQV3Ee2LqqEbEafgROoTWkfuYZoz0t1M cwyR4X4/5k8LpNZmphGYhOnZnQ4VgTzrFFk758zQgAEmEl5jGXuOW/ESDfci6D90JRZM bRvcSJy7BSB9NbgCdnAC1feeDZWVXm7Dxwonv5WXLxiP6EAbyrnWEZH3f8T67ILZwQS6 h1AEU2ubyOsnW4ZAzLemnvx0+F81BXYv5n7WPnm6/oFvpigWSQunHcAmRIHb+6Oj6OtW lkvIeyXDmeu0nmZXzDmz6+Zq6T9jvexSJa+muEuce5ndZ6rmUgWs6y86Rx3PmuAY9PIj FOdw== MIME-Version: 1.0 X-Received: by 10.140.34.67 with SMTP id k61mr185420qgk.95.1422486706287; Wed, 28 Jan 2015 15:11:46 -0800 (PST) Sender: hallam@gmail.com Received: by 10.140.92.135 with HTTP; Wed, 28 Jan 2015 15:11:46 -0800 (PST) In-Reply-To: <20150128224346.GF3110@localhost> References: <20150128224346.GF3110@localhost> Date: Wed, 28 Jan 2015 18:11:46 -0500 X-Google-Sender-Auth: 1eqYfxIYgYSMv1u7dRuGpKJoU4s Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c0dd5cd394f4050dbe7ea1 Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 23:12:15 -0000 --001a11c0dd5cd394f4050dbe7ea1 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 28, 2015 at 5:43 PM, Nico Williams wrote: > On Wed, Jan 28, 2015 at 01:14:58PM -0500, Phillip Hallam-Baker wrote: > > [Separator] > > I'll bite. > > Why not: > > > > > Advantages: > > > > * Can read the metadata for a file etc with a plain ASCII editor or > command > > line tools like cat, more, etc. > > > > * Avoids the need to BASE64 armor the content. So if the content is JSON > or > > other ASCII/Unicode text it remains readable in an ASCII/Unicode editor. > > Why even have to base64-encode the signature? > > > * Can add signatures, digests and other metadata items to content in a > > simple regular fashion. > > Ah. Hmm, right! It'd have ot be: > > [] > > or > > [] > > or as you suggest, put the [base64-encoded] signatures in the metadata. Yep, that is the reason for doing it the way proposed. It is really useful and necessary to have multiple signatures on the same content. This allows for multiple algorithms, multiple signers, etc. Or just a signature and a digest. > > * It is a historical artifact and content metadata headers are mixed in > > with protocol metadata headers without rhyme or reason. > > > > * It is not JSON and JSON is the spec we are now converging on for this > > type of work. It has all the expressive capabilities of XML and ASM.1 > > without the insanities and stupid. It is as easy to read and write as > > RFC822 but without the limitations. > > Meh. It's just one of many suitable encodings. Pick one, any one. They seem to have picked JSON. Or S-expressions with curly braces if you like to look at them that way... > > JSON sequence specifies that "A JSON text sequence consists of any number > > of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record > > Separator (0x1E), and each ending with an ASCII Line Feed character > (0x1A)" > > > > This is not ideal for JSON Container. We would prefer that the character > > which is illegal in a JSON document be the one that is the separator > > between the header and content. > > Just make it: > > RS JSON-blob LF FS content > > (That would be as close as this could get to being a JSON text > sequence while also being sufficiently different.) Works for me. If we are using RS, might as well use FS. > > > Applying this in a Web Service is very simple, our messages now have the > > form: > > > > POST / HTTP/1.1 > > Host: example.com > > Content-Type: application/json-container > > Content-Length: 666 > > > > { "Signature" : "wefwkjefkljwehfjklwhejkflh" } > > > > <0x1E>{ "Service-Type" : "acme.ws", > > "Transaction-ID" : "2h23roih23oih23orh", > > "Register" : { .... ... } } > > OK, but why not put all of this into the headers anyways? Well that is what I suggested in my Content-Signature work and that is exactly how my code works today. But folk proposed introducing the signature in the HTTP content segment and that forced me to think about which approach is better. I think I can make a good architectural argument for the JSON Container approach and besides which it is really useful at the file system level. Separating out protocol data from content-metadata is long overdue. > > > Notice how we have just developed a format that allows us to sign a > > complete code distribution including content data very easily. This is > > obviously out of scope for ACME but the fact that an approach transfers > so > > neatly to a completely different problem suggests that it is the right > > track. > > Wasn't JOSE about this sort of thing? > Sort of. That might be where we eventually do the work. But the requirements would be ACME in the first instance and the constraints from JSON. I would see JOSE as being something we just plop in and should work (or else they have some splainin' to do. --001a11c0dd5cd394f4050dbe7ea1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 28, 2015 at 5:43 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Jan 28,= 2015 at 01:14:58PM -0500, Phillip Hallam-Baker wrote:
> <JSON-BLOB> [Separator] <content-blob>

I'll bite.

Why not:

<metadata JSON> <separator> <signature> <content>
> Advantages:
>
> * Can read the metadata for a file etc with a plain ASCII editor or co= mmand
> line tools like cat, more, etc.
>
> * Avoids the need to BASE64 armor the content. So if the content is JS= ON or
> other ASCII/Unicode text it remains readable in an ASCII/Unicode edito= r.

Why even have to base64-encode the signature?

> * Can add signatures, digests and other metadata items to content in a=
> simple regular fashion.

Ah.=C2=A0 Hmm, right!=C2=A0 It'd have ot be:
=C2=A0
<metadata JSON> <separator> <signature> <content> [= <extra signatures>]

or

<metadata JSON> <separator> <content> [<signatures>= ]

or as you suggest, put the [base64-encoded] signatures in the metadata.

Yep, that is the reason for doing it the way p= roposed. It is really useful and necessary to have multiple signatures on t= he same content. This allows for multiple algorithms, multiple signers, etc= . Or just a signature and a digest.


=C2=A0
> * It is a historical artifact and content metadata headers are mixed i= n
> with protocol metadata headers without rhyme or reason.
>
> * It is not JSON and JSON is the spec we are now converging on for thi= s
> type of work. It has all the expressive capabilities of XML and ASM.1<= br> > without the insanities and stupid. It is as easy to read and write as<= br> > RFC822 but without the limitations.

Meh.=C2=A0 It's just one of many suitable encodings.=C2=A0 Pick = one, any one.

They seem to have picked JSON= . Or S-expressions with curly braces if you like to look at them that way..= .

=C2=A0
> JSON sequence specifies that "A JSON text sequence consists of an= y number
> of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record<= br> > Separator (0x1E), and each ending with an ASCII Line Feed character (0= x1A)"
>
> This is not ideal for JSON Container. We would prefer that the charact= er
> which is illegal in a JSON document be the one that is the separator > between the header and content.

Just make it:

RS JSON-blob LF FS content

(That would be as close as this could get to being a JSON text
sequence while also being sufficiently different.)

Works for me. If we are using RS, might as well use FS.
<= br>
=C2=A0
<= br> > Applying this in a Web Service is very simple, our messages now have t= he
> form:
>
> POST / HTTP/1.1
> Host: example.com=
> Content-Type: application/json-container
> Content-Length: 666
>
> { "Signature" : "wefwkjefkljwehfjklwhejkflh" }
>
> <0x1E>{ "Service-Type" : "acme.ws",
>=C2=A0 =C2=A0 "Transaction-ID" : "2h23roih23oih23orh&quo= t;,
>=C2=A0 =C2=A0 "Register" : { ....<web service parameters h= ere> ... } }

OK, but why not put all of this into the headers anyways?

Well that is what I suggested in my Content-Signature= work and that is exactly how my code works today. But folk proposed introd= ucing the signature in the HTTP content segment and that forced me to think= about which approach is better.

I think I can mak= e a good architectural argument for the JSON Container approach and besides= which it is really useful at the file system level. Separating out protoco= l data from content-metadata is long overdue.

=C2= =A0

> Notice how we have just developed a format that allows us to sign a > complete code distribution including content data very easily. This is=
> obviously out of scope for ACME but the fact that an approach transfer= s so
> neatly to a completely different problem suggests that it is the right=
> track.

Wasn't JOSE about this sort of thing?

<= /div>
Sort of. That might be where we eventually do the work. But the r= equirements would be ACME in the first instance and the constraints from JS= ON. I would see JOSE as being something we just plop in and should work (or= else they have some splainin' to do.=C2=A0
--001a11c0dd5cd394f4050dbe7ea1-- From nobody Wed Jan 28 15:20:23 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0318B1A6F11; Wed, 28 Jan 2015 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 rQXkDiocyaZb; Wed, 28 Jan 2015 15:20:07 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB0B1A6EE8; Wed, 28 Jan 2015 15:20:07 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 0CF786B007C; Wed, 28 Jan 2015 15:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=K2sOGVTeuiv0z9 UvBEQGDyzkRFo=; b=nF7LfR+dMIsAzQ2eORlBR/ZUovByAvxQ1tgm62RSqi8oHv MPPRx1kdF11ln4atUlbOBn5i+aJgD4rBNeDkpXPRH9IRMOjKpF0HkK/seJ7k04J2 8/CXKWYHQZD9sT5IY3589Ghdxi22+J01ViBrwfBj6IbaGjgkQGW3KNqUEiwrI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id A578C6B0070; Wed, 28 Jan 2015 15:20:06 -0800 (PST) Date: Wed, 28 Jan 2015 17:20:06 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20150128232002.GK3110@localhost> References: <20150128224346.GF3110@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 23:20:08 -0000 On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > OK, but why not put all of this into the headers anyways? > > Well that is what I suggested in my Content-Signature work and that is > exactly how my code works today. But folk proposed introducing the > signature in the HTTP content segment and that forced me to think about > which approach is better. Your approach looks like a Transfer-Encoding to me. If that's what it looks like, and that's what it walks like, [and that's what we want,] then that's what it should be. > I think I can make a good architectural argument for the JSON Container > approach and besides which it is really useful at the file system level. You want the contents of the object to include the signature?? I mean, I've wanted filesystems to expose some internal metadata (e.g., a Merkle hash tree root hash for a file's content, with those parameters needed to reconstruct the same hash from just the contents, namely, the shape of the tree and the size of each non-tail block of contents). But making this part of the contents instead of the metadata strikes me as rather problematic. > Separating out protocol data from content-metadata is long overdue. Maybe, but I do want POSIX to continue not commingling contents and metadata. > > > Notice how we have just developed a format that allows us to sign a > > > complete code distribution including content data very easily. This is > > > obviously out of scope for ACME but the fact that an approach transfers > > so > > > neatly to a completely different problem suggests that it is the right > > > track. > > > > Wasn't JOSE about this sort of thing? > > Sort of. That might be where we eventually do the work. But the > requirements would be ACME in the first instance and the constraints from > JSON. I would see JOSE as being something we just plop in and should work > (or else they have some splainin' to do. I meant: why not use whatever JOSE delivered? Nico -- From nobody Wed Jan 28 15:25:40 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3371A6F0B for ; Wed, 28 Jan 2015 15:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, 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 WqS4PxKLkwtz for ; Wed, 28 Jan 2015 15:25:37 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id C12691A6EE8 for ; Wed, 28 Jan 2015 15:25:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,483,1418043600"; d="scan'208";a="66858232" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Jan 2015 09:59:50 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7695"; a="329841477" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 29 Jan 2015 10:25:35 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 29 Jan 2015 10:25:34 +1100 From: "Manger, James" To: Nico Williams , Sean Leonard Date: Thu, 29 Jan 2015 10:25:34 +1100 Thread-Topic: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode Thread-Index: AdA7Tp5cirhu5ueVThaqYpmccbAtXQAAJzBA Message-ID: <255B9BB34FB7D647A506DC292726F6E1284EB0326B@WSMSG3153V.srv.dir.telstra.com> References: <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> In-Reply-To: <20150128230227.GG3110@localhost> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rfc-interest@rfc-editor.org" , "draft-ietf-json-text-sequence@tools.ietf.org" , "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 23:25:38 -0000 >> Overall I still stand by my proposition that the RFC is the module=20 >> for ABNF purposes. Honestly it just makes things a lot simpler. > Well, draft-ietf-json-text-sequence-13 will break this proposition. > But this issue (two ABNF rules with the same name) was raised earlier, an= d no one thought it was a problem. The issued was raised because someone did think it was a problem. -- James Manger From nobody Wed Jan 28 15:29:37 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCD01A6FEF for ; Wed, 28 Jan 2015 15:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 KZyzWm3q9gn3 for ; Wed, 28 Jan 2015 15:29:35 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B6DDE1A6FD5 for ; Wed, 28 Jan 2015 15:29:33 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 952ED2AC078; Wed, 28 Jan 2015 15:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wAlA2Wilhru0im tufXKlWu1MZlc=; b=midtCDGHfROicmVv9w8ON9l9t7eRnsvBjKNr6ewEV0B6Lz H7L4TIIMHKVMGrUppbRmSX8897qfHEIo4m4UuZrID4byvcpudIarF2qwS/0Mz5qx dDPLRFOuBIUdYSJRBo79gYE6gUs2xppCK1mUaz+0CrzGx3IEAhtbUEm25oFhE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 2074C2AC073; Wed, 28 Jan 2015 15:29:33 -0800 (PST) Date: Wed, 28 Jan 2015 17:29:32 -0600 From: Nico Williams To: "Manger, James" Message-ID: <20150128232928.GL3110@localhost> References: <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <255B9BB34FB7D647A506DC292726F6E1284EB0326B@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1284EB0326B@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rfc-interest@rfc-editor.org" , "draft-ietf-json-text-sequence@tools.ietf.org" , Sean Leonard , "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Jan 2015 23:29:36 -0000 On Thu, Jan 29, 2015 at 10:25:34AM +1100, Manger, James wrote: > >> Overall I still stand by my proposition that the RFC is the module > >> for ABNF purposes. Honestly it just makes things a lot simpler. > > > Well, draft-ietf-json-text-sequence-13 will break this proposition. > > > But this issue (two ABNF rules with the same name) was raised earlier, and no one thought it was a problem. > > The issued was raised because someone did think it was a problem. I typed too quickly. I mean that no one thought the change had to be made. I still don't think so, not on account of a heretofore non-existent (and inelegant) rule that there be at most one ABNF "module" per-RFC. From nobody Wed Jan 28 16:50:35 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308F61A89F9; Wed, 28 Jan 2015 16:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_d40UuSEpgC; Wed, 28 Jan 2015 16:50:31 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EC21A89F5; Wed, 28 Jan 2015 16:50:31 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u10so22885105lbd.12; Wed, 28 Jan 2015 16:50:29 -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=8IHKtDulHZ3pr6Lvf+6Ks+u4DOxg7m6CKyG+b5t1qBY=; b=ZnJDbXOEOp38MdTVVBOiAqjGL/u/ok10ijuCX2Yl6tX5mzc5aI0CVwLJXfAB6my4It 9HGs6muJaZEG5i0Xy04w2ERgqy26RFB+c3c/rai7A9bM4GTzlbF8HTgwDCR/iz8HN0Im Xm0M9MuWdffm9obMVXM38wvm6F4TnPCdvGOtI6pUe4so2eIKNgEKwFC5MA+eQK+fbCmf S7Bblpq7LuH2cAb24CfX/2B84y0v/V+pwq5Uw93HCf4+jfGDX7DTmdy3zLS5txXepLVr Yj3/LrtaeQOffufkOTZOXCDTJKoiW7U+zQh0mGxKx1pZxKSiCgTSLYDPlOH+uPt3HAUH //XA== MIME-Version: 1.0 X-Received: by 10.152.6.101 with SMTP id z5mr11488611laz.19.1422492629635; Wed, 28 Jan 2015 16:50:29 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 16:50:29 -0800 (PST) In-Reply-To: <20150128232002.GK3110@localhost> References: <20150128224346.GF3110@localhost> <20150128232002.GK3110@localhost> Date: Wed, 28 Jan 2015 19:50:29 -0500 X-Google-Sender-Auth: 55pjeCe_2ljr5Et8gteW8IP7trQ Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e01494332e29b00050dbfdf8c Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 00:50:33 -0000 --089e01494332e29b00050dbfdf8c Content-Type: text/plain; charset=UTF-8 On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams wrote: > On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > > OK, but why not put all of this into the headers anyways? > > > > Well that is what I suggested in my Content-Signature work and that is > > exactly how my code works today. But folk proposed introducing the > > signature in the HTTP content segment and that forced me to think about > > which approach is better. > > Your approach looks like a Transfer-Encoding to me. If that's what it > looks like, and that's what it walks like, [and that's what we want,] > then that's what it should be. Umm, I designed the Chunked transfer encoding. A TE gives the length of blobs. This is not a TE. > > > I think I can make a good architectural argument for the JSON Container > > approach and besides which it is really useful at the file system level. > > You want the contents of the object to include the signature?? > No, I want the option of doing drag and drop on the file plus metadata blob in a fully interoperable fashion. So the contents are still the contents. But they are prefixed by the metadata. > I mean, I've wanted filesystems to expose some internal metadata (e.g., > a Merkle hash tree root hash for a file's content, with those parameters > needed to reconstruct the same hash from just the contents, namely, the > shape of the tree and the size of each non-tail block of contents). But > making this part of the contents instead of the metadata strikes me as > rather problematic. It isn't making it part of the contents. Metadata is still metadata. Trying to get the file system to support additional semantics is a losing proposition. And even if they are supported they won't be standard across all the platforms. > > > Separating out protocol data from content-metadata is long overdue. > > Maybe, but I do want POSIX to continue not commingling contents and > metadata. I want POSIX to curl up in the corner and die. Co-mingling the contents and metadata are an inevitable consequence of considering files to just be a stream of bits. inside the container is the only place that metadata can go. UNIX has had horrid kludges for putting metadata into the content since the start. Thats what magic numbers are. > Sort of. That might be where we eventually do the work. But the > > requirements would be ACME in the first instance and the constraints from > > JSON. I would see JOSE as being something we just plop in and should work > > (or else they have some splainin' to do. > > I meant: why not use whatever JOSE delivered? > Base64 encoding the content so as to be able to work out the boundaries. Blech. --089e01494332e29b00050dbfdf8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote:
> > OK, but why not put all of this into the headers anyways?
>
> Well that is what I suggested in my Content-Signature work and that is=
> exactly how my code works today. But folk proposed introducing the
> signature in the HTTP content segment and that forced me to think abou= t
> which approach is better.

Your approach looks like a Transfer-Encoding to me.=C2=A0 If that= 9;s what it
looks like, and that's what it walks like, [and that's what we want= ,]
then that's what it should be.

Umm, I d= esigned the Chunked transfer encoding. A TE gives the length of blobs. This= is not a TE.

=C2=A0

> I think I can make a good architectural argument for the JSON Containe= r
> approach and besides which it is really useful at the file system leve= l.

You want the contents of the object to include the signature??

No, I want the option of doing drag and drop= on the file plus metadata blob in a fully interoperable fashion. So the co= ntents are still the contents. But they are prefixed by the metadata.=C2=A0=


=C2=A0
I mean, I've wanted filesystems to expose some internal metadata (e.g.,=
a Merkle hash tree root hash for a file's content, with those parameter= s
needed to reconstruct the same hash from just the contents, namely, the
shape of the tree and the size of each non-tail block of contents).=C2=A0 B= ut
making this part of the contents instead of the metadata strikes me as
rather problematic.

It isn't making it = part of the contents. Metadata is still metadata.

= Trying to get the file system to support additional semantics is a losing p= roposition. And even if they are supported they won't be standard acros= s all the platforms.

=C2=A0

> Separating out protocol data from content-metadata is long overdue.
Maybe, but I do want POSIX to continue not commingling contents and<= br> metadata.

I want POSIX to curl up in the co= rner and die.

Co-mingling the contents and metadat= a are an inevitable consequence of considering files to just be a stream of= bits. inside the container is the only place that metadata can go.=C2=A0

UNIX has had horrid kludges for putting metadata in= to the content since the start. Thats what magic numbers are.
> Sort of. That m= ight be where we eventually do the work. But the
> requirements would be ACME in the first instance and the constraints f= rom
> JSON. I would see JOSE as being something we just plop in and should w= ork
> (or else they have some splainin' to do.

I meant: why not use whatever JOSE delivered?
<= br>
Base64 encoding the content so as to be able to work out the = boundaries. Blech.=C2=A0
--089e01494332e29b00050dbfdf8c-- From nobody Wed Jan 28 16:54:05 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716451A8A06; Wed, 28 Jan 2015 16:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 9_c_xy-1Q6Em; Wed, 28 Jan 2015 16:54:02 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BD3191A8A04; Wed, 28 Jan 2015 16:54:02 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 846D0350079; Wed, 28 Jan 2015 16:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TcVAyb1T4mG26q UTWA0hpD+NSbc=; b=u/y40u7/PwgVReVs2KhUdb7qwxzTh7euYqLynsSecNg0jy sq35e0DbRYCCsK9sP5WQo3mKE3f9Cr8FWNWgrBGue41EMHPUwPB2pJOB6iVEQbAc 2NevLjeHMIHvD6b9vkfY6fDEvZPGv3OGEDrZP7xec28ZXY4bBSUsYMTpUThWA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 31F4535005B; Wed, 28 Jan 2015 16:54:02 -0800 (PST) Date: Wed, 28 Jan 2015 18:54:01 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20150129005357.GM3110@localhost> References: <20150128224346.GF3110@localhost> <20150128232002.GK3110@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 00:54:03 -0000 On Wed, Jan 28, 2015 at 07:50:29PM -0500, Phillip Hallam-Baker wrote: > On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams > wrote: > > > On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > > > OK, but why not put all of this into the headers anyways? > > > > > > Well that is what I suggested in my Content-Signature work and that is > > > exactly how my code works today. But folk proposed introducing the > > > signature in the HTTP content segment and that forced me to think about > > > which approach is better. > > > > Your approach looks like a Transfer-Encoding to me. If that's what it > > looks like, and that's what it walks like, [and that's what we want,] > > then that's what it should be. > > > Umm, I designed the Chunked transfer encoding. A TE gives the length of > blobs. This is not a TE. So it's a new MIME type of signed data? OK. > > I meant: why not use whatever JOSE delivered? > > Base64 encoding the content so as to be able to work out the boundaries. > Blech. That's what I thought. Base64 avoidance for bulk sounds good to me. Nico -- From nobody Wed Jan 28 17:02:21 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7938B1A0032; Wed, 28 Jan 2015 17:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1tLyGgJsUgU; Wed, 28 Jan 2015 17:02:13 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC871A8A47; Wed, 28 Jan 2015 17:02:02 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so22862920lbd.2; Wed, 28 Jan 2015 17:02:01 -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=kOF2LvEcRH4mNh6pgbdE0vnW8+ciQT4XDu/xnwJMh6s=; b=S2F4fqMmyx4bJlMBtOOBcSiZpWjfQcPXVohgdhC67xrNJdgHX99eA9zRbj1LTZmKwe c+bEIXMF6k0Yfx/LwU+h7rxlPsI7xK/rQLBlx1gdWE8wbAXc8AnpsVhgkPn/zUXWxrX8 9mw/vQCO4XGuafvX29AnyNRYHjOnE+cE56h6Ex7NcRF4Xr09gsqNqwB0Q6tDPcKi6Hkj HotCSOPxC2NaLdhpdERTEnq4mb3SGUHe7dy/pir9addorYLOPHToZgrvmg55k00aSW+j uHtrlq89Fa6oGWXRktglerzSLyo3rJFSsaifuQEsPWEz/+pk+zWSnp6TZLM2QiRAv1aw dG9Q== MIME-Version: 1.0 X-Received: by 10.112.162.226 with SMTP id yd2mr11558683lbb.1.1422493321183; Wed, 28 Jan 2015 17:02:01 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 17:02:01 -0800 (PST) In-Reply-To: <20150129005357.GM3110@localhost> References: <20150128224346.GF3110@localhost> <20150128232002.GK3110@localhost> <20150129005357.GM3110@localhost> Date: Wed, 28 Jan 2015 20:02:01 -0500 X-Google-Sender-Auth: bZVPLqcK5PkTA2e2WfrL_BB-BlU Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e0112c86c1afde6050dc0098b Archived-At: Cc: "acme@ietf.org" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 01:02:14 -0000 --089e0112c86c1afde6050dc0098b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 28, 2015 at 7:54 PM, Nico Williams wrote: > On Wed, Jan 28, 2015 at 07:50:29PM -0500, Phillip Hallam-Baker wrote: > > On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams > > wrote: > > > > > On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: > > > > > OK, but why not put all of this into the headers anyways? > > > > > > > > Well that is what I suggested in my Content-Signature work and that > is > > > > exactly how my code works today. But folk proposed introducing the > > > > signature in the HTTP content segment and that forced me to think > about > > > > which approach is better. > > > > > > Your approach looks like a Transfer-Encoding to me. If that's what it > > > looks like, and that's what it walks like, [and that's what we want,] > > > then that's what it should be. > > > > > > Umm, I designed the Chunked transfer encoding. A TE gives the length of > > blobs. This is not a TE. > > So it's a new MIME type of signed data? > A new MIME type of JSON wrapped data similar to the rfc822 type. The content could be encrypted for example or just be the metadata. --089e0112c86c1afde6050dc0098b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 28, 2015 at 7:54 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Jan 28, 2015 at 07:50:29PM -0500, Phillip Hallam-Baker wrote:
> On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams <nico@cryptonector.com>
> wrote:
>
> > On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wr= ote:
> > > > OK, but why not put all of this into the headers anyway= s?
> > >
> > > Well that is what I suggested in my Content-Signature work a= nd that is
> > > exactly how my code works today. But folk proposed introduci= ng the
> > > signature in the HTTP content segment and that forced me to = think about
> > > which approach is better.
> >
> > Your approach looks like a Transfer-Encoding to me.=C2=A0 If that= 's what it
> > looks like, and that's what it walks like, [and that's wh= at we want,]
> > then that's what it should be.
>
>
> Umm, I designed the Chunked transfer encoding. A TE gives the length o= f
> blobs. This is not a TE.

So it's a new MIME type of signed data?
A =C2=A0new MIME type of JSON wrapped data similar to the rfc82= 2 type.

The content could be encrypted for example= or just be the metadata.

--089e0112c86c1afde6050dc0098b-- From nobody Wed Jan 28 18:51:22 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1471A8AE1; Wed, 28 Jan 2015 18:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 LYn17R88D8Sg; Wed, 28 Jan 2015 18:51:17 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id CA3FC1A8ADC; Wed, 28 Jan 2015 18:51:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,484,1418043600"; d="scan'208,217";a="238511957" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 29 Jan 2015 13:32:56 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7695"; a="229447894" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdni.tcif.telstra.com.au with ESMTP; 29 Jan 2015 13:51:15 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 29 Jan 2015 13:51:15 +1100 From: "Manger, James" To: Phillip Hallam-Baker , JSON WG , "acme@ietf.org" Date: Thu, 29 Jan 2015 13:51:13 +1100 Thread-Topic: [Acme] Signed JSON document / Json Content Metaheader / JSON Container Thread-Index: AdA7Jll5lOzfaDYxToiTs6qbsClkAAAOI9oA Message-ID: <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1284ED9AA38WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 02:51:21 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1284ED9AA38WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBzaWduZWQgSkFSIGZpbGUgbWVldHMgc29tZSBvZiB0aGVzZSByZXF1aXJlbWVudHMuDQpNZXRh ZGF0YSBhbmQgc2lnbmF0dXJlcyBhcmUgaW4gZXh0cmEgZmlsZXMgaW4gdGhlIFpJUCBhcmNoaXZl OiBNRVRBLUlORi9NQU5JRkVTVC5NRiwgTUVUQS1JTkYvTVlLRVkuU0YsIE1FVEEtSU5GL01ZS0VZ LlJTQS4NCkNvbnRlbnQgaXMgdGhlIG90aGVyIGZpbGVzIGluIHRoZSBhcmNoaXZlLg0KSXQgaXMg bm90IEpTT04gb2YgY291cnNlLCBhbmQgdGhlIHNpZ25hdHVyZSAmIGNlcnRzIGFyZSBwYWNrYWdl ZCBpbiBBU04uMSwgYnV0IGl0IGlzIGEgdXNlZnVsIGNvbXBhcmlzb24uIEl0IGF2b2lkcyBCQVNF NjQgb24gdGhlIGNvbnRlbnQ7IGNhbiBhZGRzIHNpZ25hdHVyZXMsIGRpZ2VzdHMsIGFuZCBvdGhl ciBtZXRhZGF0YTsgY2FuIHRyYW5zcG9ydCBjb250ZW50IGFuZCBtZXRhZGF0YSBhcyBhIHJlZ3Vs YXIgYmxvYiAoKi5qYXIgZmlsZSk7IGNhbiBzaWduIGNvbXBsZXRlIGNvZGUgZGlzdHJpYnV0aW9u cy4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBBY21lIFttYWlsdG86YWNtZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbGxpcCBIYWxsYW0tQmFrZXINClNlbnQ6IFRodXJz ZGF5LCAyOSBKYW51YXJ5IDIwMTUgNToxNSBBTQ0KVG86IEpTT04gV0c7IGFjbWVAaWV0Zi5vcmcN ClN1YmplY3Q6IFtBY21lXSBTaWduZWQgSlNPTiBkb2N1bWVudCAvIEpzb24gQ29udGVudCBNZXRh aGVhZGVyIC8gSlNPTiBDb250YWluZXINCg0KQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gcHJvcG9z ZSBhIHNwZWMgc2ltaWxhciB0byB0aGUgSlNPTiBsb2cgZmlsZSBzcGVjIGJ1dCB3aXRoIHRoZSBw dXJwb3NlIG9mIGJlaW5nIGEgY29udGFpbmVyIGZvciBKU09OIHNpZ25hdHVyZXMuIFRoZSBpbW1l ZGlhdGUgYXBwbGljYXRpb24gZm9yIHRoaXMgbWlnaHQgYmUgZm9yIEFDTUUgb3Igb3RoZXIgSlNP Ti9SZXN0IFdlYiBzZXJ2aWNlcy4NCg0KVGhlIGVsZXZhdG9yIHBpdGNoIGZvciB0aGUgaWRlYSBp cyB0aGF0IGEgSlNPTiBDb250YWluZXIgd291bGQgYmUgYSBKU09OIE1ldGFkYXRhIGJsb2Igd2l0 aCB0aGUgY29udGVudCBiZWluZyBkZXNjcmliZWQgYXBwZW5kZWQgdG8gdGhlIGVuZCBpbiBhIHdh eSB0aGF0IG1ha2VzIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gY29udGVudCBhbmQgbWV0YWRhdGEg c2ltcGxlIGFuZCB1bmFtYmlndW91cy4NCg0KPEpTT04tQkxPQj4gW1NlcGFyYXRvcl0gPGNvbnRl bnQtYmxvYj4NCg0KQWR2YW50YWdlczoNCg0KKiBDYW4gcmVhZCB0aGUgbWV0YWRhdGEgZm9yIGEg ZmlsZSBldGMgd2l0aCBhIHBsYWluIEFTQ0lJIGVkaXRvciBvciBjb21tYW5kIGxpbmUgdG9vbHMg bGlrZSBjYXQsIG1vcmUsIGV0Yy4NCg0KKiBBdm9pZHMgdGhlIG5lZWQgdG8gQkFTRTY0IGFybW9y IHRoZSBjb250ZW50LiBTbyBpZiB0aGUgY29udGVudCBpcyBKU09OIG9yIG90aGVyIEFTQ0lJL1Vu aWNvZGUgdGV4dCBpdCByZW1haW5zIHJlYWRhYmxlIGluIGFuIEFTQ0lJL1VuaWNvZGUgZWRpdG9y Lg0KDQoqIENhbiBhZGQgc2lnbmF0dXJlcywgZGlnZXN0cyBhbmQgb3RoZXIgbWV0YWRhdGEgaXRl bXMgdG8gY29udGVudCBpbiBhIHNpbXBsZSByZWd1bGFyIGZhc2hpb24uDQoNCiogQ29udGVudCBh bmQgbWV0YWRhdGEgY2FuIGJlIHRyYW5zcG9ydGVkIGFzIGEgc2ltcGxlIHJlZ3VsYXIgYmxvYiB0 aGF0IGlzIGZ1bGx5IGFic3RyYWN0ZWQgZnJvbSBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIHRyYW5z cG9ydCBhbmQgd2l0aG91dCB0aGUgbmVlZCBmb3IgY2Fub25pY2FsaXphdGlvbiwgWFBhdGggb3Ig b3RoZXIgY29tcGxpY2F0aW9ucy4NCg0KDQpSaWdodCBub3csIHRoZSBJRVRGIHNwZWMgZm9yIGRl c2NyaWJpbmcgY29udGVudCBtZXRhZGF0YSBpcyBiYXNlZCBvbiBSRkM4MjIuIEFuZCBieSAnYmFz ZWQgb24nLCBJIG1lYW4gdGhhdCBpdCBpcyBhIGZpbmQgdGhlIG5lZWRsZSBpbiB0aGUgUkZDIGhh eXN0YWNrIGFwcHJvYWNoLiBSRkM4MjIgc3R5bGUgY29udGVudCBoZWFkZXJzIGFzIGN1cnJlbnRs eSB1c2VkIGhhdmUgc2V2ZXJhbCBkaXNhZHZhbnRhZ2VzOg0KDQoqIEl0IGlzIGEgZmxhdCBzdHJ1 Y3R1cmUsIGhlYWRlcnMgY2FuIGhhdmUgYXR0cmlidXRlcyBidXQgdHJ5aW5nIHRvIGFkZCBtb3Jl IHN0cnVjdHVyZSBpcyBwYWluZnVsLg0KDQoqIEl0IGlzIGEgaGlzdG9yaWNhbCBhcnRpZmFjdCBh bmQgY29udGVudCBtZXRhZGF0YSBoZWFkZXJzIGFyZSBtaXhlZCBpbiB3aXRoIHByb3RvY29sIG1l dGFkYXRhIGhlYWRlcnMgd2l0aG91dCByaHltZSBvciByZWFzb24uDQoNCiogSXQgaXMgbm90IEpT T04gYW5kIEpTT04gaXMgdGhlIHNwZWMgd2UgYXJlIG5vdyBjb252ZXJnaW5nIG9uIGZvciB0aGlz IHR5cGUgb2Ygd29yay4gSXQgaGFzIGFsbCB0aGUgZXhwcmVzc2l2ZSBjYXBhYmlsaXRpZXMgb2Yg WE1MIGFuZCBBU00uMSB3aXRob3V0IHRoZSBpbnNhbml0aWVzIGFuZCBzdHVwaWQuIEl0IGlzIGFz IGVhc3kgdG8gcmVhZCBhbmQgd3JpdGUgYXMgUkZDODIyIGJ1dCB3aXRob3V0IHRoZSBsaW1pdGF0 aW9ucy4NCg0KDQpUaGUgc3BlYyBpdHNlbGYgd291bGQgYmUgc2ltcGxlLCBpdHMgYmFzaWNhbGx5 IGRyYWZ0LWlldGYtanNvbi10ZXh0LXNlcXVlbmNlIGFwcGxpZWQgdG8gYSBzZXF1ZW5jZSBvZiBv bmUganNvbiBvYmplY3QgYW5kIG9uZSBjb250ZW50IGJsb2IuDQoNCkpTT04gc2VxdWVuY2Ugc3Bl Y2lmaWVzIHRoYXQgIkEgSlNPTiB0ZXh0IHNlcXVlbmNlIGNvbnNpc3RzIG9mIGFueSBudW1iZXIg b2YgSlNPTiB0ZXh0cywgYWxsIGVuY29kZWQgaW4gVVRGLTgsIGVhY2ggcHJlZml4ZWQgYnkgYW4g QVNDSUkgUmVjb3JkIFNlcGFyYXRvciAoMHgxRSksIGFuZCBlYWNoIGVuZGluZyB3aXRoIGFuIEFT Q0lJIExpbmUgRmVlZCBjaGFyYWN0ZXIgKDB4MUEpIg0KDQpUaGlzIGlzIG5vdCBpZGVhbCBmb3Ig SlNPTiBDb250YWluZXIuIFdlIHdvdWxkIHByZWZlciB0aGF0IHRoZSBjaGFyYWN0ZXIgd2hpY2gg aXMgaWxsZWdhbCBpbiBhIEpTT04gZG9jdW1lbnQgYmUgdGhlIG9uZSB0aGF0IGlzIHRoZSBzZXBh cmF0b3IgYmV0d2VlbiB0aGUgaGVhZGVyIGFuZCBjb250ZW50Lg0KDQpBbGwgaW5kZXhlcyB1c2Vk IGluIHRoZSBtZXRhZGF0YSBoZWFkZXIgYXJlIGNhbGN1bGF0ZWQgZnJvbSB0aGUgUmVjb3JkIFNl cGFyYXRvciBieXRlLCB0aGUgZmlyc3QgYnl0ZSBmb2xsb3dpbmcgYmVpbmcgYnl0ZSAwIGFuZCBz byBvbi4NCg0KDQpBcHBseWluZyB0aGlzIGluIGEgV2ViIFNlcnZpY2UgaXMgdmVyeSBzaW1wbGUs IG91ciBtZXNzYWdlcyBub3cgaGF2ZSB0aGUgZm9ybToNCg0KUE9TVCAvIEhUVFAvMS4xDQpIb3N0 OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20+DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL2pzb24tY29udGFpbmVyDQpDb250ZW50LUxlbmd0aDogNjY2DQoNCnsgIlNpZ25hdHVyZSIg OiAid2Vmd2tqZWZrbGp3ZWhmamtsd2hlamtmbGgiIH0NCg0KPDB4MUU+eyAiU2VydmljZS1UeXBl IiA6ICJhY21lLndzPGh0dHA6Ly9hY21lLndzPiIsDQogICAiVHJhbnNhY3Rpb24tSUQiIDogIjJo MjNyb2loMjNvaWgyM29yaCIsDQogICAiUmVnaXN0ZXIiIDogeyAuLi4uPHdlYiBzZXJ2aWNlIHBh cmFtZXRlcnMgaGVyZT4gLi4uIH0gfQ0KDQpXaGVyZSA8MHgxRT4gaXMgdGhlIHJlY29yZCBzZXBh cmF0b3IgY2hhcmFjdGVyLg0KDQpUaGUgc2NvcGUgb2YgdGhlIHNpZ25hdHVyZSBpcyB0aGUgY29u dGVudCwgdGhlIHdob2xlIGNvbnRlbnQsIEFORCBOT1RISU5HIEJVVCBUSEUgQ09OVEVOVC4gU2ln bmluZyBoZWFkZXJzIGlzIGEgbXVncyBnYW1lLiBQdXQgYWxsIHRoZSBpbmZvcm1hdGlvbiB0aGF0 IG1hdHRlcnMgaW50byBvbmUgYmxvYiBhbmQgc2lnbiB0aGUgYmxvYi4gRG8gbm90IHByZXNlbnQg ZGV2ZWxvcGVycyB3aXRoIGFuIElLRUEgc2VsZi1hc3NlbWJseSBqb2IuDQoNClNvIHRvIHByZXZl bnQgcHJvdG9jb2wgc3Vic3RpdHV0aW9uIGF0dGFja3MsIHRoZSBzZXJ2aWNlIGlkZW50aWZpZXIg YW5kIHRoZSBtZXRob2QgbmFtZSB3cmFwIHRoZSBtZXRob2QgcGFyYW1ldGVycy4gSW4gYSByZXNw b25zZSwgdGhlIHNlcnZpY2UgaWRlbnRpZmllciwgcmVzcG9uc2UgY29kZSBhbmQgdHJhbnNhY3Rp b24gSUQgd3JhcCB0aGUgcmVzcG9uc2UgZGF0YSBmb3IgdGhlIHNhbWUgcmVhc29uLg0KDQoNCkFw cGx5aW5nIHRoZSBzY2hlbWUgdG8gc3RvcmVkIGRhdGEgaW4gYSBmaWxlIHN5c3RlbSBpcyBhIGxp dHRsZSBkaWZmZXJlbnQuIEZpcnN0IHdlIGhhdmUgdG8gZGV2ZWxvcCBhIGZpbGUgZXh0ZW5zaW9u IGNvbnZlbnRpb246DQoNCmZpbGUuanBnICBiZWNvbWVzIGZpbGUuanBnLmpzb25jDQoNCk1hbnkg anNvbmMgYXdhcmUgYXBwbGljYXRpb25zIHdpbGwgaGF2ZSB0byBzaGFyZSBkYXRhIHdpdGggYXBw bGljYXRpb25zIHRoYXQgYXJlIG5vdCBhd2FyZS4gU28gd2UgbmVlZCB0aGUgb3B0aW9uIG9mIHN0 b3JpbmcgbWV0YWRhdGEgaW4gYSBzZXBhcmF0ZSBmaWxlIHdoZW4gdGhhdCBpcyBjb252ZW5pZW50 Og0KDQpUaGUgbWV0YWRhdGEgZm9yIGZpbGUuanBnIGlzIHN0b3JlZCBpbiBmaWxlLmpzb25tDQoN CkluIHNvbWUgY2lyY3Vtc3RhbmNlcyB3ZSBtaWdodCB3YW50IHRvIGtlZXAgdGhlIG1ldGFkYXRh IGZvciBhbGwgdGhlIGZpbGVzIGluIGEgZGlyZWN0b3J5IG9yIHRyZWUgaW4gb25lIGZpbGUsIGEg bWV0YWRhdGEgY29udGFpbmVyLiBUaGlzIGNvdWxkIGJlIGpzb25tYy5qc29ubWMgYXBwZWFyaW5n IGluIGVpdGhlciB0aGUgZGlyZWN0b3J5IGEgZmlsZSBpcyBpbiBvciBvbmUgb2YgdGhlIGRpcmVj dG9yaWVzIGFib3ZlIGl0Lg0KDQpBIG1ldGFkYXRhIGNvbnRhaW5lciB3b3VsZCBiZSBhIEpTT04g Y29udGFpbmVyIGFuZCBiZWdpbiB3aXRoIHRoZSB1c3VhbCBtZXRhZGF0YSBoZWFkZXIgZm9yIHRo YXQgZmlsZSBmb2xsb3dlZCBieSBhIEpTT04gc2VxdWVuY2Ugb2YgZW50cmllcyBwZXIgZmlsZS4g SWYgdGhpcyBjb250YWlucyBhIHNpZ25hdHVyZSwgdGhlIGZpbGUgZW50cmllcyBjYW4ganVzdCBi ZSBkaWdlc3RzLg0KDQoNCk5vdGljZSBob3cgd2UgaGF2ZSBqdXN0IGRldmVsb3BlZCBhIGZvcm1h dCB0aGF0IGFsbG93cyB1cyB0byBzaWduIGEgY29tcGxldGUgY29kZSBkaXN0cmlidXRpb24gaW5j bHVkaW5nIGNvbnRlbnQgZGF0YSB2ZXJ5IGVhc2lseS4gVGhpcyBpcyBvYnZpb3VzbHkgb3V0IG9m IHNjb3BlIGZvciBBQ01FIGJ1dCB0aGUgZmFjdCB0aGF0IGFuIGFwcHJvYWNoIHRyYW5zZmVycyBz byBuZWF0bHkgdG8gYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBwcm9ibGVtIHN1Z2dlc3RzIHRoYXQg aXQgaXMgdGhlIHJpZ2h0IHRyYWNrLg0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1284ED9AA38WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEgc2lnbmVkIEpBUiBmaWxlIG1l ZXRzIHNvbWUgb2YgdGhlc2UgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NZXRhZGF0YSBhbmQgc2lnbmF0 dXJlcyBhcmUgaW4gZXh0cmEgZmlsZXMgaW4gdGhlIFpJUCBhcmNoaXZlOiBNRVRBLUlORi9NQU5J RkVTVC5NRiwgTUVUQS1JTkYvTVlLRVkuU0YsIE1FVEEtSU5GL01ZS0VZLlJTQS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q29u dGVudCBpcyB0aGUgb3RoZXIgZmlsZXMgaW4gdGhlIGFyY2hpdmUuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IGlzIG5vdCBK U09OIG9mIGNvdXJzZSwgYW5kIHRoZSBzaWduYXR1cmUgJmFtcDsgY2VydHMgYXJlIHBhY2thZ2Vk IGluIEFTTi4xLCBidXQgaXQgaXMgYSB1c2VmdWwgY29tcGFyaXNvbi4gSXQgYXZvaWRzIEJBU0U2 NCBvbiB0aGUgY29udGVudDsgY2FuIGFkZHMgc2lnbmF0dXJlcywgZGlnZXN0cywgYW5kIG90aGVy IG1ldGFkYXRhOyBjYW4gdHJhbnNwb3J0IGNvbnRlbnQgYW5kIG1ldGFkYXRhIGFzIGEgcmVndWxh ciBibG9iICgqLmphciBmaWxlKTsgY2FuIHNpZ24gY29tcGxldGUgY29kZSBkaXN0cmlidXRpb25z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBBY21lIFttYWlsdG86YWNtZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YgPC9iPlBoaWxsaXAgSGFsbGFtLUJha2VyPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjkg SmFudWFyeSAyMDE1IDU6MTUgQU08YnI+PGI+VG86PC9iPiBKU09OIFdHOyBhY21lQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBbQWNtZV0gU2lnbmVkIEpTT04gZG9jdW1lbnQgLyBKc29uIENv bnRlbnQgTWV0YWhlYWRlciAvIEpTT04gQ29udGFpbmVyPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5BbGwsJm5ic3A7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSB3 b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBzcGVjIHNpbWlsYXIgdG8gdGhlIEpTT04gbG9nIGZpbGUg c3BlYyBidXQgd2l0aCB0aGUgcHVycG9zZSBvZiBiZWluZyBhIGNvbnRhaW5lciBmb3IgSlNPTiBz aWduYXR1cmVzLiBUaGUgaW1tZWRpYXRlIGFwcGxpY2F0aW9uIGZvciB0aGlzIG1pZ2h0IGJlIGZv ciBBQ01FIG9yIG90aGVyIEpTT04vUmVzdCBXZWIgc2VydmljZXMuPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGVsZXZhdG9yIHBpdGNoIGZvciB0aGUgaWRlYSBpcyB0 aGF0IGEgSlNPTiBDb250YWluZXIgd291bGQgYmUgYSBKU09OIE1ldGFkYXRhIGJsb2Igd2l0aCB0 aGUgY29udGVudCBiZWluZyBkZXNjcmliZWQgYXBwZW5kZWQgdG8gdGhlIGVuZCBpbiBhIHdheSB0 aGF0IG1ha2VzIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gY29udGVudCBhbmQgbWV0YWRhdGEgc2lt cGxlIGFuZCB1bmFtYmlndW91cy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD4mbHQ7SlNPTi1CTE9CJmd0OyBbU2VwYXJhdG9yXSAmbHQ7Y29udGVudC1ibG9iJmd0OzxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFkdmFudGFnZXM6PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+KiBDYW4gcmVhZCB0aGUgbWV0YWRhdGEgZm9yIGEg ZmlsZSBldGMgd2l0aCBhIHBsYWluIEFTQ0lJIGVkaXRvciBvciBjb21tYW5kIGxpbmUgdG9vbHMg bGlrZSBjYXQsIG1vcmUsIGV0Yy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD4qIEF2b2lkcyB0aGUgbmVlZCB0byBCQVNFNjQgYXJtb3IgdGhlIGNvbnRlbnQuIFNvIGlmIHRo ZSBjb250ZW50IGlzIEpTT04gb3Igb3RoZXIgQVNDSUkvVW5pY29kZSB0ZXh0IGl0IHJlbWFpbnMg cmVhZGFibGUgaW4gYW4gQVNDSUkvVW5pY29kZSBlZGl0b3IuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+KiBDYW4gYWRkIHNpZ25hdHVyZXMsIGRpZ2VzdHMgYW5kIG90aGVy IG1ldGFkYXRhIGl0ZW1zIHRvIGNvbnRlbnQgaW4gYSBzaW1wbGUgcmVndWxhciBmYXNoaW9uLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiogQ29udGVudCBhbmQgbWV0YWRh dGEgY2FuIGJlIHRyYW5zcG9ydGVkIGFzIGEgc2ltcGxlIHJlZ3VsYXIgYmxvYiB0aGF0IGlzIGZ1 bGx5IGFic3RyYWN0ZWQgZnJvbSBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIHRyYW5zcG9ydCBhbmQg d2l0aG91dCB0aGUgbmVlZCBmb3IgY2Fub25pY2FsaXphdGlvbiwgWFBhdGggb3Igb3RoZXIgY29t cGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SaWdodCBub3csIHRo ZSBJRVRGIHNwZWMgZm9yIGRlc2NyaWJpbmcgY29udGVudCBtZXRhZGF0YSBpcyBiYXNlZCBvbiBS RkM4MjIuIEFuZCBieSAnYmFzZWQgb24nLCBJIG1lYW4gdGhhdCBpdCBpcyBhIGZpbmQgdGhlIG5l ZWRsZSBpbiB0aGUgUkZDIGhheXN0YWNrIGFwcHJvYWNoLiBSRkM4MjIgc3R5bGUgY29udGVudCBo ZWFkZXJzIGFzIGN1cnJlbnRseSB1c2VkIGhhdmUgc2V2ZXJhbCBkaXNhZHZhbnRhZ2VzOjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiogSXQgaXMgYSBmbGF0IHN0cnVjdHVy ZSwgaGVhZGVycyBjYW4gaGF2ZSBhdHRyaWJ1dGVzIGJ1dCB0cnlpbmcgdG8gYWRkIG1vcmUgc3Ry dWN0dXJlIGlzIHBhaW5mdWwuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ KiBJdCBpcyBhIGhpc3RvcmljYWwgYXJ0aWZhY3QgYW5kIGNvbnRlbnQgbWV0YWRhdGEgaGVhZGVy cyBhcmUgbWl4ZWQgaW4gd2l0aCBwcm90b2NvbCBtZXRhZGF0YSBoZWFkZXJzIHdpdGhvdXQgcmh5 bWUgb3IgcmVhc29uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiogSXQg aXMgbm90IEpTT04gYW5kIEpTT04gaXMgdGhlIHNwZWMgd2UgYXJlIG5vdyBjb252ZXJnaW5nIG9u IGZvciB0aGlzIHR5cGUgb2Ygd29yay4gSXQgaGFzIGFsbCB0aGUgZXhwcmVzc2l2ZSBjYXBhYmls aXRpZXMgb2YgWE1MIGFuZCBBU00uMSB3aXRob3V0IHRoZSBpbnNhbml0aWVzIGFuZCBzdHVwaWQu IEl0IGlzIGFzIGVhc3kgdG8gcmVhZCBhbmQgd3JpdGUgYXMgUkZDODIyIGJ1dCB3aXRob3V0IHRo ZSBsaW1pdGF0aW9ucy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgc3BlYyBp dHNlbGYgd291bGQgYmUgc2ltcGxlLCBpdHMgYmFzaWNhbGx5Jm5ic3A7ZHJhZnQtaWV0Zi1qc29u LXRleHQtc2VxdWVuY2UgYXBwbGllZCB0byBhIHNlcXVlbmNlIG9mIG9uZSBqc29uIG9iamVjdCBh bmQgb25lIGNvbnRlbnQgYmxvYi48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5KU09OIHNlcXVlbmNlIHNwZWNpZmllcyB0aGF0ICZxdW90O0EgSlNPTiB0ZXh0IHNlcXVlbmNl IGNvbnNpc3RzIG9mIGFueSBudW1iZXIgb2YgSlNPTiB0ZXh0cywgYWxsIGVuY29kZWQgaW4gVVRG LTgsIGVhY2ggcHJlZml4ZWQgYnkgYW4gQVNDSUkgUmVjb3JkIFNlcGFyYXRvciAoMHgxRSksIGFu ZCBlYWNoIGVuZGluZyB3aXRoIGFuIEFTQ0lJIExpbmUgRmVlZCBjaGFyYWN0ZXIgKDB4MUEpJnF1 b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhpcyBpcyBub3QgaWRl YWwgZm9yIEpTT04gQ29udGFpbmVyLiBXZSB3b3VsZCBwcmVmZXIgdGhhdCB0aGUgY2hhcmFjdGVy IHdoaWNoIGlzIGlsbGVnYWwgaW4gYSBKU09OIGRvY3VtZW50IGJlIHRoZSBvbmUgdGhhdCBpcyB0 aGUgc2VwYXJhdG9yIGJldHdlZW4gdGhlIGhlYWRlciBhbmQgY29udGVudC48bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BbGwgaW5kZXhlcyB1c2VkIGluIHRoZSBtZXRhZGF0 YSBoZWFkZXIgYXJlIGNhbGN1bGF0ZWQgZnJvbSB0aGUgUmVjb3JkIFNlcGFyYXRvciBieXRlLCB0 aGUgZmlyc3QgYnl0ZSBmb2xsb3dpbmcgYmVpbmcgYnl0ZSAwIGFuZCBzbyBvbi48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BcHBseWluZyB0aGlzIGluIGEgV2ViIFNlcnZpY2UgaXMg dmVyeSBzaW1wbGUsIG91ciBtZXNzYWdlcyBub3cgaGF2ZSB0aGUgZm9ybTo8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QT1NUIC8gSFRUUC8xLjE8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Ib3N0OiA8YSBocmVmPSJodHRwOi8vZXhhbXBs ZS5jb20iPmV4YW1wbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbi1jb250YWluZXI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Db250ZW50LUxlbmd0aDogNjY2 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+eyAmcXVvdDtTaWduYXR1cmUm cXVvdDsgOiAmcXVvdDt3ZWZ3a2plZmtsandlaGZqa2x3aGVqa2ZsaCZxdW90OyB9PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmx0OzB4MUUmZ3Q7eyAmcXVvdDtTZXJ2aWNl LVR5cGUmcXVvdDsgOiAmcXVvdDs8YSBocmVmPSJodHRwOi8vYWNtZS53cyI+YWNtZS53czwvYT4m cXVvdDssPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 ICZuYnNwOyZxdW90O1RyYW5zYWN0aW9uLUlEJnF1b3Q7IDogJnF1b3Q7MmgyM3JvaWgyM29paDIz b3JoJnF1b3Q7LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZu YnNwOyAmbmJzcDsmcXVvdDtSZWdpc3RlciZxdW90OyA6IHsgLi4uLiZsdDt3ZWIgc2VydmljZSBw YXJhbWV0ZXJzIGhlcmUmZ3Q7IC4uLiB9IH08bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5XaGVyZSAmbHQ7MHgxRSZndDsgaXMgdGhlIHJlY29yZCBzZXBhcmF0b3IgY2hhcmFj dGVyLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBzY29wZSBvZiB0 aGUgc2lnbmF0dXJlIGlzIHRoZSBjb250ZW50LCB0aGUgd2hvbGUgY29udGVudCwgQU5EIE5PVEhJ TkcgQlVUIFRIRSBDT05URU5ULiBTaWduaW5nIGhlYWRlcnMgaXMgYSBtdWdzIGdhbWUuIFB1dCBh bGwgdGhlIGluZm9ybWF0aW9uIHRoYXQgbWF0dGVycyBpbnRvIG9uZSBibG9iIGFuZCBzaWduIHRo ZSBibG9iLiBEbyBub3QgcHJlc2VudCBkZXZlbG9wZXJzIHdpdGggYW4gSUtFQSBzZWxmLWFzc2Vt Ymx5IGpvYi48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TbyB0byBwcmV2 ZW50IHByb3RvY29sIHN1YnN0aXR1dGlvbiBhdHRhY2tzLCB0aGUgc2VydmljZSBpZGVudGlmaWVy IGFuZCB0aGUgbWV0aG9kIG5hbWUgd3JhcCB0aGUgbWV0aG9kIHBhcmFtZXRlcnMuIEluIGEgcmVz cG9uc2UsIHRoZSBzZXJ2aWNlIGlkZW50aWZpZXIsIHJlc3BvbnNlIGNvZGUgYW5kIHRyYW5zYWN0 aW9uIElEIHdyYXAgdGhlIHJlc3BvbnNlIGRhdGEgZm9yIHRoZSBzYW1lIHJlYXNvbi48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BcHBseWluZyB0aGUgc2NoZW1lIHRvIHN0b3JlZCBk YXRhIGluIGEgZmlsZSBzeXN0ZW0gaXMgYSBsaXR0bGUgZGlmZmVyZW50LiBGaXJzdCB3ZSBoYXZl IHRvIGRldmVsb3AgYSBmaWxlIGV4dGVuc2lvbiBjb252ZW50aW9uOjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPmZpbGUuanBnICZuYnNwO2JlY29tZXMgZmlsZS5qcGcuanNv bmM8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5NYW55IGpzb25jIGF3YXJl IGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdG8gc2hhcmUgZGF0YSB3aXRoIGFwcGxpY2F0aW9ucyB0 aGF0IGFyZSBub3QgYXdhcmUuIFNvIHdlIG5lZWQgdGhlIG9wdGlvbiBvZiBzdG9yaW5nIG1ldGFk YXRhIGluIGEgc2VwYXJhdGUgZmlsZSB3aGVuIHRoYXQgaXMgY29udmVuaWVudDo8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgbWV0YWRhdGEgZm9yIGZpbGUuanBnIGlz IHN0b3JlZCBpbiBmaWxlLmpzb25tPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SW4gc29tZSBjaXJjdW1zdGFuY2VzIHdlIG1pZ2h0IHdhbnQgdG8ga2VlcCB0aGUgbWV0YWRh dGEgZm9yIGFsbCB0aGUgZmlsZXMgaW4gYSBkaXJlY3Rvcnkgb3IgdHJlZSBpbiBvbmUgZmlsZSwg YSBtZXRhZGF0YSBjb250YWluZXIuIFRoaXMgY291bGQgYmUganNvbm1jLmpzb25tYyBhcHBlYXJp bmcgaW4gZWl0aGVyIHRoZSBkaXJlY3RvcnkgYSBmaWxlIGlzIGluIG9yIG9uZSBvZiB0aGUgZGly ZWN0b3JpZXMgYWJvdmUgaXQuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ QSBtZXRhZGF0YSBjb250YWluZXIgd291bGQgYmUgYSBKU09OIGNvbnRhaW5lciBhbmQgYmVnaW4g d2l0aCB0aGUgdXN1YWwgbWV0YWRhdGEgaGVhZGVyIGZvciB0aGF0IGZpbGUgZm9sbG93ZWQgYnkg YSBKU09OIHNlcXVlbmNlIG9mIGVudHJpZXMgcGVyIGZpbGUuIElmIHRoaXMgY29udGFpbnMgYSBz aWduYXR1cmUsIHRoZSBmaWxlIGVudHJpZXMgY2FuIGp1c3QgYmUgZGlnZXN0cy48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Ob3RpY2UgaG93IHdlIGhhdmUganVzdCBkZXZlbG9wZWQg YSBmb3JtYXQgdGhhdCBhbGxvd3MgdXMgdG8gc2lnbiBhIGNvbXBsZXRlIGNvZGUgZGlzdHJpYnV0 aW9uIGluY2x1ZGluZyBjb250ZW50IGRhdGEgdmVyeSBlYXNpbHkuIFRoaXMgaXMgb2J2aW91c2x5 IG91dCBvZiBzY29wZSBmb3IgQUNNRSBidXQgdGhlIGZhY3QgdGhhdCBhbiBhcHByb2FjaCB0cmFu c2ZlcnMgc28gbmVhdGx5IHRvIGEgY29tcGxldGVseSBkaWZmZXJlbnQgcHJvYmxlbSBzdWdnZXN0 cyB0aGF0IGl0IGlzIHRoZSByaWdodCB0cmFjay48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+ PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1284ED9AA38WSMSG3153Vsrv_-- From nobody Wed Jan 28 18:57:53 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D8D1A8ADC; Wed, 28 Jan 2015 18:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLyAM8SRmdEV; Wed, 28 Jan 2015 18:57:47 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956711A1B39; Wed, 28 Jan 2015 18:57:47 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id z81so22642883oif.2; Wed, 28 Jan 2015 18:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=595tA3U5e8XE7XG1NKLUdwjHd3N8PgjDbyr1p4+RYS4=; b=rDi+SKYB2D12FD5fROFEwYJx/QGa1lrTunV/XN5m0fx6rEHKxeWb85RZX5r3PiIt2D naV0wMwqx27Wxb+M6b7p2hhd7ztqTBijGt4332h5mG2yqtVrItiUEv7/FVTMTPdc84I1 EO32pIDiWYsCXwGN9uqYjUz3FRcvagix90/sDApcTiaDHKodrDYZhdOxFUHt0HzUCgbg lfWghtHZfoo6jwl3oMe7Of/CZrD9RiqjCInaYSuP4U/HbPYQy0X0kX2aKKCGD1eMNHb3 um0wmVkK3P0EWkO6sGRi0Z81puzIOr1i1dpyMgg5le32I4O7apx5rodccmnBkvKERmlW KzqQ== X-Received: by 10.60.44.70 with SMTP id c6mr4285621oem.36.1422500266767; Wed, 28 Jan 2015 18:57:46 -0800 (PST) MIME-Version: 1.0 References: <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> From: Nat Sakimura Date: Thu, 29 Jan 2015 02:57:46 +0000 Message-ID: To: "Manger, James" , Phillip Hallam-Baker , JSON WG , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11c21c70180168050dc1a737 Archived-At: Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 02:57:51 -0000 --001a11c21c70180168050dc1a737 Content-Type: text/plain; charset=UTF-8 On a side note: if such a spec is to be defined here, IMHO, it should use the algorithms and probably header parameters specified by JWA, etc. It should limit the scope to payload processing and expression of the entire thing in JSON Log like format, and leave the rest to JOSE. On Thu Jan 29 2015 at 11:51:24 Manger, James < James.H.Manger@team.telstra.com> wrote: > A signed JAR file meets some of these requirements. > > Metadata and signatures are in extra files in the ZIP archive: > META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA. > > Content is the other files in the archive. > > It is not JSON of course, and the signature & certs are packaged in ASN.1, > but it is a useful comparison. It avoids BASE64 on the content; can adds > signatures, digests, and other metadata; can transport content and metadata > as a regular blob (*.jar file); can sign complete code distributions. > > > > -- > > James Manger > > > > *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Thursday, 29 January 2015 5:15 AM > *To:* JSON WG; acme@ietf.org > *Subject:* [Acme] Signed JSON document / Json Content Metaheader / JSON > Container > > > > All, > > > > I would like to propose a spec similar to the JSON log file spec but with > the purpose of being a container for JSON signatures. The immediate > application for this might be for ACME or other JSON/Rest Web services. > > > > The elevator pitch for the idea is that a JSON Container would be a JSON > Metadata blob with the content being described appended to the end in a way > that makes the separation between content and metadata simple and > unambiguous. > > > > [Separator] > > > > Advantages: > > > > * Can read the metadata for a file etc with a plain ASCII editor or > command line tools like cat, more, etc. > > > > * Avoids the need to BASE64 armor the content. So if the content is JSON > or other ASCII/Unicode text it remains readable in an ASCII/Unicode editor. > > > > * Can add signatures, digests and other metadata items to content in a > simple regular fashion. > > > > * Content and metadata can be transported as a simple regular blob that is > fully abstracted from and independent of the transport and without the need > for canonicalization, XPath or other complications. > > > > > > Right now, the IETF spec for describing content metadata is based on > RFC822. And by 'based on', I mean that it is a find the needle in the RFC > haystack approach. RFC822 style content headers as currently used have > several disadvantages: > > > > * It is a flat structure, headers can have attributes but trying to add > more structure is painful. > > > > * It is a historical artifact and content metadata headers are mixed in > with protocol metadata headers without rhyme or reason. > > > > * It is not JSON and JSON is the spec we are now converging on for this > type of work. It has all the expressive capabilities of XML and ASM.1 > without the insanities and stupid. It is as easy to read and write as > RFC822 but without the limitations. > > > > > > The spec itself would be simple, its > basically draft-ietf-json-text-sequence applied to a sequence of one json > object and one content blob. > > > > JSON sequence specifies that "A JSON text sequence consists of any number > of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record > Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A)" > > > > This is not ideal for JSON Container. We would prefer that the character > which is illegal in a JSON document be the one that is the separator > between the header and content. > > > > All indexes used in the metadata header are calculated from the Record > Separator byte, the first byte following being byte 0 and so on. > > > > > > Applying this in a Web Service is very simple, our messages now have the > form: > > > > POST / HTTP/1.1 > > Host: example.com > > Content-Type: application/json-container > > Content-Length: 666 > > > > { "Signature" : "wefwkjefkljwehfjklwhejkflh" } > > > > <0x1E>{ "Service-Type" : "acme.ws", > > "Transaction-ID" : "2h23roih23oih23orh", > > "Register" : { .... ... } } > > > > Where <0x1E> is the record separator character. > > > > The scope of the signature is the content, the whole content, AND NOTHING > BUT THE CONTENT. Signing headers is a mugs game. Put all the information > that matters into one blob and sign the blob. Do not present developers > with an IKEA self-assembly job. > > > > So to prevent protocol substitution attacks, the service identifier and > the method name wrap the method parameters. In a response, the service > identifier, response code and transaction ID wrap the response data for the > same reason. > > > > > > Applying the scheme to stored data in a file system is a little different. > First we have to develop a file extension convention: > > > > file.jpg becomes file.jpg.jsonc > > > > Many jsonc aware applications will have to share data with applications > that are not aware. So we need the option of storing metadata in a separate > file when that is convenient: > > > > The metadata for file.jpg is stored in file.jsonm > > > > In some circumstances we might want to keep the metadata for all the files > in a directory or tree in one file, a metadata container. This could be > jsonmc.jsonmc appearing in either the directory a file is in or one of the > directories above it. > > > > A metadata container would be a JSON container and begin with the usual > metadata header for that file followed by a JSON sequence of entries per > file. If this contains a signature, the file entries can just be digests. > > > > > > Notice how we have just developed a format that allows us to sign a > complete code distribution including content data very easily. This is > obviously out of scope for ACME but the fact that an approach transfers so > neatly to a completely different problem suggests that it is the right > track. > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c21c70180168050dc1a737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On a side note: if such a spec is to be defined here, IMHO, it should use t= he algorithms and probably header parameters specified by JWA, etc. It shou= ld limit the scope to payload processing and expression of the entire thing= in JSON Log like format, and leave the rest to JOSE.=C2=A0

On Thu Jan 29 2015 at 11:51:24 Manger, James <James.H.Manger@team.telstra.com= > wrote:

A signed JAR file meets some of these requirements.

Metadata and sign= atures are in extra files in the ZIP archive: META-INF/MANIFEST.MF, META-IN= F/MYKEY.SF, META-INF/MYKEY.RSA.

Content is the other files in the archive.

It= is not JSON of course, and the signature & certs are packaged in ASN.1= , but it is a useful comparison. It avoids BASE64 on the content; can adds = signatures, digests, and other metadata; can transport content and metadata= as a regular blob (*.jar file); can sign complete code distributions.

=C2=A0

--

James Manger

=C2=A0

From: Acme [mailto:= acme-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
S= ent: Thursday, 29 January 2015 5:15 AM
To: JSON WG; acme@ietf.org
Subject= : [Acme] Signed JSON document / Json Content Metaheader / JSON Containe= r

=C2=A0

All,=C2=A0

=C2=A0

I would lik= e to propose a spec similar to the JSON log file spec but with the purpose = of being a container for JSON signatures. The immediate application for thi= s might be for ACME or other JSON/Rest Web services.

=C2=A0

The elevator pitch for the idea is that a JSON Container would = be a JSON Metadata blob with the content being described appended to the en= d in a way that makes the separation between content and metadata simple an= d unambiguous.

= =C2=A0

<JSON-BLOB> [Separ= ator] <content-blob>

=C2=A0

Advantages:=

=C2=A0

* Can read the metadata for a file etc with= a plain ASCII editor or command line tools like cat, more, etc.<= /u>

=C2=A0

* Avoids the need to BASE64 armor the content. So i= f the content is JSON or other ASCII/Unicode text it remains readable in an= ASCII/Unicode editor.

<= u>=C2=A0

* Can add signatur= es, digests and other metadata items to content in a simple regular fashion= .

=C2=A0

* Content and metadata can be transport= ed as a simple regular blob that is fully abstracted from and independent o= f the transport and without the need for canonicalization, XPath or other c= omplications.

=C2= =A0

=C2=A0

Right now, the IETF spec for describing cont= ent metadata is based on RFC822. And by 'based on', I mean that it = is a find the needle in the RFC haystack approach. RFC822 style content hea= ders as currently used have several disadvantages:

<= div>

=C2=A0

* It is a flat structure, headers can have attributes but trying = to add more structure is painful.

=C2=A0

* It is= a historical artifact and content metadata headers are mixed in with proto= col metadata headers without rhyme or reason.

<= p class=3D"MsoNormal">=C2=A0

* It is not JSON and JSON is the spec we are now converging on for thi= s type of work. It has all the expressive capabilities of XML and ASM.1 wit= hout the insanities and stupid. It is as easy to read and write as RFC822 b= ut without the limitations.

=C2=A0

=C2=A0=

The spec itself would be simpl= e, its basically=C2=A0draft-ietf-json-text-sequence applied to a sequence o= f one json object and one content blob.

=C2=A0

J= SON sequence specifies that "A JSON text sequence consists of any numb= er of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Se= parator (0x1E), and each ending with an ASCII Line Feed character (0x1A)&qu= ot;

=C2=A0=

This is not ideal for JSON Container.= We would prefer that the character which is illegal in a JSON document be = the one that is the separator between the header and content.=

=C2=A0

All indexes used in the metadata header are calculated= from the Record Separator byte, the first byte following being byte 0 and = so on.

=C2=A0<= /u>

=C2=A0

Applying this in a Web Service is very simple, our = messages now have the form:

=C2=A0

POST / HTTP/1= .1

Content-Type: application/json-container

Content-Length: 666

=C2=A0

<= p class=3D"MsoNormal">{ "Signature" : "wefwkjefkljwehfjklwhe= jkflh" }

=C2= =A0

<0x1E>{ "Service= -Type" : "acme.ws",

<= div>

Applying the scheme to stored data in a file sys= tem is a little different. First we have to develop a file extension conven= tion:

The metadata for file.jpg is stored in file.jsonm

=C2=A0

<= /div>

In some circumstances we might want to kee= p the metadata for all the files in a directory or tree in one file, a meta= data container. This could be jsonmc.jsonmc appearing in either the directo= ry a file is in or one of the directories above it.

=

=C2=A0

A metadata container would be a JSON container and begin with th= e usual metadata header for that file followed by a JSON sequence of entrie= s per file. If this contains a signature, the file entries can just be dige= sts.

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">Notice how we have just developed a format that allow= s us to sign a complete code distribution including content data very easil= y. This is obviously out of scope for ACME but the fact that an approach tr= ansfers so neatly to a completely different problem suggests that it is the= right track.

=C2= =A0

=C2=A0

_______________________________________________=
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c21c70180168050dc1a737-- From nobody Wed Jan 28 20:03:22 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BBA1A1B51; Wed, 28 Jan 2015 20:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rWn0tl79PhR; Wed, 28 Jan 2015 20:03:07 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1FB1A1AB4; Wed, 28 Jan 2015 20:03:07 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id 10so23904772lbg.10; Wed, 28 Jan 2015 20:03:05 -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=N+ZIj/d932Tc08iUr4zlvf9TYblAQ6UWIR3f+CS1vX8=; b=Jj1OSf/i/kQCW7RjgupJhIUrGVBpZT9TOP1scEd+3+mO42c3luvIvghOzrH3PBEIVa AlRVFQ9pK61+fOHGf7j7Rgl3u2wVRhTb8Ozs4w/UMkdYKD8RijRZxKlHaYgV6e9ImQJO sHQ8q08smKIi9zny5f0tAxVN3YkZGbkUFN/V9f5YzDRHDIiNVaRU6GF07OEuTSzxOfSh NrgJVUBaGoTqRRER6v5Fm+q3XXfzxBsIR48QJX84GuAUEFAFNrgPFhby/RIiAg7y/q9B sVcO+/sEkjnGIBpGLvV21i1trn0B8F4sTbESKKSyHhQPrLrh2ImdfN14uCx5yMiGJi14 dOzw== MIME-Version: 1.0 X-Received: by 10.152.29.193 with SMTP id m1mr12014457lah.84.1422504185595; Wed, 28 Jan 2015 20:03:05 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 20:03:05 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 28 Jan 2015 23:03:05 -0500 X-Google-Sender-Auth: 4t53TvsEJNw0e6zH8ipqvXcFy0U Message-ID: From: Phillip Hallam-Baker To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e0158bf4cac8bec050dc2904a Archived-At: Cc: "acme@ietf.org" , "Manger, James" , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 04:03:11 -0000 --089e0158bf4cac8bec050dc2904a Content-Type: text/plain; charset=UTF-8 On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura wrote: > On a side note: if such a spec is to be defined here, IMHO, it should use > the algorithms and probably header parameters specified by JWA, etc. It > should limit the scope to payload processing and expression of the entire > thing in JSON Log like format, and leave the rest to JOSE. > Absolutely. In fact that is why I am not raising it in JOSE as that just provides the format for the main crypto attributes. > On Thu Jan 29 2015 at 11:51:24 Manger, James < > James.H.Manger@team.telstra.com> wrote: > >> A signed JAR file meets some of these requirements. >> >> Metadata and signatures are in extra files in the ZIP archive: >> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA. >> >> Content is the other files in the archive. >> >> It is not JSON of course, and the signature & certs are packaged in >> ASN.1, but it is a useful comparison. It avoids BASE64 on the content; can >> adds signatures, digests, and other metadata; can transport content and >> metadata as a regular blob (*.jar file); can sign complete code >> distributions. >> >> >> I have used signed jar files. But Sun rather poisoned the well there by suing Microsoft over control of Java followed up by further lawsuits from Oracle. I can't imagine anyone is going to accept Jar or anything involving assinine.1 as a wire format for packaging. Those days are long past. The way you get coherence is to pick one encoding and stick to it. JSON seems to have been the one we picked. It has all the functionality offered by the alternatives and none of the drawbacks. --089e0158bf4cac8bec050dc2904a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <sakimura@gmail.com= > wrote:
On a side note: if suc= h a spec is to be defined here, IMHO, it should use the algorithms and prob= ably header parameters specified by JWA, etc. It should limit the scope to = payload processing and expression of the entire thing in JSON Log like form= at, and leave the rest to JOSE.

Absolut= ely. In fact that is why I am not raising it in JOSE as that just provides = the format for the main crypto attributes.=C2=A0

<= br>


=C2=A0
On Thu Jan = 29 2015 at 11:51:24 Manger, James <James.H.Manger@team.telstra.com> wro= te:

A signed JAR file meets some of these requirements.

Metad= ata and signatures are in extra files in the ZIP archive: META-INF/MANIFEST= .MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.

Content is the other files in th= e archive.

It is not JSON of course, and the signature & certs are packa= ged in ASN.1, but it is a useful comparison. It avoids BASE64 on the conten= t; can adds signatures, digests, and other metadata; can transport content = and metadata as a regular blob (*.jar file); can sign complete code distrib= utions.


=

I have used signed jar = files. But Sun rather poisoned the well there by suing Microsoft over contr= ol of Java followed up by further lawsuits from Oracle.

I can't imagine anyone is going to accept Jar or anything involvi= ng assinine.1 as a wire format for packaging. Those days are long past. The= way you get coherence is to pick one encoding and stick to it. JSON seems = to have been the one we picked. It has all the functionality offered by the= alternatives and none of the drawbacks.
=C2=A0
=
--089e0158bf4cac8bec050dc2904a-- From nobody Wed Jan 28 22:12:50 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05A1A6F2B for ; Wed, 28 Jan 2015 22:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vk2a_EpzBxQ for ; Wed, 28 Jan 2015 22:12:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65FF1A000C for ; Wed, 28 Jan 2015 22:12:41 -0800 (PST) Received: from netb ([82.113.121.85]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MBZ9u-1YRBun3Fna-00Aa7i; Thu, 29 Jan 2015 07:12:04 +0100 From: Bjoern Hoehrmann To: Nico Williams Date: Thu, 29 Jan 2015 07:11:54 +0100 Message-ID: References: <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <255B9BB34FB7D647A506DC292726F6E1284EB0326B@WSMSG3153V.srv.dir.telstra.com> <20150128232928.GL3110@localhost> In-Reply-To: <20150128232928.GL3110@localhost> 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:9qRnDaLJzcKTLToQYHolcAlF2ujnzB2i8rwLqSSyyDhXWth3GZR TegTQrqsRO1F11jnnSJfIzBoXXU/TAogJFaGHkHTwh9qQzJcKDZ2/kPfpojYaetq0VN7wCz zwUJ+Ae3HZ2RV9IaHgj0JfBlOpMGRsRii6yau8aIr+8RZaNsONnTW8MPleHhKz2M28mQPrv GZtx9dYRRUgw+ANl/cVTA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , "rfc-interest@rfc-editor.org" , "Manger, James" , Sean Leonard , "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 06:12:45 -0000 * Nico Williams wrote: >On Thu, Jan 29, 2015 at 10:25:34AM +1100, Manger, James wrote: >> >> Overall I still stand by my proposition that the RFC is the module >> >> for ABNF purposes. Honestly it just makes things a lot simpler. >> >> > Well, draft-ietf-json-text-sequence-13 will break this proposition. >> >> > But this issue (two ABNF rules with the same name) was raised earlier, and no one thought it was a problem. >> >> The issued was raised because someone did think it was a problem. > >I typed too quickly. I mean that no one thought the change had to be >made. I very strongly urge to change this. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Thu Jan 29 03:04:13 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B01A020B for ; Thu, 29 Jan 2015 03:04:10 -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 YNldXILN-J25 for ; Thu, 29 Jan 2015 03:04:09 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C66F1A01F6 for ; Thu, 29 Jan 2015 03:04:09 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B243E22E262; Thu, 29 Jan 2015 06:04:00 -0500 (EST) Message-ID: <54CA13A1.5050502@seantek.com> Date: Thu, 29 Jan 2015 03:04:01 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Nico Williams References: <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <255B9BB34FB7D647A506DC292726F6E1284EB0326B@WSMSG3153V.srv.dir.telstra.com> <20150128232928.GL3110@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , "rfc-interest@rfc-editor.org" , "Manger, James" , "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 11:04:10 -0000 On 1/28/2015 10:11 PM, Bjoern Hoehrmann wrote: > * Nico Williams wrote: >> On Thu, Jan 29, 2015 at 10:25:34AM +1100, Manger, James wrote: >>>>> Overall I still stand by my proposition that the RFC is the module >>>>> for ABNF purposes. Honestly it just makes things a lot simpler. >>>> Well, draft-ietf-json-text-sequence-13 will break this proposition. >>>> But this issue (two ABNF rules with the same name) was raised earlie= r, and no one thought it was a problem. >>> The issued was raised because someone did think it was a problem. >> I typed too quickly. I mean that no one thought the change had to be >> made. > I very strongly urge to change this. Yes. Let's just look at this from a readability standpoint. Suppose you have some standard that defines "newline" in two different=20 illustrations as: newline =3D CR =2E.. newline =3D LF is that really clear? It's pretty unclear. I would call that an=20 editorial problem (at least). It would be much clearer to say: newlineMac =3D CR =2E.. newlineUnix =3D LF anynewline =3D newlineMac / newlineUnix i.e., with different rule names. Then you can say things in the=20 specification text, like "in UNIX environments, use newlineUnix...but=20 when reading data from an unknown source, use anynewline..." and be=20 unambiguous. Sean From nobody Thu Jan 29 07:11:14 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CF21A1B74; Wed, 28 Jan 2015 20:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.628 X-Spam-Level: * X-Spam-Status: No, score=1.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, 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 ADGR7OdzgLuX; Wed, 28 Jan 2015 20:25:51 -0800 (PST) Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90CF1A1AB4; Wed, 28 Jan 2015 20:25:50 -0800 (PST) Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t0T4PF7p036188; Thu, 29 Jan 2015 14:25:15 +1000 (EST) (envelope-from frase@frase.id.au) Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t0T4PFnJ004856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 14:25:15 +1000 (EST) (envelope-from frase@frase.id.au) Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9/Submit) id t0T4P9xr004855; Thu, 29 Jan 2015 14:25:09 +1000 (EST) (envelope-from frase@frase.id.au) X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f Date: Thu, 29 Jan 2015 14:25:09 +1000 From: Fraser Tweedale To: Phillip Hallam-Baker Message-ID: <20150129042508.GA4845@bacardi.hollandpark.frase.id.au> References: <255B9BB34FB7D647A506DC292726F6E1284ED9AA38@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-Mailman-Approved-At: Thu, 29 Jan 2015 07:11:12 -0800 Cc: "Manger, James" , "acme@ietf.org" , Nat Sakimura , JSON WG Subject: Re: [Json] [Acme] Signed JSON document / Json Content Metaheader / JSON Container X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Jan 2015 04:25:52 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2015 at 11:03:05PM -0500, Phillip Hallam-Baker wrote: > On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura wrote: >=20 > > On a side note: if such a spec is to be defined here, IMHO, it should u= se > > the algorithms and probably header parameters specified by JWA, etc. It > > should limit the scope to payload processing and expression of the enti= re > > thing in JSON Log like format, and leave the rest to JOSE. > > >=20 > Absolutely. In fact that is why I am not raising it in JOSE as that just > provides the format for the main crypto attributes. >=20 >=20 >=20 >=20 >=20 >=20 > > On Thu Jan 29 2015 at 11:51:24 Manger, James < > > James.H.Manger@team.telstra.com> wrote: > > > >> A signed JAR file meets some of these requirements. > >> > >> Metadata and signatures are in extra files in the ZIP archive: > >> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA. > >> > >> Content is the other files in the archive. > >> > >> It is not JSON of course, and the signature & certs are packaged in > >> ASN.1, but it is a useful comparison. It avoids BASE64 on the content;= can > >> adds signatures, digests, and other metadata; can transport content and > >> metadata as a regular blob (*.jar file); can sign complete code > >> distributions. > >> > >> > >> > I have used signed jar files. But Sun rather poisoned the well there by > suing Microsoft over control of Java followed up by further lawsuits from > Oracle. >=20 > I can't imagine anyone is going to accept Jar or anything involving > assinine.1 as a wire format for packaging. Those days are long past. The > way you get coherence is to pick one encoding and stick to it. JSON seems > to have been the one we picked. It has all the functionality offered by t= he > alternatives and none of the drawbacks. There are =E2=88=9E valid ways to serialise a JSON object. If a JSON object is signed over, it must be canonicalised, or signed over and transported in serialised form. JOSE takes the latter approach (base64url-encoded serialised JSON object, inside a JSON object), while JWK thumbprint draft uses canonicalisation. ASN.1 encodings and deterministic binary serialisations can avoid the need for these sorts of hacks. I agree the JSON ship has sailed, but there *are* drawbacks. Regards, Fraser > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUybYiAAoJEEtTkFJBEeHiZboP/ixGct5l+DmLVt8MW/bAGgWX Yw/EW282qrzKfNVjgzuG6fQVPqUr7QVH6SRPCr7Rx4vZSlI+N9NmG+ySHon9Lhjc 4Hr9rLa1zyk6Lj7ZXAo24MmiKoHwDd0MdXOMymS/VjHXLLXmZONnqswLQ7NG9CeS 0xyuVO2DfuSyUfBlBoyngaZbExoLnbcRVVA9dgMBg8k3okcccYS+VuhH2evm6yo2 s7IO5w6xp5HqyVkM1SxC0fYIDILIikPMBYTivCSZVrQ/iW9TN+t5gJx6DhTr+sgL MyPlFbgEDYN8haXov9NwMxsrpjSQIZdNtjD7jv2TFUcZKFXgHB82UPlQ7p8pr+pU qFbvj935946N1ctRzSCHpEOubLXnaMp6cUxiDqf+GtOw13y7EcAa3tDVj/UNHuGf PI0uPbrWJcjWW33p3T9EZCzM08jlHXgjyIJ6yPNlxQP6+uP9brJnFlwVoRUup4bB b5eJyes2vH4iTDhlZ7zxXr+/KDUCARtlV+sfeYYbEHjh7nQO5Au6HiRun9bLdmgo 8mNDD/yXmtfCoXVve8p2YQsd2mI7nsqnTlRYYgWXYImvkz3GPOtcvOlYPb/FjW6t pdF4/x77p/YHjnS51rIZvJd5fsh9ZDHi/JUT1O4JWc/rlciZpPtXDv/PzTd22OFz 37rD1NYbk3KPD7VMyXuy =PtXX -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From nobody Thu Jan 29 19:01:02 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4461A88F2 for ; Thu, 29 Jan 2015 19:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 RQ3ZOhs_InkT for ; Thu, 29 Jan 2015 19:00:59 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2411A88F3 for ; Thu, 29 Jan 2015 19:00:59 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so24796846wes.10 for ; Thu, 29 Jan 2015 19:00:57 -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=FmmV8LRjBtgHBXn5Bh7S8Q5I3TH7sxp83vUO9jLie7c=; b=u6zF/A/CTxxQ4FiKg51jlJvgirGNq1bjSjTFw2RbhFONpwJaX5MoGHiJWrRsdfzZd6 niFyv1l0NBUEMSchFcNTutRTvqkNJLjG9lZCAuGh6ZzgcEFv4TvR+9oboBoyN2NkIXKL Cacim2gjHbcR6kK+n6DP/gdEeU0GVu7LDWLVVCTvBGsKQ5prezlQ5dzY/7hSINhOyKpF aRFehU8VAChsBAbRcAaYg0ee6thklcUb7zpg1AIM7xcdr9EBAKBhKFhsIht1oSGDYTTL 5ZA3sn5DoORW2AaipDJ1JEOnp/6bwL2bfyiSOQhsPtBkalQhfOeFyA9XuEv6AFH6IHrq b1UQ== MIME-Version: 1.0 X-Received: by 10.194.90.143 with SMTP id bw15mr7435943wjb.132.1422586857811; Thu, 29 Jan 2015 19:00:57 -0800 (PST) Received: by 10.194.163.194 with HTTP; Thu, 29 Jan 2015 19:00:57 -0800 (PST) Date: Thu, 29 Jan 2015 22:00:57 -0500 Message-ID: From: Daniel Parker To: json@ietf.org Content-Type: multipart/alternative; boundary=047d7bfd01285276b4050dd5d0c3 Archived-At: Subject: [Json] Have there been proposals for xpath-like expressions in json? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2015 03:01:00 -0000 --047d7bfd01285276b4050dd5d0c3 Content-Type: text/plain; charset=UTF-8 Hello everyone, I'm interested in implementing xpath-like expressions for the opensource c++ json library jsoncons . I've seen one proposal, JsonPath , dated 2007. Have there been others? Thank you, Daniel Parker --047d7bfd01285276b4050dd5d0c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

I'm interested in i= mplementing xpath-like expressions for the opensource c++ json library jsoncons. I've se= en one proposal,=C2=A0Js= onPath, dated 2007. Have there been others?

Th= ank you,
Daniel Parker
--047d7bfd01285276b4050dd5d0c3-- From nobody Thu Jan 29 20:16:34 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2D1A8940 for ; Thu, 29 Jan 2015 20:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.614, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s_g4O_XlipK for ; Thu, 29 Jan 2015 20:16:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3101A6F33 for ; Thu, 29 Jan 2015 20:16:29 -0800 (PST) Received: from netb ([89.204.138.242]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LeALI-1Xu8r01IUu-00pwVq; Fri, 30 Jan 2015 05:16:27 +0100 From: Bjoern Hoehrmann To: Daniel Parker Date: Fri, 30 Jan 2015 05:16:26 +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:caNHEvwUSV4o4T5sWlXGn5GMX0a7S7CxTIDRh3KIOEM65Ymz+0F nFpsBVO/mHFqWYhsugaKdscx7nYOdlrm/To2pqAU6PeY7Vn4N1/ZxfoT2OTy0aka+qoOp2d Q7G7+XT5Pzr43JGTt7bBSKIu4uWvxj4Rz66rSf+5gbPak7LK7TwPsXaTFZm5+6/GEiZ0GRG VvRuN6c/1hQ5Xe2DDjF6g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: json@ietf.org Subject: Re: [Json] Have there been proposals for xpath-like expressions in json? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2015 04:16:31 -0000 * Daniel Parker wrote: >I'm interested in implementing xpath-like expressions for the opensource >c++ json library jsoncons . I've >seen one proposal, JsonPath , dated >2007. Have there been others? https://tools.ietf.org/html/rfc6901 -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Thu Jan 29 20:38:52 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7741A8850 for ; Thu, 29 Jan 2015 20:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_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 hIry1UvEnVAD for ; Thu, 29 Jan 2015 20:38:49 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6B1A6FFB for ; Thu, 29 Jan 2015 20:38:49 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 1BD4126405D for ; Thu, 29 Jan 2015 20:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=u8wTNKMWrFzsT/sB4cqG Ra664bU=; b=r0PK1hDBuGU6gfcZ43JoicjuvpVk4s4zVkdaNcJMWpISiDdVF/hv On4pInN8XhKiNuw7+RfNL7q+cT0qVzcvrV3bu22ZYtymSx/T1aJVxqT60Ciwt2V9 zMyedSz7DxaoqTiRccJEot6lECvl+7SNPqWEP3l0XFEpPO2ngfmNpOY= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id EB9E9264059 for ; Thu, 29 Jan 2015 20:38:48 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so423815wib.5 for ; Thu, 29 Jan 2015 20:38:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.20.226 with SMTP id q2mr1069160wie.28.1422592728026; Thu, 29 Jan 2015 20:38:48 -0800 (PST) Received: by 10.216.222.74 with HTTP; Thu, 29 Jan 2015 20:38:47 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Jan 2015 22:38:47 -0600 Message-ID: From: Nico Williams To: Daniel Parker Content-Type: multipart/alternative; boundary=bcaec53d55ed36d434050dd72e41 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Have there been proposals for xpath-like expressions in json? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2015 04:38:50 -0000 --bcaec53d55ed36d434050dd72e41 Content-Type: text/plain; charset=UTF-8 If you're looking for a programming language like XPath/XSLT, I'd recommend looking at jq (https://stedolan.github.io/jq). Nico -- --bcaec53d55ed36d434050dd72e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you're looking for a programming language like XPath/XSLT, I'd r= ecommend looking at jq (https://s= tedolan.github.io/jq).

Nico
--=C2=A0
--bcaec53d55ed36d434050dd72e41-- From nobody Fri Jan 30 03:31:44 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219A81A8BB5 for ; Fri, 30 Jan 2015 03:31:43 -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 eSLBKVCzIYHq for ; Fri, 30 Jan 2015 03:31:41 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4904B1A01F4 for ; Fri, 30 Jan 2015 03:31:41 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 83D6F22E261; Fri, 30 Jan 2015 06:31:39 -0500 (EST) Message-ID: <54CB6B9A.1080801@seantek.com> Date: Fri, 30 Jan 2015 03:31:38 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nico Williams References: <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> In-Reply-To: <20150128230227.GG3110@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rfc-interest@rfc-editor.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jan 2015 11:31:43 -0000 On 1/28/2015 3:02 PM, Nico Williams wrote: >> As a broader useful point (not directed specifically to >> draft-ietf-json-text-sequence-13), I think it would be nice if >> future RFC ABNF can assume that the symbols in RFC 20 for %x00-20 / >> %x7F are rules that can be used as-is. Hence NUL =3D %x00, SUB =3D %x1= A, >> DEL =3D %x7F, etc. > I agree. These should be added to RFC5234 (i.e., we should publish an > update RFC listing them). I would be willing to write up/work on a concise RFC (Internet-Draft)=20 that does this, prior to IETF 92. I would not mind adding a few=20 additional rules to the Core Rules if there is near-unanimous support=20 for such rules. (Hard to think of any in particular, except maybe some=20 generic UTF8 character rules. Last I checked, ABNF is still=20 octet-oriented and US-ASCII focused.) While I would not say "precondition", it is reasonable to require that=20 RFCs after the publication of such an RFC follow it, much like RFCs past = 5234 use RFC 5234 as the basis. Sean From nobody Sat Jan 31 07:13:27 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA001A8942; Sat, 31 Jan 2015 07:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SOK_GGXn-v_f; Sat, 31 Jan 2015 07:13:23 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9E51A8952; Sat, 31 Jan 2015 07:13:23 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5A87122E25F; Sat, 31 Jan 2015 10:13:21 -0500 (EST) Message-ID: <54CCF10C.5060605@seantek.com> Date: Sat, 31 Jan 2015 07:13:16 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <54C29891.6040101@alum.mit.edu> <54C3576A.9030206@greenbytes.de> <54C3BE06.8010707@alum.mit.edu> <54C3C6A3.6080003@seantek.com> <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <54CB6B9A.1080801@seantek.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Nico Williams , rfc-interest@rfc-editor.org, abnf-discuss@ietf.org, "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2015 15:13:25 -0000 On 1/30/2015 3:32 PM, Bjoern Hoehrmann wrote: > * Sean Leonard wrote: >> On 1/28/2015 3:02 PM, Nico Williams wrote: >>>> As a broader useful point (not directed specifically to >>>> draft-ietf-json-text-sequence-13), I think it would be nice if >>>> future RFC ABNF can assume that the symbols in RFC 20 for %x00-20 / >>>> %x7F are rules that can be used as-is. Hence NUL =3D %x00, SUB =3D %= x1A, >>>> DEL =3D %x7F, etc. >>> I agree. These should be added to RFC5234 (i.e., we should publish a= n >>> update RFC listing them). >> I would be willing to write up/work on a concise RFC (Internet-Draft) >> that does this, prior to IETF 92. I would not mind adding a few >> additional rules to the Core Rules if there is near-unanimous support >> for such rules. (Hard to think of any in particular, except maybe some= >> generic UTF8 character rules. Last I checked, ABNF is still >> octet-oriented and US-ASCII focused.) > It is integer-oriented, you have to define the alphabet in prose and ar= e > free to say it's "octets" or "Unicode scalar values" or whatever else. Ok. I was not aware of that, however it is stated clearly enough in RFC=20 5234 Section 2.3. Many specifications use ABNF as octets, and define UTF-8 data in terms=20 of octets. E.g., LDAP [RFC4512]; see "UTFMB". It makes equal sense (in=20 some contexts, perhaps better sense) to use ABNF in integer form for=20 integers 0 - 0x10FFFF, i.e., Unicode scalar values. However those folks who want to define formal import syntaxes will have=20 to grapple with this issue--namely that integer values do not represent=20 the same thing across different specifications. I see this as another=20 reason not to pursue import syntaxes. > I do not think an RFC that updates RFC 5234 just to add names for three= > symbols is a good idea. *Only* the following symbols are being proposed: NUL =3D %d0 SOH =3D %d1 STX =3D %d2 ETX =3D %d3 EOT =3D %d4 ENQ =3D %d5 ACK =3D %d6 BEL =3D %d7 BS =3D %d8 HT =3D %d9 ; also defined as HTAB LF =3D %d10 ; already defined VT =3D %d11 FF =3D %d12 ; (literally used in every RFC) CR =3D %d13 ; already defined SO =3D %d14 SI =3D %d15 DLE =3D %d16 DC1 =3D %d17 DC2 =3D %d18 DC3 =3D %d19 DC4 =3D %d20 NAK =3D %d21 SYN =3D %d22 ETB =3D %d23 CAN =3D %d24 EM =3D %d25 SUB =3D %d26 ESC =3D %d27 FS =3D %d28 GS =3D %d29 RS =3D %d30 US =3D %d31 SP =3D %d32 ; already defined DEL =3D %d127 These are all taken from RFC 20, and (mercifully) have the same symbol=20 names in Unicode. > It's very rare that the particular characters > are useful, NUL is used more often than you (or many others) might care to admit. draft-ietf-json-text-sequence-13 makes use of RS, and that usage is very = appropriate given the engineering problem (that the WG has probably=20 already explored). ESC is used in ANSI escape codes, which form an integral part of a=20 variety of standards (maybe few IETF standards, but ISO and=20 industry-specific standards such as those in the healthcare industry)=20 and are used in modern command-lines and consoles. SO and SI are used in ISO 2022 character sets. There are probably a number of historical examples. > and ordinarily you will have to define other rules on your > own aswell; Well yes, but now you will not need to define as many=20 rules--particularly rules for unprintable characters. I note also that XML 1.0 prohibits C0 control characters except for HT,=20 LF, CR, SP, and DEL. Why the standard prohibits FF and BS, but lets DEL=20 in, is rather mysterious to me. However if you want to represent these=20 characters for their semantics, say, in xml2rfc V3, RS is possible but=20 the actual "0x1E" is a harder sell. XML 1.1 permits all C0 control characters except NUL. Therefore, a XML=20 fragment streaming format akin to draft-ietf-json-text-sequence could=20 easily use NUL to separate records on the wire. > on the software side you would then have ABNF tools that do > not know the new Core rules, I would have to update my Parse::ABNF Perl= > module for instance, "lazy"? :) Laziness is not a valid reason to prohibit new work... For some of these rules (e.g., DC1) perhaps the principal reason to=20 include them in the Core Rules is to discourage future spec writers from = using that rule name to define something else. > and there is the issue that some specifications may > already be using the symbol names, and dealing with clashes with Core > rules is a bit nasty. As with "lazy" there may be clashes with the Core Rules, but that can be = taken as evidence that the Core Rules should have been extended (or=20 defined) earlier--not as evidence to prohibit new work. As it is, if you = use a Core Rule (as draft-josefsson-pkix-textual does), you can't take=20 the reference for granted; the IESG will ask you to reference [RFC5234]. The only spec that I am aware of that would cause problems is LDAP's RFC = 4512, which defines ESC =3D %x5C ("\" backslash). However, RFC 4512 also = proposes a lot of completely unnecessary rule names (NULL, SPACE,=20 DOLLAR, USCORE, EQUALS, DOT), restates at least one Core Rule (DQUOTE),=20 and has a bona-fide conflict with existing Core Rules (SP and WSP).=20 Since RFC 5234 was defined after 4512, this is evidence in support of=20 standardization for future RFCs. Cheers, Sean From nobody Sat Jan 31 11:53:16 2015 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784DA1A1B19; Sat, 31 Jan 2015 11:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mECXN5zrvSf6; Sat, 31 Jan 2015 11:53:13 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D962A1A1B0B; Sat, 31 Jan 2015 11:53:12 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1YHe6J-0003Wi-97; Sat, 31 Jan 2015 14:53:03 -0500 Date: Sat, 31 Jan 2015 14:53:03 -0500 From: John Cowan To: Sean Leonard Message-ID: <20150131195302.GA12839@mercury.ccil.org> References: <54C3CF7F.6090901@seantek.com> <54C4AFF1.6030608@gmx.de> <54C7FAD7.7040500@alum.mit.edu> <54C870B5.7000205@seantek.com> <20150128173229.GC3110@localhost> <54C9632A.2040204@seantek.com> <20150128230227.GG3110@localhost> <54CB6B9A.1080801@seantek.com> <54CCF10C.5060605@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CCF10C.5060605@seantek.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Nico Williams , rfc-interest@rfc-editor.org, Bjoern Hoehrmann , abnf-discuss@ietf.org, "json@ietf.org" Subject: Re: [Json] [rfc-i] v3imp #8 Fragment tagging on sourcecode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 31 Jan 2015 19:53:14 -0000 Sean Leonard scripsit: > I note also that XML 1.0 prohibits C0 control characters except for > HT, LF, CR, SP, and DEL. Why the standard prohibits FF and BS, but > lets DEL in, is rather mysterious to me. Carelessness, basically. > XML 1.1 permits all C0 control characters except NUL. Therefore, a > XML fragment streaming format akin to draft-ietf-json-text-sequence > could easily use NUL to separate records on the wire. XML 1.1 (says the one who initiated its development and fought for it) is dead, and in fact died a-borning. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org They tried to pierce your heart with a Morgul-knife that remains in the wound. If they had succeeded, you would become a wraith under the domination of the Dark Lord. --Gandalf