From nobody Thu Oct 1 11:54: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 D92671A8845 for ; Thu, 1 Oct 2015 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Volj_FJSLCad for ; Thu, 1 Oct 2015 11:54:14 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 EB9261A8844 for ; Thu, 1 Oct 2015 11:54:13 -0700 (PDT) Received: by igbni9 with SMTP id ni9so1503581igb.0 for ; Thu, 01 Oct 2015 11:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3CzAeDzJtVCPqOd9fj/HCaASAgiVl/IgzLaihVZP/hc=; b=jt823THJ2ZJjLA20FDP+uSypDXL0TBzZiz0SEuDqUdMeAMBekdzwa6CYq23kU8OOXk eDhCCwGpBgwtIjgKBA+aDXh5/V9Za+si9iSEnGDzJq/tPgk81jcJkvhxQWpH28mdy+k7 NEXXzum7PRtw/J5mA5IvMVD61DE0bY174I7bcaRNwJRlODGBAk9+MxYaEyA0ginBGqtf bc5+OXoOC6wz41FLsG+36TWDif4V/YdgsrwuHp9Au3IGFVwHvsfq2A/rjUUYCQlPo6hA NEOLqAvZeFfhfY2VWRvUk6tWpcWAGx3Qsqh4pzfR9V6eq57V+7O0oqxdmMcwdlGoVsGd CnIw== MIME-Version: 1.0 X-Received: by 10.50.83.6 with SMTP id m6mr450637igy.90.1443725653322; Thu, 01 Oct 2015 11:54:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.17.24 with HTTP; Thu, 1 Oct 2015 11:54:13 -0700 (PDT) In-Reply-To: <560C8C12.2010805@gmail.com> References: <560C8C12.2010805@gmail.com> Date: Thu, 1 Oct 2015 14:54:13 -0400 X-Google-Sender-Auth: UaRDmrq_KP85iRT19OmMa1o2XvM Message-ID: From: Barry Leiba To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 Oct 2015 18:54:15 -0000 > I must admit that I am puzzled as to how ECMA-404 can be a normative > reference for any document that is a minor change from rfc7159. What in > ECMA-404 is needed to understand or implement what is in rfc7159? Rob has it nailed in his message: "To me, it seems like a political or diplomatic gesture that helps the Internet to move forward. "Framing it in technical or standards-wonk terms seems counterproductive. I don't think there are substantive issues in those areas that would be resolved by objecting to the plan in the charter." That really is the point: tying the two documents together more tight, to make people more comfortable that they are not likely (certainly not intended) to diverge later. > As has been stated, rfc7159 already references ECMA-404. A conservative way > to make a closer connection from rfc7159 to ECMA-404 would be to state that > ECMA-404 has an alternative description of JSON that is extremely close to > the definition in rfc7159. Such a statement would, indeed, be an excellent one to put into 7159bis. Barry, responsible AD From nobody Thu Oct 1 13: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 B2FF61A88E3 for ; Thu, 1 Oct 2015 13:47:53 -0700 (PDT) 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 8BuhvBXQpyIz for ; Thu, 1 Oct 2015 13:47:52 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 1D0A51A88EF for ; Thu, 1 Oct 2015 13:47:48 -0700 (PDT) Received: by ioii196 with SMTP id i196so99446322ioi.3 for ; Thu, 01 Oct 2015 13:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ELkyJpRkfNIV1kSiRnTWsCOaR2xmiY835xdFEcCJUS0=; b=R/54aCMY7JQ5iS0tb8E4cOeKVdL3mrIW/Sg/8YDFUPxeAMf/fd+1RcpuAxSbBYGHCu UIUMvVl510gcuSMSawBz9ay26dLadLDij4l5i/oa6EcO9BteWYQH5PWhsA7Ny0r4YzP1 9D/49KjWn55P2BgCEd8MFAEHeVg2ZiEkQkOPnjekIvpXdEf84LBy13jz3Yi7VUN/UHd3 gw95lM2f31Z0V+hJ9i6D69DGkn6ym6scliLqqlh+3t5gikm0dOija85vi0ORNH0SQS1n Lj5mJ3+vpFqTlGRb0WQh/0X8beMyGLuSRlYNcSBdz95aJ1qqJyR3U8+JgOCBjt8rNxPG KL1w== X-Received: by 10.107.138.213 with SMTP id c82mr13088200ioj.179.1443732467547; Thu, 01 Oct 2015 13:47:47 -0700 (PDT) Received: from idefix.nuance.com ([184.151.36.114]) by smtp.gmail.com with ESMTPSA id l2sm2101325igv.11.2015.10.01.13.47.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 13:47:46 -0700 (PDT) To: Barry Leiba References: <560C8C12.2010805@gmail.com> From: "Peter F. Patel-Schneider" X-Enigmail-Draft-Status: N1110 Message-ID: <560D9BF0.9050504@gmail.com> Date: Thu, 1 Oct 2015 13:47:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 Oct 2015 20:47:53 -0000 On 10/01/2015 11:54 AM, Barry Leiba wrote: >> I must admit that I am puzzled as to how ECMA-404 can be a normative >> reference for any document that is a minor change from rfc7159. What in >> ECMA-404 is needed to understand or implement what is in rfc7159? > > Rob has it nailed in his message: > "To me, it seems like a political or diplomatic gesture that helps the > Internet to move forward. > > "Framing it in technical or standards-wonk terms seems counterproductive. > I don't think there are substantive issues in those areas that would be > resolved by objecting to the plan in the charter." > > That really is the point: tying the two documents together more tight, > to make people more comfortable that they are not likely (certainly > not intended) to further (?) > diverge later. > >> As has been stated, rfc7159 already references ECMA-404. A conservative way >> to make a closer connection from rfc7159 to ECMA-404 would be to state that >> ECMA-404 has an alternative description of JSON that is extremely close to >> the definition in rfc7159. > > Such a statement would, indeed, be an excellent one to put into 7159bis. > > Barry, responsible AD > peter From nobody Tue Oct 6 23:16: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 412681A92E7 for ; Tue, 6 Oct 2015 23:16:37 -0700 (PDT) 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 vNBqbstPrOzZ for ; Tue, 6 Oct 2015 23:16:35 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 657841ACDE7 for ; Tue, 6 Oct 2015 23:16:35 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so12546257wic.0 for ; Tue, 06 Oct 2015 23:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=PX4MynJJNncuf/f1VWM8qm6LTwcfDcMCCXTCAMocdSI=; b=At4egBsj4uObQQOEU2FwJkU9ygFVbZnj5rQ44a14WVbWENnPu0IOWQtUjm7x9VsQ6D xmf7Dlxwq2BqnqqTPd0bTRgo+VSD8kEcOPzctji0powv2Xj5End8z+iFT80Yg4EBck9J njeMBpKMsxcoC7ZbLiYv3tCKVNgPpw6gdd5FOSOK46SGsVmt3F47SSe+PP/gc181Jwl6 d44YuKh7J6hdPaA9iZgmcckgt98Sq7Hdh7wMJqsXyl6ZbNjHXYFhjRE9XDsyBJJq0r0c +1mX7++Qdabo0pzEMEQUZVcR6BimGhIVWeUVdsCjg0IK3myYJRLpj5jJ5oBLyLfXMfyP tWew== X-Received: by 10.180.102.195 with SMTP id fq3mr22042964wib.7.1444198594019; Tue, 06 Oct 2015 23:16:34 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id i10sm36900170wjz.41.2015.10.06.23.16.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2015 23:16:32 -0700 (PDT) To: json@ietf.org From: Anders Rundgren Message-ID: <5614B8B9.2050405@gmail.com> Date: Wed, 7 Oct 2015 08:16:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] A Crypto-compliant JSON Implementation X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Oct 2015 06:16:37 -0000 A Crypto-compliant JSON Implementation ================================== Although maybe not a topic for the IETF, I would anyway like (for those who don't follow the JOSE list) to describe a JSON implementation which enables "Signed JSON". Didn't the JOSE WG just finished that? No, the JOSE WG have rather created a set of JSON-flavored and URL-friendly cryptographic containers where the actual data has no relation to JSON ; the data is Base64URL-encoded to be neutral to the content. Anyway, for me working payment systems and similar where signed JSON messages are wrapped by other signed JSON messages like "Russian dolls", Base64 simply wasn't an option: http://xmlns.webpki.org/webpay/v1/webpay-card-payment-messages.html#p11 How much did I have to "violate" the JSON specification to accomplish this? Not a single bit. What I did was simply parsing properties using LinkedHashMap (to maintain a predictive order) plus a minute fix for numbers keeping the original textual representation in the background for serialization. This also has the benefit that properties are serialized in the same order as they were created which is a feature often requested by the JSON community at large which isn't too surprising since XML elements, EDI, ASN.1, and plain-text always had this quality. Anders https://mobilepki.org/jcs From nobody Tue Oct 13 07:03: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 5C1B21B417E for ; Tue, 13 Oct 2015 07:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WPvQbi5q0aP for ; Tue, 13 Oct 2015 07:03:32 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 552E81B4178 for ; Tue, 13 Oct 2015 07:03:32 -0700 (PDT) Received: by igcpe7 with SMTP id pe7so16549229igc.0 for ; Tue, 13 Oct 2015 07:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VLKW0lOwBQp1pgir/P8o6Vfv4t53USZHLrlQ0lyeqvM=; b=YKxp66CeOfQBv/wAKxUk9pkB+6+DE6RQrZ8GwwiZgg/CWG6NfkVxtEkJLwDDIPYECk 0EKS3eFdPHbQA9PgzNvMT6lejnaSDSlSBKPJ8rHzjWjfeYa0v0MyYrsrNgY0ZdAo/kmd vXhvOmffZFcon9P8IkOJDhJ7b0NfRQ184pX6Q0yEJ5LebKVOwpmu1TtUq47wa1824TO6 WoC9KGOzMP9LrpCz8faU7n/R23p7te3aKAt1+4fqosLLZ031voivz0IOyhF9UfW5LrfY JlGEe/ysdmYaA+5Vmp9fkqC2l2XgpXXme/P8sEZKGO65bEi3SOzEZvCKoYSdIgcEzFj+ VfjQ== MIME-Version: 1.0 X-Received: by 10.50.79.230 with SMTP id m6mr20081960igx.9.1444745011709; Tue, 13 Oct 2015 07:03:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.15.105 with HTTP; Tue, 13 Oct 2015 07:03:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2015 07:03:31 -0700 X-Google-Sender-Auth: jZb6ugmhyXQXpfnPceQWERjp8O0 Message-ID: From: Barry Leiba To: "Matt Miller (mamille2)" , Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 13 Oct 2015 14:03:33 -0000 > In a nutshell, the goal of this effort is to produce a bis to 7159 that: > > * promotes JSON to IETF Internet Standard > * references ECMA-404 and is a reference for ECMA-404 > > Tim Bray has agreed to edit 7159bis. > > As a start, I propose we start with rfc7159 and: > > 1) Apply verified errata from < https://www.rfc-editor.org/errata_search.php?rfc=7159 > > 2) Change the reference to ECMA-404 from informative to normative Can we get a first version of this before the I-D cutoff for Yoko (this coming Monday, 19 Oct)? Barry From nobody Tue Oct 13 21:03: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 9C42D1A21B8 for ; Tue, 13 Oct 2015 21:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz4bYBYDKEgj for ; Tue, 13 Oct 2015 21:03:11 -0700 (PDT) Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) (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 CF63E1B2AFE for ; Tue, 13 Oct 2015 21:03:10 -0700 (PDT) Received: by vkat63 with SMTP id t63so22914408vka.1 for ; Tue, 13 Oct 2015 21:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=x4UDe570tFHh6gaxA7kpCNZqQPEU8QbBPbGiH1HjCus=; b=fN+9crGYiawZGX/1aueRTAvx+jj6q2biZeTB2GoD17Ipyv11O/0vinha/hsY74AXyQ OaQBxTK7jZjeUwh4yF4t1rnPDcpesgarz3Y80KCxYornrubyaPbuUouY+ZrzRSSbfp1Y FR7qSXXIGeRsDiEi+MUPItkaM7QdcLXh0BKcWmPy48ch7lDV2TdfFIuwGJqQdjzDzDgT q5JVBJAD8hrORSPd9JjTLiqizbHlVFPbdMhvopSF5UDEW+UUBNcPdEVoR4Gu89rf08gc ql8mRCZ9QgYYCqArn4dwH1jX/uoRp3K24d2KTWVlVI4o1EUEHNzLDxLo6Buv0BaDDi/I wnFw== X-Gm-Message-State: ALoCoQmarLwFJlDNh99h7+jyRgcHGhsubkjwkceSMdBvXV3fjEEDlvyFnBjfHgMw+B7Aik6uTHWi X-Received: by 10.31.190.6 with SMTP id o6mr627922vkf.120.1444795389756; Tue, 13 Oct 2015 21:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.162.79 with HTTP; Tue, 13 Oct 2015 21:02:50 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: From: Tim Bray Date: Tue, 13 Oct 2015 21:02:50 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c019c0faeb9f052208a33f Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 04:03:12 -0000 --001a11c019c0faeb9f052208a33f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure, but isn=E2=80=99t a consensus call on the substantive change to the s= pec in order? On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba wrote: > > In a nutshell, the goal of this effort is to produce a bis to 7159 that= : > > > > * promotes JSON to IETF Internet Standard > > * references ECMA-404 and is a reference for ECMA-404 > > > > Tim Bray has agreed to edit 7159bis. > > > > As a start, I propose we start with rfc7159 and: > > > > 1) Apply verified errata from < > https://www.rfc-editor.org/errata_search.php?rfc=3D7159 > > > 2) Change the reference to ECMA-404 from informative to normative > > Can we get a first version of this before the I-D cutoff for Yoko > (this coming Monday, 19 Oct)? > > Barry > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c019c0faeb9f052208a33f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sur= e, but isn=E2=80=99t a consensus call on the substantive change to the spec= in order?

On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba <barryleiba@comput= er.org> wrote:
> In a nutshell, the goal of this effort is to produce a bis to 71= 59 that:
>
> * promotes JSON to IETF Internet Standard
> * references ECMA-404 and is a reference for ECMA-404
>
> Tim Bray has agreed to edit 7159bis.
>
> As a start, I propose we start with rfc7159 and:
>
> 1) Apply verified errata from < https= ://www.rfc-editor.org/errata_search.php?rfc=3D7159 >
> 2) Change the reference to ECMA-404 from informative to normative

Can we get a first version of this before the I-D cutoff for Yoko (this coming Monday, 19 Oct)?

Barry



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--001a11c019c0faeb9f052208a33f-- From nobody Tue Oct 13 21:22: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 13FEE1B2B26 for ; Tue, 13 Oct 2015 21:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3MKoUzSvMq6 for ; Tue, 13 Oct 2015 21:22:30 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 B034E1B2B24 for ; Tue, 13 Oct 2015 21:22:30 -0700 (PDT) Received: by vkha6 with SMTP id a6so22986275vkh.2 for ; Tue, 13 Oct 2015 21:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1hdd5zZU92PG4M+o0UEDEQwxG4iQhSTQzXCiDFapatI=; b=vWiqw7wzuoRVqX7E6ZhTiuyaqy5s5vvucRTYcII1zhXEh3B5mx/NXoDxS+jgbSxB94 bSmxSwWSmbUizTzK0QOikW32sy2vd/aN1b0q5xeMHi5jKQHD0iac9I/7COXxYo0k6YHv ZyRhdkARhaxPkWt1wyVdHULpDKMoElru47zMWytEy18aECb3bcTIOW4DsrSXb//euyyM VeuoztPhNWYW8AV5ueTxQswgOeujTBlrVrtu0LxQ0DfDY6D7E0OhzXeAHGVwm7P4SKVk H3htT5CCgTGHHdAaI4uyE4/UeK7rsjQxno+xUtE+pWixYXJYBsp+f59o6+b8PyCywTNf hj4A== MIME-Version: 1.0 X-Received: by 10.31.192.9 with SMTP id q9mr611482vkf.63.1444796549935; Tue, 13 Oct 2015 21:22:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Tue, 13 Oct 2015 21:22:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Oct 2015 00:22:29 -0400 X-Google-Sender-Auth: PuiejzSsY7ECJYctk235DEau7BM Message-ID: From: Barry Leiba To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 04:22:32 -0000 >> > In a nutshell, the goal of this effort is to produce a bis to 7159 tha= t: >> > >> > * promotes JSON to IETF Internet Standard >> > * references ECMA-404 and is a reference for ECMA-404 >> > >> > Tim Bray has agreed to edit 7159bis. >> > >> > As a start, I propose we start with rfc7159 and: >> > >> > 1) Apply verified errata from < >> > https://www.rfc-editor.org/errata_search.php?rfc=3D7159 >> > 2) Change the reference to ECMA-404 from informative to normative >> >> Can we get a first version of this before the I-D cutoff for Yoko >> (this coming Monday, 19 Oct)? > > Sure, but isn=E2=80=99t a consensus call on the substantive change to the= spec in > order? That could be done by posting an I-D to make the proposal, and have the working group review it and comment on it. Right now, there's just a "here's what we plan to do", and there've been a few comments about that. Specific text to review might help, no? Barry From nobody Tue Oct 13 22:39: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 9C1401B2B8D for ; Tue, 13 Oct 2015 22:39:54 -0700 (PDT) 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 CtZ6sOkPFn_0 for ; Tue, 13 Oct 2015 22:39:53 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 07F741B2B8C for ; Tue, 13 Oct 2015 22:39:53 -0700 (PDT) Received: by wicge5 with SMTP id ge5so85079307wic.0 for ; Tue, 13 Oct 2015 22:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mz0FRJFTPshBuFK3PtAniGSP0vGDIhzjEoybJYu6RX4=; b=vhCSP2QjKuLAvJaoHSN/295BLpG8TS2iEO1s0uoe48ckQuA0kwWRAPLOjzXlsgr4zB gaTGFdyJnO353fj1l9SeRsUFXDipH6Q6XITDjfzbm3Zc17pD7atZA24i1ZzEz/kDKsMH mUxUzdwIqbA1X1mLFk+iCbeUmFWq0LwOxpf/qFLHOnC8EMPcQY+zrG+wpul9tcHPbuMU bSZfct5+h1XTWAy/pBbQ5niGoipw897h7iNSk+9P5nfr8I39+8dp72yQvGnPmDsNy2q5 tu7/07hdueXD/Hk0lyMe9TRcv9hFyuStc8tnLnmzMY2Yn7S55mdn+z1U0nune+4D8Coc ySXw== X-Received: by 10.180.207.235 with SMTP id lz11mr2061292wic.1.1444801191407; Tue, 13 Oct 2015 22:39:51 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id o3sm17693378wif.22.2015.10.13.22.39.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Oct 2015 22:39:50 -0700 (PDT) To: Barry Leiba , Tim Bray References: From: Anders Rundgren Message-ID: <561DEA9F.3070605@gmail.com> Date: Wed, 14 Oct 2015 07:39:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 05:39:54 -0000 I'm obviously "somewhat" biased but how about evaluating my proposal which addresses two entirely different topics: - The ability to sign JSON objects in a way that mimics XML DSig but without bringing in a complex canonicalization scheme - Predictive serialization which most developers are likely to appreciate Note: There's no need defining a specific signature scheme, it is enough creating a foundation for such work. https://mailarchive.ietf.org/arch/msg/json/wfyXZ6mzDwQqVMUw-UT_-L1fhQU JWS will be a hard sell to the business community who are slowly but surely converting from XML and EDI to JSON. They shouldn't have to develop their own JSON standards! Cheers, Anders Rundgren From nobody Wed Oct 14 01:36: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 42FB31B2C67 for ; Wed, 14 Oct 2015 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xE7-ZCT7cD34 for ; Wed, 14 Oct 2015 01:36:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 C9B7E1B2C45 for ; Wed, 14 Oct 2015 01:36:13 -0700 (PDT) Received: from [10.59.6.129] ([37.152.95.96]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Likl3-1aIbUM1xyX-00cwre; Wed, 14 Oct 2015 10:36:08 +0200 To: Tim Bray , Barry Leiba References: From: Julian Reschke Message-ID: <561E079D.9090908@gmx.de> Date: Wed, 14 Oct 2015 09:43:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:IwlaqS2+rg4pu4zEzf7O735b3D2zABg0uUfzx3EMwqssQ5WqMTR 6nLwNNAZRiuBUgIXC5vG+q8OAZSi+Nd9ERHqcBA+ev9+eFYCSV+3ycFbGAIytvpvqmDA4nN OG9B3Zq47jdDNRhznzPDItRxlgjcz/YrCc5k1P3becoJ2Jq4S87zBQpa2JE742lk9UiK9oX h6GuGpz+XYSthq03BrlBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GKTy7Iwi0M0=:O8kAieAuDIY+FDtKkIYkaW ekR6GW9Pa4LEgRUhJjDNZlk3758YS6rVIERmrE5mNm9z34sM0Zq8E1GaufG0nVZDnssi0OnK9 30rBpD/nU/ghjCewCIK/Rviw3xqC1UPPqAQYRWt32veAlW7aSmqRyevudZpZrqFCCVKqcbdIE j/IO7lMUceR4HK5WFGrOd3BaTo2xCtMDxc0qdnpxekuVHifMye9DXpdrnmzTu+zA18QSfgB/G FcL1T2tChtOCZDoUne5iCVv5cVJ+FhWK5SxmNOurU0V9BCKlpi4ya4m4RtclXGn+8ruxEkzLj RM6jOIzLNnSjRPyTPPOQh++ACIgeQ1u1dxxniG2zlxoBOtPZKLwp6KaKoYFkn59vDxQvAS47j dwhLTQmMZMITvG6RQqCf0A9b4XWM7jjfezXJ8PEGvYuGlNdWLYBl5i+6e2Y8kzTsEKEAoZK/q F5/RZP+4UMWp5e6ZnG2m/lAw3C23EHOtK/j5ZZG5Oy7JNctuNrnoE3OZ+2XhDxbxPX5kjRASh c8r7PJHFXZ3oWMj7n7ZJun+fl0XfgyXzmP687V9bahLuZlnkkttuxpqzEssgwU44OAVOWVORH mJyThdW/B6YxUDfbUmjP0OlPWLdN8HT5EKtHtdb84C8eYXkuqZhqspqIfg5qjPChdrqGoWlpA Vm0t5nUY13ZyNGuWCvjMMxLOOuUTn8Et6F2EeaXsPy8954dLevZ3Qna/rFC5gRu61dJZ8e3Rw o9B5OtRiPJBVhC7Q/PQC/ncWCteJ6VLivfJxapr70r+Rss+wg33egitLsj2Bf94UVCKu//DUn wJ0LjOM Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 08:36:15 -0000 On 2015-10-14 06:02, Tim Bray wrote: > Sure, but isn’t a consensus call on the substantive change to the spec > in order? Right. As far as I recall, there was little (or no?) support for the reference change. I believe we should discuss it here *before* making a change in the draft. Best regards, Julian From nobody Wed Oct 14 08:26: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 43C851AC419 for ; Wed, 14 Oct 2015 08:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 tO1N65VdMT2f for ; Wed, 14 Oct 2015 08:26:47 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97541AC3BB for ; Wed, 14 Oct 2015 08:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1964; q=dns/txt; s=iport; t=1444836406; x=1446046006; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=357ZnHGxOCiGViRi603ljOTBZQidi5fI0HsD5TvbVmk=; b=VkXi8rBqGbHx67f19GlvdGIIZyXfede7Nh2VsiznRerabZTNFUPwZCE9 7IX7dFijWMpaQ7aTgZp3Twi2ALi3lqfQSCwdkGrk3ICG7J4uKsOgvNne0 R9bUh2EfDah5J3EBbyR6dB5fnQGWYuRDAJP1lOLmdsBDcrbOYm9vdBsD6 M=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BDAwAXcx5W/4oNJK1egyZUbga9Hg6BWiGCcoIKfwKBQzgUAQEBAQEBAYEKhCcBAQR5EAIBCBguIRElAgQOBQ4GiAUDEg2+Gg2EeQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiQaCboJQgj0HgxqBFAEElVVAAYJNgWFqhg6BdJRBh0gBHwFDhAJxAYVogQYBAQE X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="asc'?scan'208";a="197960219" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 14 Oct 2015 15:26:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9EFQjNo013166 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 15:26:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 10:26:32 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 10:26:32 -0500 From: "Matt Miller (mamille2)" To: Anders Rundgren Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHQ+wFNtMRdQTHPQkS2mYrhXeCPSJ5p3bCAgADZvgCAAAV9gIAAFZSAgAC0xAA= Date: Wed, 14 Oct 2015 15:26:31 +0000 Message-ID: <7616CE83-5A46-4248-B784-FFEEBE83C818@cisco.com> References: <561DEA9F.3070605@gmail.com> In-Reply-To: <561DEA9F.3070605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.101.72.85] Content-Type: multipart/signed; boundary="Apple-Mail=_4A8763E5-29B1-4E41-90B6-AD9E47970FC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 15:26:50 -0000 --Apple-Mail=_4A8763E5-29B1-4E41-90B6-AD9E47970FC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 13, 2015, at 23:39, Anders Rundgren = wrote: >=20 > I'm obviously "somewhat" biased but how about evaluating my proposal = which addresses > two entirely different topics: >=20 > - The ability to sign JSON objects in a way that mimics XML DSig but = without bringing > in a complex canonicalization scheme > - Predictive serialization which most developers are likely to = appreciate >=20 > Note: There's no need defining a specific signature scheme, it is = enough creating a > foundation for such work. >=20 > https://mailarchive.ietf.org/arch/msg/json/wfyXZ6mzDwQqVMUw-UT_-L1fhQU >=20 > JWS will be a hard sell to the business community who are slowly but = surely converting > from XML and EDI to JSON. They shouldn't have to develop their own = JSON standards! >=20 The WG's charter is very constrained, and these are not in scope. -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_4A8763E5-29B1-4E41-90B6-AD9E47970FC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWHnQzAAoJEDWi+S0W7cO1euIH/2pTuEHqd+K4SdwMA2vo3kEJ Tdf6v3Vzg+HCkgOd2Xw1/3rUSarEQyrVYEQY3aE2ShCoCxC8JxlwJKYUHWeBWb1H hK88e+1qn6JuxHLDNg8eyBCCCx49ocd7qC4596VEu3LxhkZ5v8akjqBW4eL/5GWS G2ybtmjtVJE0gNhx13WIHPKX/HzpmqDaubwRFVEgMvaPldVpA9zxwm6o2Mv82itI KG4kSl2vp8+4yg1N8HnPsilGcCUZCxnBvpxF0XBCpha/R5c+FA+oidjuqqE5FQqD Y9/Q7/i6gS/7nO6uHeHwZ84+075j435JnHqFIfB+DoTvaZGzceq1WLYvbgQiyLo= =JvE7 -----END PGP SIGNATURE----- --Apple-Mail=_4A8763E5-29B1-4E41-90B6-AD9E47970FC9-- From nobody Wed Oct 14 08:37:58 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 703271ACC72 for ; Wed, 14 Oct 2015 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 G4-DJoeIntQ9 for ; Wed, 14 Oct 2015 08:37:56 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2A71AC529 for ; Wed, 14 Oct 2015 08:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1444837075; x=1446046675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9ni8Yk2EoPcCmAq1s11+aMrvoF5E9XNTbAeR/k7PbvE=; b=k7dnc9x4Zwx898lpoCDzS5CoHIufLWfPJOGf4y3spM7bUD8yvHx7SYvQ AOF7G3dTU6wFvC5QyA3NLxUyWy4/qk3U/5AX9CvFLXeIqiq2aCXSMLPtM +B/4hNZTMp+DbWt86fMKQ7C5ckKIocl2DDVMzyI7pXgiNXo53iVU/pljx Q=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BDAwB1dh5W/4oNJK1EGoMmVG4GvR4OgVohgnKCCn8CgUM4FAEBAQEBAQGBCoQmAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IGAgNO68nk0IBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIkGgm6FDQeCaTGBFAWWFQGCTYFhg1qFEpwJAR8BQ4IRHYFUcQGFaIEGAQEB X-IronPort-AV: E=Sophos;i="5.17,681,1437436800"; d="asc'?scan'208";a="197436781" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2015 15:37:55 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9EFbta8022038 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2015 15:37:55 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 14 Oct 2015 10:37:41 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Wed, 14 Oct 2015 10:37:40 -0500 From: "Matt Miller (mamille2)" To: Barry Leiba Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHQ+wFNtMRdQTHPQkS2mYrhXeCPSJ5p3bCAgADZvgCAAAV9gIAAzXcA Date: Wed, 14 Oct 2015 15:37:40 +0000 Message-ID: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.101.72.85] Content-Type: multipart/signed; boundary="Apple-Mail=_1A39A3C2-025C-4700-ABBD-BA0602BC4D3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 15:37:57 -0000 --Apple-Mail=_1A39A3C2-025C-4700-ABBD-BA0602BC4D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 13, 2015, at 22:22, Barry Leiba = wrote: >=20 >>>> In a nutshell, the goal of this effort is to produce a bis to 7159 = that: >>>>=20 >>>> * promotes JSON to IETF Internet Standard >>>> * references ECMA-404 and is a reference for ECMA-404 >>>>=20 >>>> Tim Bray has agreed to edit 7159bis. >>>>=20 >>>> As a start, I propose we start with rfc7159 and: >>>>=20 >>>> 1) Apply verified errata from < >>>> https://www.rfc-editor.org/errata_search.php?rfc=3D7159 >>>> 2) Change the reference to ECMA-404 from informative to normative >>>=20 >>> Can we get a first version of this before the I-D cutoff for Yoko >>> (this coming Monday, 19 Oct)? >>=20 >> Sure, but isn=E2=80=99t a consensus call on the substantive change to = the spec in >> order? >=20 > That could be done by posting an I-D to make the proposal, and have > the working group review it and comment on it. Right now, there's > just a "here's what we plan to do", and there've been a few comments > about that. Specific text to review might help, no? >=20 > Barry RFC 7159 has the following verified errata: * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4264 * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4336 I suggest at the least an I-D be published that applies these. -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_1A39A3C2-025C-4700-ABBD-BA0602BC4D3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWHnbRAAoJEDWi+S0W7cO1CxQIAJhKc9ACCk9A9uZn2oZMwrnY 0nf/QEWjUoJ2IC5jkJC9GxOKI1iMwcS7umd6u198cQ8siSBXxf9D10p9upG9gHIP QZwGhsm3phF5flPfnSPHuu9GW1Csm3Z9FfwreUsLaOHBmGBNHi0N3Z06BHvMRFmV UN7hHQX851PnZ+FEgAMtiQmlLX/slCAo7hUm2hkzffNRM/gKG4B23uSGG1P5jKa5 zbeRiC0SaZsOHtQdWBYDA/p9XNgFjj3HRln710rl5TajESB6HGLTsJYUCpXpscTQ Tt5kKG7EFrkejLgrVcBzmBTBr1Zxl7vCyPhgA/S6W1xWdsb26yLAz27QvvnJ65A= =w5kp -----END PGP SIGNATURE----- --Apple-Mail=_1A39A3C2-025C-4700-ABBD-BA0602BC4D3F-- From nobody Wed Oct 14 09:10: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 14AD31ACD52 for ; Wed, 14 Oct 2015 09:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWjQCfDn3htJ for ; Wed, 14 Oct 2015 09:10:14 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 871191ACD65 for ; Wed, 14 Oct 2015 09:10:02 -0700 (PDT) Received: by vkha6 with SMTP id a6so32546470vkh.2 for ; Wed, 14 Oct 2015 09:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qBwvS42l3yXLHOXB8AV5p1Cdzul5XzHU+IUgdGJn19E=; b=Qmunub4EWZRXsJSUsv6yPhhzo2fK0+aHI/9pox4/CxdAKHCN7OAllxhtzml+pB4BJN GCM8VsBZyGAA0LU+RErFemk0LdTq6Dc9seUsOAFCyu0wZaDw0VH5haOQUy9tYQ/9vdb0 eZyEpO7hQ+ogF3k0+OE3dqo2nv2IANXsLhto6ZiGAsXc0GJD6AEfRU/H8ALu9QkjE5Et si4lkCZdTfOxzAP8Z/MwMaiQC3lJBkENeohLIvj60q1y0L2i57nWdZFeU43jmjJvfqmq 2YqWvcVhgFJCeEWnrvMpqhuWPnw9c4CsfArnIbc75IglgWgA/ibIH2Oo9l3eL+1Q1fKu lzSg== MIME-Version: 1.0 X-Received: by 10.31.192.9 with SMTP id q9mr2272358vkf.63.1444839001745; Wed, 14 Oct 2015 09:10:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Wed, 14 Oct 2015 09:10:01 -0700 (PDT) In-Reply-To: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> Date: Wed, 14 Oct 2015 12:10:01 -0400 X-Google-Sender-Auth: QY-27YRMU2q5fyZWXOXT7Ut8lWo Message-ID: From: Barry Leiba To: "Matt Miller (mamille2)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Oct 2015 16:10:15 -0000 >>> Sure, but isn=E2=80=99t a consensus call on the substantive change to t= he spec in >>> order? >> >> That could be done by posting an I-D to make the proposal, and have >> the working group review it and comment on it. Right now, there's >> just a "here's what we plan to do", and there've been a few comments >> about that. Specific text to review might help, no? > > RFC 7159 has the following verified errata: > > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4264 > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4336 > > I suggest at the least an I-D be published that applies these. That works for me. As to the other, specific text proposed on the list will give people something to discuss. Barry From nobody Sun Oct 18 11:05: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 8A3631ACC7F for ; Sun, 18 Oct 2015 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqEAurZiz9T7 for ; Sun, 18 Oct 2015 11:05:36 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (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 D4DAF1AC82C for ; Sun, 18 Oct 2015 11:05:35 -0700 (PDT) Received: by iow1 with SMTP id 1so169119234iow.1 for ; Sun, 18 Oct 2015 11:05:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cyNK/HnwriH3MKrCJX9B8e5PBUEiFrn0dzkSarqhfu8=; b=BL+avsBcjRztinHPItF4d17PJMQFXKbYfVq8/caBb39iGAshiNcsaF6rIj1ICA6ofw 7AozGZxurVw+mL9FCRXxT1oGhrb5Z6eckyqZIO+KnB97UPg0Z/frZREGP0x0NnTGZHJL 4nWl578IfQPUA+i7PZZuzPrJ7zUbXqNdVBW3U6AF13uOTX6A/2n2/g2kHXIt6NjW+/hM OUWZzrCblVzYEMgbAfnm0aNVqAvKn1MoVJO4psAYDE5BHB6CZRRvaqNp3WlEgZTC3Bbm 6ZnAKy31z6ollGFU/UkmMbL2eHdOAR4WMKe9R+vVKDsvrYsGCOv60ViSU4alkaBcSZ0n duEQ== X-Gm-Message-State: ALoCoQnhr4CUPtsP4sp+NfHIwtqd1zZhrs7zv38uyX9HJcq6OTpE6YTVzb9daDUXax5Ddes7Oc4R X-Received: by 10.107.163.204 with SMTP id m195mr27066999ioe.65.1445191535131; Sun, 18 Oct 2015 11:05:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.30.4 with HTTP; Sun, 18 Oct 2015 11:05:15 -0700 (PDT) X-Originating-IP: [209.52.88.169] In-Reply-To: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> From: Tim Bray Date: Sun, 18 Oct 2015 11:05:15 -0700 Message-ID: To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=001a1140fb701598fc052264e0b5 Archived-At: Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 18:05:37 -0000 --001a1140fb701598fc052264e0b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the off-chance anyone is listening: The second erratum is a correction to a couple of errata references. But I'd have thought that 7159bis should really only have references to errata post-7159. Pardon the extreme editorial wonkery. On Wed, Oct 14, 2015 at 8:37 AM, Matt Miller (mamille2) wrote: > > On Oct 13, 2015, at 22:22, Barry Leiba wrote: > > > >>>> In a nutshell, the goal of this effort is to produce a bis to 7159 > that: > >>>> > >>>> * promotes JSON to IETF Internet Standard > >>>> * references ECMA-404 and is a reference for ECMA-404 > >>>> > >>>> Tim Bray has agreed to edit 7159bis. > >>>> > >>>> As a start, I propose we start with rfc7159 and: > >>>> > >>>> 1) Apply verified errata from < > >>>> https://www.rfc-editor.org/errata_search.php?rfc=3D7159 > >>>> 2) Change the reference to ECMA-404 from informative to normative > >>> > >>> Can we get a first version of this before the I-D cutoff for Yoko > >>> (this coming Monday, 19 Oct)? > >> > >> Sure, but isn=E2=80=99t a consensus call on the substantive change to = the spec > in > >> order? > > > > That could be done by posting an I-D to make the proposal, and have > > the working group review it and comment on it. Right now, there's > > just a "here's what we plan to do", and there've been a few comments > > about that. Specific text to review might help, no? > > > > Barry > > RFC 7159 has the following verified errata: > > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4264 > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4336 > > I suggest at the least an I-D be published that applies these. > > > -- > - m&m > > Matt Miller > Cisco Systems, Inc. > > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1140fb701598fc052264e0b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = the off-chance anyone is listening: The second erratum is a correction to a= couple of errata references.=C2=A0 But I'd have thought that 7159bis s= hould really only have references to errata post-7159.=C2=A0 Pardon the ext= reme editorial wonkery.

On Wed, Oct 14, 2015 at 8:37 AM, Matt Miller (mamille2) <= span dir=3D"ltr"><mamille2@cisco.com> wrote:
> On Oct 13, 2015, at 22:22, B= arry Leiba <barryleiba@comput= er.org> wrote:
>
>>>> In a nutshell, the goal of this effort is to produce a bis= to 7159 that:
>>>>
>>>> * promotes JSON to IETF Internet Standard
>>>> * references ECMA-404 and is a reference for ECMA-404
>>>>
>>>> Tim Bray has agreed to edit 7159bis.
>>>>
>>>> As a start, I propose we start with rfc7159 and:
>>>>
>>>> 1) Apply verified errata from <
>>>> https://www.rfc-editor.org/e= rrata_search.php?rfc=3D7159
>>>> 2) Change the reference to ECMA-404 from informative to no= rmative
>>>
>>> Can we get a first version of this before the I-D cutoff for Y= oko
>>> (this coming Monday, 19 Oct)?
>>
>> Sure, but isn=E2=80=99t a consensus call on the substantive change= to the spec in
>> order?
>
> That could be done by posting an I-D to make the proposal, and have > the working group review it and comment on it.=C2=A0 Right now, there&= #39;s
> just a "here's what we plan to do", and there've bee= n a few comments
> about that.=C2=A0 Specific text to review might help, no?
>
> Barry

RFC 7159 has the following verified errata:

* https://www.rfc-editor.org/e= rrata_search.php?rfc=3D7159&eid=3D3915
* https://www.rfc-editor.org/e= rrata_search.php?rfc=3D7159&eid=3D4264
* https://www.rfc-editor.org/e= rrata_search.php?rfc=3D7159&eid=3D4336

I suggest at the least an I-D be published that applies these.


--
- m&m

Matt Miller <mamille2@cisco.com>
Cisco Systems, Inc.





--
=
--001a1140fb701598fc052264e0b5-- From nobody Sun Oct 18 11:35: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 04E7E1ACD55 for ; Sun, 18 Oct 2015 11:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq72UI6ql4Bf for ; Sun, 18 Oct 2015 11:35:15 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 E0F121ACD53 for ; Sun, 18 Oct 2015 11:35:14 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so43241865igb.0 for ; Sun, 18 Oct 2015 11:35:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EskZv9P/1rPff895qDF5Z2nltVyp3hL6voGlAbtT8J0=; b=MStr5OdHaix26LkiHaznKv7baJpd72+EIUDnGwNJ3KjddDsP5uETxAvdIXQ3wYcVs+ ipOIbb9SlYG/+UdpHD8HAfGNImEHCPZF9TNFJjFVnHJ8SHTrAh6aP6yPFoJBhKNKHEq3 TvlOqgjzAXHLdMnXTSKnYJurZKilvo+S6tlOaA7YxFISPrNW4Xklfc7XSJfu4kQ6HjH0 YOiMlqQLBTs26iGheIAEzQLq5RxhFWyPAZek84g/3iPjv4b5fRfZvKnhwbzHij0+3E2B IZX3zf4FTUM01TEDLTdVbchakkfjefqdxkd8f+HG/osdpfd31ofa1bFZf+k8K7Jzi3Ji pjfw== X-Gm-Message-State: ALoCoQlYV1ncJ8lih9d4vveuPTTeG+wFQKSQ4fHyg3Ey1zzLdCXhKoZrNLUOS32O41iFJi3dCFLf X-Received: by 10.50.39.109 with SMTP id o13mr16221045igk.43.1445193314195; Sun, 18 Oct 2015 11:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.30.4 with HTTP; Sun, 18 Oct 2015 11:34:54 -0700 (PDT) X-Originating-IP: [209.52.88.169] In-Reply-To: References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> From: Tim Bray Date: Sun, 18 Oct 2015 11:34:54 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7bd76d041ff77c0522654a9f Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 18:35:17 -0000 --047d7bd76d041ff77c0522654a9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [I'll post a 7159bis with errata by end-of-day whether I get an answer on the errata-wonkery or not. Now, returning to the meat of the discussion.] I have really major heartburn with introducing a Normative Reference to ECMA404 in 7159bis. Because language in standards documents should be used carefully, and =E2=80=9CNormative Reference=E2=80=9D has a very specific me= aning, and that meaning clearly does not apply in this case. However, since there is apparently a feeling that there is some benefit to the community in achieving =E2=80=9Cstandards harmony=E2=80=9D, let me propose three ways fo= rward: 1. Include a normative reference to ECMA404, but accompany it with text explaining that this reference is marked normative because it is considered authoritative in the community of JavaScript language specifiers, not in the normal sense of =E2=80=9Cnormative=E2=80=9D; there is no necessity to r= ead it in order too understand or implement RFC7159bis, nor does it specify any technology which must be present in an implementation that is not also described in 7159bis.=E2=80=9D 2. Do not include a normative reference, but expand the note about ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered authoritative in the community of JavaScript implementers. 3. Conclude that this effort has no observable benefit to the community implementing JSON on the Internet and abandon the RFC7159bis project. On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba wrote: > >>> Sure, but isn=E2=80=99t a consensus call on the substantive change to= the spec > in > >>> order? > >> > >> That could be done by posting an I-D to make the proposal, and have > >> the working group review it and comment on it. Right now, there's > >> just a "here's what we plan to do", and there've been a few comments > >> about that. Specific text to review might help, no? > > > > RFC 7159 has the following verified errata: > > > > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 > > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4264 > > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4336 > > > > I suggest at the least an I-D be published that applies these. > > That works for me. > > As to the other, specific text proposed on the list will give people > something to discuss. > > Barry > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --047d7bd76d041ff77c0522654a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[I&= #39;ll post a 7159bis with errata by end-of-day whether I get an answer on = the errata-wonkery or not.=C2=A0 Now, returning to the meat of the discussi= on.]

=
I have really major = heartburn with introducing a Normative Reference to ECMA404 in 7159bis.=C2= =A0 Because language in standards documents should be used carefully, and = =E2=80=9CNormative Reference=E2=80=9D has a very specific meaning, and that= meaning clearly does not apply in this case.=C2=A0 However, since there is= apparently a feeling that there is some benefit to the community in achiev= ing =E2=80=9Cstandards harmony=E2=80=9D, let me propose three ways forward:=

1. Include a normative r= eference to ECMA404, but accompany it with text explaining that this refere= nce is marked normative because it is considered authoritative in the commu= nity of JavaScript language specifiers, not in the normal sense of =E2=80= =9Cnormative=E2=80=9D; there is no necessity to read it in order too understand or implement RFC7159bis, nor does it specify = any technology which must be present in an implementation that is not also = described in 7159bis.=E2=80=9D

2. Do= not include a normative reference, but expand the note about ECMA404 in Se= ction 1.2 to emphasize that ECMA404 may be considered authoritative in the = community of JavaScript implementers.


On We= d, Oct 14, 2015 at 9:10 AM, Barry Leiba <barryleiba@computer.org= > wrote:
>&= gt;> Sure, but isn=E2=80=99t a consensus call on the substantive change = to the spec in
>>> order?
>>
>> That could be done by posting an I-D to make the proposal, and hav= e
>> the working group review it and comment on it.=C2=A0 Right now, th= ere's
>> just a "here's what we plan to do", and there've= been a few comments
>> about that.=C2=A0 Specific text to review might help, no?
>
> RFC 7159 has the following verified errata: >
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D3915
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D4264
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D4336
>
> I suggest at the least an I-D be published that applies these.

That works for me.

As to the other, specific text proposed on the list will give people
something to discuss.

Barry



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--047d7bd76d041ff77c0522654a9f-- From nobody Sun Oct 18 12:22:28 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 730A51ACE6A for ; Sun, 18 Oct 2015 12:22:26 -0700 (PDT) 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 wMjtgdTE5nfE for ; Sun, 18 Oct 2015 12:22:24 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 B21561ACE67 for ; Sun, 18 Oct 2015 12:22:24 -0700 (PDT) Received: by yknn9 with SMTP id n9so74424754ykn.0 for ; Sun, 18 Oct 2015 12:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=0IGdHxURz+YnjNojJDOTt/iBUHNQBuO6R/PUV7XxiUo=; b=xra7tfcDZHFFqSeKvGvb+d/Cshdq6+ZWn/h8CH0WtTr07mmJIsqp0sO+khIuxy73Pd syzzHhHEiDkew74eKoKdPIOFIz3u4/nBfSO4Aab1QCWg4bc+S3kr5cSD8cUFiV1HYSOV J7Dbo4DzYV/Aw/kktpBnV21Aj6LuitCzjUvJ5VJd6lwH+zWAEXNcdYlv3PmAjWom2X9q p7QCvcM/Uogd1FivN1rWf4HS+8P7K8KuBOlvq2bO2NeGW2a2K3vz2zlPmBiVnwONyNt4 4F09uQWUq2hPVsqVLXjzFY6VR5qqoPMGKS9DzovoSpSbBhPrCDHeTt420EIuHvjLl1aV u3rw== X-Received: by 10.129.119.4 with SMTP id s4mr19378635ywc.67.1445196144053; Sun, 18 Oct 2015 12:22:24 -0700 (PDT) Received: from idefix.nuance.com (pool-108-53-90-228.nwrknj.fios.verizon.net. [108.53.90.228]) by smtp.gmail.com with ESMTPSA id q4sm23666279ywf.32.2015.10.18.12.22.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 12:22:22 -0700 (PDT) To: Tim Bray , Barry Leiba References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> From: "Peter F. Patel-Schneider" X-Enigmail-Draft-Status: N1110 Message-ID: <5623F16D.9040304@gmail.com> Date: Sun, 18 Oct 2015 12:22:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 19:22:26 -0000 You are echoing my sentiments. I vote for something along the lines of option 2. (I would really like to vote for 3, but standards harmony does indeed have some benefit.) The other option would be to make all the language definition stuff in RFC7159bis informative and point to ECMA404 for the normative definition. However, this option has the added problem that the language definition in ECMA404 depends on an undefined formalism. peter On 10/18/2015 11:34 AM, Tim Bray wrote: > [I'll post a 7159bis with errata by end-of-day whether I get an answer on the > errata-wonkery or not. Now, returning to the meat of the discussion.] > > I have really major heartburn with introducing a Normative Reference to > ECMA404 in 7159bis. Because language in standards documents should be used > carefully, and “Normative Reference” has a very specific meaning, and that > meaning clearly does not apply in this case. However, since there is > apparently a feeling that there is some benefit to the community in achieving > “standards harmony”, let me propose three ways forward: > > 1. Include a normative reference to ECMA404, but accompany it with text > explaining that this reference is marked normative because it is considered > authoritative in the community of JavaScript language specifiers, not in the > normal sense of “normative”; there is no necessity to read it in order too > understand or implement RFC7159bis, nor does it specify any technology which > must be present in an implementation that is not also described in 7159bis.” > > 2. Do not include a normative reference, but expand the note about ECMA404 in > Section 1.2 to emphasize that ECMA404 may be considered authoritative in the > community of JavaScript implementers. > > 3. Conclude that this effort has no observable benefit to the community > implementing JSON on the Internet and abandon the RFC7159bis project. > > On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba > wrote: > > >>> Sure, but isn’t a consensus call on the substantive change to the spec in > >>> order? > >> > >> That could be done by posting an I-D to make the proposal, and have > >> the working group review it and comment on it. Right now, there's > >> just a "here's what we plan to do", and there've been a few comments > >> about that. Specific text to review might help, no? > > > > RFC 7159 has the following verified errata: > > > > * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=3915 > > * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4264 > > * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4336 > > > > I suggest at the least an I-D be published that applies these. > > That works for me. > > As to the other, specific text proposed on the list will give people > something to discuss. > > Barry > > > > > -- > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) > From nobody Sun Oct 18 15:11:45 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 2590A1AD363 for ; Sun, 18 Oct 2015 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGyMBFLUGAIL for ; Sun, 18 Oct 2015 15:11:41 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 BCBE01AD35A for ; Sun, 18 Oct 2015 15:11:41 -0700 (PDT) Received: by igbhv6 with SMTP id hv6so45640270igb.0 for ; Sun, 18 Oct 2015 15:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZEnNVUiKDI5EYjP9CA+0m1+t4pO0rX9MSvmrOXDEQEA=; b=KcyaJNpmchkFn8BGht9ht0p9P2NcXNBHyq5nQV7kUdUCrclhbE159/cNK3+i21xSR/ p/XnON9VvNlStbaj9yhBepR4/upc1Y92ZxVmyzfIoDwgxtvurgsXnF/oOGlxo75i1B+Q 6p/VUGcEBtZSu0PGK8e1o6DNq7anMZakqANdeKot2VkYCpL+tvdYu3QbRh6hQ6imrEku RTQyh+w0GXEtmE12LaRLPY53SInDOgrusLa97B8DXmnWpNopMklrHRG42e2kUXv/5Hvd i8pdQyFJJvH/I//1MNnwSDgA88IIGA2dBu07hExSBOJ5unWkA+g6xloxQQ+liFCtUJdo W+Pw== MIME-Version: 1.0 X-Received: by 10.50.26.66 with SMTP id j2mr15794090igg.42.1445206301157; Sun, 18 Oct 2015 15:11:41 -0700 (PDT) Received: by 10.107.8.17 with HTTP; Sun, 18 Oct 2015 15:11:41 -0700 (PDT) In-Reply-To: References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> Date: Sun, 18 Oct 2015 15:11:41 -0700 Message-ID: From: Rob Sayre To: Tim Bray Content-Type: multipart/alternative; boundary=047d7bd75bb2352f0405226850d9 Archived-At: Cc: "Matt Miller \(mamille2\)" , Barry Leiba , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 22:11:44 -0000 --047d7bd75bb2352f0405226850d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > =E2=80=9CNormative Reference=E2=80=9D has a very specific meaning, and t= hat meaning clearly does not apply in this case. That conclusion is not clear to me. Can you explain? - Rob On Sun, Oct 18, 2015 at 11:34 AM, Tim Bray wrote: > [I'll post a 7159bis with errata by end-of-day whether I get an answer on > the errata-wonkery or not. Now, returning to the meat of the discussion.= ] > > I have really major heartburn with introducing a Normative Reference to > ECMA404 in 7159bis. Because language in standards documents should be us= ed > carefully, and =E2=80=9CNormative Reference=E2=80=9D has a very specific = meaning, and that > meaning clearly does not apply in this case. However, since there is > apparently a feeling that there is some benefit to the community in > achieving =E2=80=9Cstandards harmony=E2=80=9D, let me propose three ways = forward: > > 1. Include a normative reference to ECMA404, but accompany it with text > explaining that this reference is marked normative because it is consider= ed > authoritative in the community of JavaScript language specifiers, not in > the normal sense of =E2=80=9Cnormative=E2=80=9D; there is no necessity to= read it in order > too understand or implement RFC7159bis, nor does it specify any > technology which must be present in an implementation that is not also > described in 7159bis.=E2=80=9D > > 2. Do not include a normative reference, but expand the note about ECMA40= 4 > in Section 1.2 to emphasize that ECMA404 may be considered authoritative = in > the community of JavaScript implementers. > > 3. Conclude that this effort has no observable benefit to the community > implementing JSON on the Internet and abandon the RFC7159bis project. > > On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba > wrote: > >> >>> Sure, but isn=E2=80=99t a consensus call on the substantive change t= o the >> spec in >> >>> order? >> >> >> >> That could be done by posting an I-D to make the proposal, and have >> >> the working group review it and comment on it. Right now, there's >> >> just a "here's what we plan to do", and there've been a few comments >> >> about that. Specific text to review might help, no? >> > >> > RFC 7159 has the following verified errata: >> > >> > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D3915 >> > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4264 >> > * https://www.rfc-editor.org/errata_search.php?rfc=3D7159&eid=3D4336 >> > >> > I suggest at the least an I-D be published that applies these. >> >> That works for me. >> >> As to the other, specific text proposed on the list will give people >> something to discuss. >> >> Barry >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7bd75bb2352f0405226850d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0 =E2=80=9CNormative Reference=E2=80=9D has = a very specific meaning, and that meaning clearly does not apply in this ca= se.

That conclusion is not clear to me. Can you ex= plain?

- Rob


On Sun, Oct 18, 2015 at 11:= 34 AM, Tim Bray <tbray@textuality.com> wrote:
[I'll post a 7159bis with errata by end-of-day whe= ther I get an answer on the errata-wonkery or not.=C2=A0 Now, returning to = the meat of the discussion.]

I have really major heartburn with introducing a Normative Reference to= ECMA404 in 7159bis.=C2=A0 Because language in standards documents should b= e used carefully, and =E2=80=9CNormative Reference=E2=80=9D has a very spec= ific meaning, and that meaning clearly does not apply in this case.=C2=A0 H= owever, since there is apparently a feeling that there is some benefit to t= he community in achieving =E2=80=9Cstandards harmony=E2=80=9D, let me propo= se three ways forward:

1.= Include a normative reference to ECMA404, but accompany it with text expla= ining that this reference is marked normative because it is considered auth= oritative in the community of JavaScript language specifiers, not in the no= rmal sense of =E2=80=9Cnormative=E2=80=9D; there is no necessity to read it= in order too understand or implement RFC7159bis, = nor does it specify any technology which must be present in an implementati= on that is not also described in 7159bis.=E2=80=9D

<= /span>
2. Do not include a normative reference, but expand the no= te about ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered= authoritative in the community of JavaScript implementers.
<= span style=3D"color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-ser= if;font-size:12.6667px">3. Conclude that this effort has no observable bene= fit to the community implementing JSON on the Internet and abandon the RFC7= 159bis project.

On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba <barryleiba@computer.org> wrote:
>>> Sure, but isn=E2=80=99t a consensus call on the su= bstantive change to the spec in
>>> order?
>>
>> That could be done by posting an I-D to make the proposal, and hav= e
>> the working group review it and comment on it.=C2=A0 Right now, th= ere's
>> just a "here's what we plan to do", and there've= been a few comments
>> about that.=C2=A0 Specific text to review might help, no?
>
> RFC 7159 has the following verified errata:
>
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D3915
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D4264
> * https://www.rfc-editor.= org/errata_search.php?rfc=3D7159&eid=3D4336
>
> I suggest at the least an I-D be published that applies these.

That works for me.

As to the other, specific text proposed on the list will give people
something to discuss.

Barry



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

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


--047d7bd75bb2352f0405226850d9-- From nobody Sun Oct 18 15:24: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 49AA21AD4A1 for ; Sun, 18 Oct 2015 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 OrgUFNMhwiqQ for ; Sun, 18 Oct 2015 15:24:05 -0700 (PDT) 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 6BC981AD49B for ; Sun, 18 Oct 2015 15:24:05 -0700 (PDT) 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 t9IMO05c015086; Mon, 19 Oct 2015 00:24:00 +0200 (CEST) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (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 3nfG336HJ5z4pPj; Mon, 19 Oct 2015 00:23:59 +0200 (CEST) Message-ID: <56241BFE.5080609@tzi.org> Date: Mon, 19 Oct 2015 00:23:58 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.5 (Macintosh/20150923) MIME-Version: 1.0 To: Rob Sayre References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 22:24:07 -0000 Rob Sayre wrote: >> “Normative Reference” has a very specific meaning, and that meaning > clearly does not apply in this case. > > That conclusion is not clear to me. Can you explain? I'll leave explaining the conclusion to Tim, but here is the premise: https://www.ietf.org/iesg/statement/normative-informative.html In particular: "Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work." Grüße, Carsten From nobody Sun Oct 18 16:33: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 67DCD1B2A1D for ; Sun, 18 Oct 2015 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m94wYDBMHWII for ; Sun, 18 Oct 2015 16:33:05 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 B1F991B2A16 for ; Sun, 18 Oct 2015 16:33:05 -0700 (PDT) Received: by igbhv6 with SMTP id hv6so46266891igb.0 for ; Sun, 18 Oct 2015 16:33:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Mh5fW2sgWeC6D8oz5KrimbWSMXawG6DYVJ5sozXxDp8=; b=CAHkNlis/b7OIC684pawXn324it7MwbnOpdeNnNv1XoLNlq9hZcGW2cT8Lp24f9PnR L7F4wU4KkIl1kc6u6Myvk8b8yjQUFDvqh0HhFFv6LRgdPJzxn9cIsYNzuglRq2GdfNtm zBd3kmOGg2rFSuW5Jls/qipg7hYT3IqDDk8qhi2L35SmGdcjcbroTLazj1mZcX9HZxNn ZZgrDU4K9hP4PiS492DLIKqawe85EcTOEO8u/l++ohZKgeFHuLsQzn045jzTNTgly9ld oQs4BgQrHfrCv9GVwd9DpE7U9fFCIk3brfDdOopzCDYQ3FXs0ORiEdzlR2fMLwB10Oi2 6o1A== X-Gm-Message-State: ALoCoQnioDi4LXEuI4Qj0su7ezpjhgF76RrbuhZVPhrjgl82f+gh0WtMmYA8e4fyMfLX/omGoHQU X-Received: by 10.50.78.7 with SMTP id x7mr17700564igw.54.1445211185024; Sun, 18 Oct 2015 16:33:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.30.4 with HTTP; Sun, 18 Oct 2015 16:32:45 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: <56241BFE.5080609@tzi.org> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> From: Tim Bray Date: Sun, 18 Oct 2015 16:32:45 -0700 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0117646d4f2e360522697347 Archived-At: Cc: "json@ietf.org" , Rob Sayre Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Oct 2015 23:33:07 -0000 --089e0117646d4f2e360522697347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Carsten. My belief is that ECMA404 meet neither of those criteria. I also believe, based on prior conversation, that the goal of this WG has nothing to do with with changing the meaning of RFC7159, but rather is aimed at =E2=80=9Cstandards harmonization=E2=80=9D. While I=E2=80=99m uncon= vinced of the benefits, if there=E2=80=99s IETF consensus behind such harmonization, I wouldn=E2=80= =99t stand in the way. But I would hope that there=E2=80=99s a better way to achieve it = than with a flagrantly bogus normative reference. And I=E2=80=99ve suggested a = couple. On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann wrote: > Rob Sayre wrote: > >> =E2=80=9CNormative Reference=E2=80=9D has a very specific meaning, an= d that meaning > > clearly does not apply in this case. > > > > That conclusion is not clear to me. Can you explain? > > I'll leave explaining the conclusion to Tim, but here is the premise: > > https://www.ietf.org/iesg/statement/normative-informative.html > > In particular: "Normative references specify documents that must be read > to understand or implement the technology in the new RFC, or whose > technology must be present for the technology in the new RFC to work." > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > 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) --089e0117646d4f2e360522697347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tha= nks, Carsten. My belief is that ECMA404 meet neither of those criteria.

I also believe, based on pri= or conversation, that the goal of this WG has nothing to do with with chang= ing the meaning of RFC7159, but rather is aimed at =E2=80=9Cstandards harmo= nization=E2=80=9D. While I=E2=80=99m unconvinced of the benefits, if there= =E2=80=99s IETF consensus behind such harmonization, I wouldn=E2=80=99t sta= nd in the way.=C2=A0 But I would hope that there=E2=80=99s a better way to = achieve it than with a flagrantly bogus normative reference.=C2=A0 And I=E2= =80=99ve suggested a couple.

On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann <cabo@t= zi.org> wrote:
Rob Sayre wrote:
>>=C2=A0 =E2=80=9CNormative Reference=E2=80=9D has a very specific me= aning, and that meaning
> clearly does not apply in this case.
>
> That conclusion is not clear to me. Can you explain?

I'll leave explaining the conclusion to Tim, but here is the pre= mise:

https://www.ietf.org/iesg/statement/no= rmative-informative.html

In particular: "Normative references specify documents that must be re= ad
to understand or implement the technology in the new RFC, = or whose
technology must be present for the technology in the new RFC to work."=

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

_______________________________________________
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)
--089e0117646d4f2e360522697347-- From nobody Sun Oct 18 18:01: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 9309B1B2AE5 for ; Sun, 18 Oct 2015 18:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zNijfQjquQZ for ; Sun, 18 Oct 2015 18:01:49 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0097.outbound.protection.outlook.com [104.47.126.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C972B1B2AD6 for ; Sun, 18 Oct 2015 18:01:48 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0132.jpnprd01.prod.outlook.com (10.161.27.13) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 01:01:44 +0000 To: Tim Bray , Barry Leiba References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <562440F5.7010603@it.aoyama.ac.jp> Date: Mon, 19 Oct 2015 10:01:41 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0015.jpnprd01.prod.outlook.com (25.161.24.25) To KAWPR01MB0132.jpnprd01.prod.outlook.com (25.161.27.13) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0132; 2:O2Fsc+O882kldrL3fPzEVtJbJyeLGB82Zd0kPYn1h4kyA7kbSmOz0zeg5sT8puuE68TFtcaxnI9geYOdq39/KxzMgDYcGrCFI0unKMAVuuwwyYoYmJV70Beq4F0mPuOUzguv2yDGs+s2O9Yw0izKqawHOlTz/COAAwafaeKaLr8=; 3:FXp3alqMcov51QTXMExgrreE8vWtN4AjGx5YAtyUYWcV7aP0ma/qNsWH/Vn+Fj+leWRvksK8fWfT/eMNzpFRpcLYKru/Bp6EYtNLZM0lM3q8xr+hAfAmkkDjEuP5zpreO4hte1wuHWpI/2RgMO+dEg==; 25:vV0M4fYcoTGYFCgmFJqyBpoL7GI8kVOcItvJjyq8PsOOwYJcao2umAI6cEHSeZZsOWTD7QByqjXI9vE6IKpynpCUL8jhF3DSqulsYxfM6aISjFvda5N9xXojDMj8UduVaKJyJ/EK+3EQzx8gKijgPBdFvYGtYJqDPekiiTGmJhtTvvLUJlx16DHt8FX0xvY/IPDu4EMwKss3jGi5GpX+tZoPwEpjYthrbBIkhBmlI7nmxFEsoK9HpRRZYe0gZrBHIm7qQTSDOZRPJxRF+d5ouQ==; 4:hahfU2ej+zOxWXJPhLR/Y7Rw2oa96LHYKtoaoTZZBvT9mqEqaqvgEn0Qe7N8ewH5oG20wGHVxMch+UVOa4BKj36JqaA89A4howfyff9H9AY+13GmVOKt6E4W23SWTfarPAb8qd+nkDheV5Umbo3h1VEAWISF/61G6O4weEAD+gVbRvoDwX3jeA1Igew+etjNHgUaApAivivcRj5HteeldEUTBtvwlLtGFWQgyAshvaZJrIIp7ptV4IxmK25EC8TVbjhUxgAOeoMEcqT5hcSkO3eyzEjb5E4XiUPx5/AjA+txk719OjlSjN11pM67LsBDMJTxNwESEmd7nIAmqCEcZg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0132; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:KAWPR01MB0132; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0132; X-Forefront-PRVS: 07349BFAD2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(24454002)(479174004)(199003)(377454003)(66066001)(93886004)(33656002)(5008740100001)(23676002)(92566002)(65806001)(189998001)(15975445007)(16799955002)(5001960100002)(122386002)(2950100001)(74482002)(50466002)(64126003)(19580405001)(40100003)(65956001)(54356999)(561944003)(42186005)(77096005)(80316001)(5004730100002)(105586002)(64706001)(19580395003)(46102003)(83506001)(47776003)(101416001)(5007970100001)(99136001)(87266999)(5001770100001)(76176999)(65816999)(97736004)(81156007)(50986999)(4001350100001)(87976001)(86362001)(59896002)(106356001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0132; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTMyOzIzOmhET1NrbTJKckJOaUhET2wrcmlwS2JJT1NP?= =?utf-8?B?SnV4Ukh4WHNQQk1RWWhIbDVyOXZlZEY0UGxSN2dDRHkvNC9TT2pPNGZlZXNw?= =?utf-8?B?ZlJIUWlVS1hGU2FHTGl5aEg5QUdCbDA1Wm9sKzcrSzFnbGJMa1VJTU0wZy9S?= =?utf-8?B?M0QzSURQdlA1eVJEZHVoUndzd05HcDMwbGx4Rkh6ZjZ4RHl6cFBGRXlHVVE0?= =?utf-8?B?MUZWWXBBSWNpeTVEYnJsL1hIM0hRQTBYN2tXb2VIRVZkZGg1dEttSXk0SDhD?= =?utf-8?B?K2xxeXplUEdPM2NqMlZiSDFLMmJJYUlWWUxvRkpZOXpmOFNyeEVDNHRKSlN2?= =?utf-8?B?UjNlLzdxNy9EM0ZrdzYzK0tpRy9ITzhTWm1DRFRsU09mdmtlbGptWlFLczRJ?= =?utf-8?B?TUlOVWI2RmxnZnlMK0JHbW8wQVJzanpaME9ZNVY1VHdEMWJoQ3dFT1JhTjla?= =?utf-8?B?ckRHbnZDNTNMUDlpRDBZb2duT1dpa21JVy9pYzFiaGJRaE5CakZMN2tvNDI1?= =?utf-8?B?MUt2NmhvN2FRNHUvTEZERGJRWS9WcjZwOUFhcW1LdGgwbklSTXZwUmg0Z2NS?= =?utf-8?B?YWFPTHhTNmNnT2pXS28zNFh0QnMwckU4eEtIMktzb3JXaHZMRnUvVUV0YmZu?= =?utf-8?B?WUlSaGJNZVFHNk5Zc0JXRWllK1NhaUhYa0xsT2VKSG9JUTg5Q25lenR0bDFn?= =?utf-8?B?SHFoY3dtdlZpZkV1YitMSFZHODRRcW1ZVThWM2l2WTMrbHJacmN6ME9wbHQ2?= =?utf-8?B?djFyMy9LdDA1Y0hwV3VUSGdiRGo5eHBMWG5sa3QyenFjZ25sWTArUUZNWTBG?= =?utf-8?B?dFhHYlBldCtQWW1IcGtpNlpvV29sdmhnZUZJaVB3eWhCcG9vZmFiUVV3N0ls?= =?utf-8?B?d252VUpnZksrUWQ1aTF3dW1LZUc4Z3VtWVZDYTVVVURpd0JRRmpxYXdULzB5?= =?utf-8?B?eEdxVHJlVGhKQjM4VzBRaThkUGhHR0t6T1U0bmY1eE1yMkFlODUrRDJGemhT?= =?utf-8?B?UmQ1QW5Pb2NnL1ZqSElJQkUwUThUZlRYY241YSsxNmg5MHJYWmtGUkh2ZlRK?= =?utf-8?B?K2x1S1JCYm5mRy9ZNW5UMWxISGhMMzI4emtEbUdhTW1tQVdUNWNKRjQrRDls?= =?utf-8?B?NE40QzdjckpQamZZbFgxSmFVR1A5YkE4UTBxM211Y296WEZMRUtDYkNXcnU4?= =?utf-8?B?UVBIS3FoR0luU1RIZHFSMWhmZ1ZLcXdhNU1iV0lPUzhwdTMyWUVUVlBYMjFG?= =?utf-8?B?SHFNZXhEeWJnemxVQ2JYeUNWR3FDTitBZlZaZEd0WWtuRzBhRE5mWnVFNlE4?= =?utf-8?B?cVlpRzE1QXMyNmdSU20xVjd3Z0liVE1Jc3lSNzBoWlcxMEIxWlFGcnV2MkJy?= =?utf-8?B?L0NWeEVXRHk0UnBCR0dnZExHVUhQNCtWWHFmWlZSaE9Wb3JCa3E1bkRYUTJK?= =?utf-8?B?VFBxTjQyNHpNUnA3SGs5MFB4N3FSRm1ZNEU4K0ZoT0pKby9Lejl4TUh2TnN0?= =?utf-8?B?S1ZLOXdrR0pBaG42UXBrUTdTTnEzK1FraDM4bEdqR3g4d2RxbUI3eGZHc2xU?= =?utf-8?B?VzNsOUNMcXozYkxtWXN2S2ZwNlRVMDJCS1Z2eGs4czNNV09Hd1NsSnZLTnlX?= =?utf-8?B?dGpFN05NRVlnTGNtSVVVNU5WQlFZQnhJZFJBSW9oVUFnN01hNjdqcGhpc29B?= =?utf-8?B?cGRpOXh6cUtYbklzYUVJRUwrU2ZoVWUyTFV2QTJWK3k1c3hrcVVIVUExQUVC?= =?utf-8?B?R2M5bFVxWXFGSEhvK2xWdVF5TFJ5RnBuZllrWU9wc3hPV0VXZlpqMGF5UE5P?= =?utf-8?B?azZNZFNnRm14UWttcWlvdDBibUdodk90d0g4cEcwUFlMRzhHZmZzMzNNV0hw?= =?utf-8?B?WkRWd1NtakR1Uk1haExuYlBUWWt6emo1cEJKWGk0TFNCMWlwcEEzOGRjdy9N?= =?utf-8?B?WFVFeWFhTGVRPT0=?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0132; 5:qLmxbZ5XhzQ0uCzJgnE05dEzOr12rQK6o83hVqtbboFug33o6VKX6T/YhympZBe7pitG/xuoqwce1fKfkN5mq4FwW3k3EHtX2VRJ6dFy3ROhSq/ywbz/aiQsCVa/3D0UtuZ5N+8hsieK9hfz9PRvwA==; 24:1Aml+l1uFjq9jzva7/e+S7Z6ra4tXl+vKoBlFme2UmEkQtorPkPKcxGebP/mNlwey2lhXjumuMiGvLmljde++BvTGMqB7Iypw1XKHXedA84=; 20:ErX01Kvn5hKuDa/aqSoEl9YtOlkje9+sNNOTN0254N/Eyy4eH8UjkINYkr32VshuszgJSPeem+GjPtkidX9EYw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2015 01:01:44.1924 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0132 Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 01:01:52 -0000 I'd be fine with 1. I agree that strictly speaking, it doesn't meet the criteria for a normative reference. But then, I don't know of anybody who would just go ahead and read straight through all the normative references when implementing a spec; in some cases, it may be a single paragraph or subsection that makes a reference normative, so selecting what you read is the default (unless the default is "look only at the examples and hack something up, and reading some part of normative references is anyway useless because thoroughly reading the spec at hand is too much work in the first place). There's one condition, namely that this is reciprocal (i.e. that ECMA also uses a normative reference), but as far as I understand, that's part of the plan, or not? Regards, Martin. On 2015/10/19 03:34, Tim Bray wrote: > [I'll post a 7159bis with errata by end-of-day whether I get an answer on > the errata-wonkery or not. Now, returning to the meat of the discussion.] > > I have really major heartburn with introducing a Normative Reference to > ECMA404 in 7159bis. Because language in standards documents should be used > carefully, and “Normative Reference” has a very specific meaning, and that > meaning clearly does not apply in this case. However, since there is > apparently a feeling that there is some benefit to the community in > achieving “standards harmony”, let me propose three ways forward: > > 1. Include a normative reference to ECMA404, but accompany it with text > explaining that this reference is marked normative because it is considered > authoritative in the community of JavaScript language specifiers, not in > the normal sense of “normative”; there is no necessity to read it in order > too understand or implement RFC7159bis, nor does it specify any technology > which must be present in an implementation that is not also described in > 7159bis.” > > 2. Do not include a normative reference, but expand the note about ECMA404 > in Section 1.2 to emphasize that ECMA404 may be considered authoritative in > the community of JavaScript implementers. > > 3. Conclude that this effort has no observable benefit to the community > implementing JSON on the Internet and abandon the RFC7159bis project. > > On Wed, Oct 14, 2015 at 9:10 AM, Barry Leiba > wrote: > >>>>> Sure, but isn’t a consensus call on the substantive change to the spec >> in >>>>> order? >>>> >>>> That could be done by posting an I-D to make the proposal, and have >>>> the working group review it and comment on it. Right now, there's >>>> just a "here's what we plan to do", and there've been a few comments >>>> about that. Specific text to review might help, no? >>> >>> RFC 7159 has the following verified errata: >>> >>> * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=3915 >>> * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4264 >>> * https://www.rfc-editor.org/errata_search.php?rfc=7159&eid=4336 >>> >>> I suggest at the least an I-D be published that applies these. >> >> That works for me. >> >> As to the other, specific text proposed on the list will give people >> something to discuss. >> >> Barry >> > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun Oct 18 19:49:46 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 631D31A00FA for ; Sun, 18 Oct 2015 19:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BikME_3t5aa for ; Sun, 18 Oct 2015 19:49:42 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (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 B76E51A00F4 for ; Sun, 18 Oct 2015 19:49:42 -0700 (PDT) Received: by ioll68 with SMTP id l68so15773459iol.3 for ; Sun, 18 Oct 2015 19:49:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Nj+b5d6KuP2Eqan01nrmCl1u7SCPqRtuocXtVOTTwZQ=; b=ASRVKHQJGMvZEKWC6YUnVaav0iQ6ImZFSFa+EaXFKkxJM7v6RJp0o8hTN8VCypy+83 iMZaGtlOqC9e87zth2Wbk7RW+1G2XWtF3N268wBJ5dvQQrvOd2NXgzli2EsyOH/jrfXl CZZA4WkK3sDJlS7XRmBE9tgT/njNE7SSIwWzT1eFCr9A3r7oHhmKMxR+DWhFffy+Xt0C xwHOLK5FaG0m2gIsckIxNKiyhewxUQvLfx5D7YQoeX61zfCAAYBZQEvR7HXxLTIXpF0Y mNiAgvjL4bcaJdAI0oi4hBXsk2PGyMoAWfv+XxcWIbl5SBADjfhuB1BktFrC5Q+gxE22 Tr7g== X-Gm-Message-State: ALoCoQnI+7+3+rghZjdUCXMOHP+miEAxJOqaq9VfhO2OI9BE9B8nJg26AtsSwEQPJ3AzA1RORhtx X-Received: by 10.107.163.204 with SMTP id m195mr28415115ioe.65.1445222982055; Sun, 18 Oct 2015 19:49:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.30.4 with HTTP; Sun, 18 Oct 2015 19:49:22 -0700 (PDT) X-Originating-IP: [24.84.248.61] In-Reply-To: References: From: Tim Bray Date: Sun, 18 Oct 2015 19:49:22 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a1140fb70779ef705226c32f9 Archived-At: Cc: "json@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 02:49:44 -0000 --001a1140fb70779ef705226c32f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It=E2=80=99s not letting me submit the draft because it claims that: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D JavaScript Object Notation Group exists but is not an active group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I=E2=80=99ve uploaded the XML & txt & HTML to http://www.tbray.org/ietf/715= 9bis/ - if someone else knows how to work around this go ahead, otherwise I could upload it as an individual submission. On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba wrote: > > In a nutshell, the goal of this effort is to produce a bis to 7159 that= : > > > > * promotes JSON to IETF Internet Standard > > * references ECMA-404 and is a reference for ECMA-404 > > > > Tim Bray has agreed to edit 7159bis. > > > > As a start, I propose we start with rfc7159 and: > > > > 1) Apply verified errata from < > https://www.rfc-editor.org/errata_search.php?rfc=3D7159 > > > 2) Change the reference to ECMA-404 from informative to normative > > Can we get a first version of this before the I-D cutoff for Yoko > (this coming Monday, 19 Oct)? > > Barry > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1140fb70779ef705226c32f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It= =E2=80=99s not letting me submit the draft because it claims that:=C2=A0
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
JavaScript Object Notation
Group exists but is not an active group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I=E2=80=99ve uploaded the XML & txt & HTML to=C2= =A0http://www.tbray.org/ietf= /7159bis/ - if someone else knows how to work around this go ahead, oth= erwise I could upload it as an individual submission.


On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba <barr= yleiba@computer.org> wrote:
> In a nutshell, the goal of this effort is to produce= a bis to 7159 that:
>
> * promotes JSON to IETF Internet Standard
> * references ECMA-404 and is a reference for ECMA-404
>
> Tim Bray has agreed to edit 7159bis.
>
> As a start, I propose we start with rfc7159 and:
>
> 1) Apply verified errata from < https= ://www.rfc-editor.org/errata_search.php?rfc=3D7159 >
> 2) Change the reference to ECMA-404 from informative to normative

Can we get a first version of this before the I-D cutoff for Yoko (this coming Monday, 19 Oct)?

Barry



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--001a1140fb70779ef705226c32f9-- From nobody Sun Oct 18 20:13: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 6E1111A017D for ; Sun, 18 Oct 2015 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_7UY9Ze_cM7 for ; Sun, 18 Oct 2015 20:13:49 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 571381A01A8 for ; Sun, 18 Oct 2015 20:13:38 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so47731488igb.0 for ; Sun, 18 Oct 2015 20:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DHlgVyWoG95dUvQmJCEJdBD3Nt7cOiFgEf6IDgiV3pg=; b=GUEmC6PS2K6mOhu508hardvos1HdLiA9jn9JN+UD8pNaAwNejQUyhwr8DHyPyHx5if bace1S9JRl35y9Qh9XoqpDrFJU8ux5bmwq1bX+U4Z2CLR0+qrS7PTHsirNfABeARm3D7 fH1KZ/TsfRgLA2sfaNcCWTf9/1hKpX0pHy5FPbR+B/0q69WVAM7trRtApZ44uG1lte0U 0tLZiJLSnmQAXta9K87dpLm+HkPjqm5tlOWl6ORvKT8NHl8sgZaKsIq6ivQdZ9XrIYMJ n3lDcKB+YMRIxBGxSyxbQNMw+82gEJfWdcipmp21s+RIteYQVXdVlVSheeODV/wqDehy Azew== MIME-Version: 1.0 X-Received: by 10.50.117.97 with SMTP id kd1mr16372146igb.42.1445224416130; Sun, 18 Oct 2015 20:13:36 -0700 (PDT) Received: by 10.107.8.17 with HTTP; Sun, 18 Oct 2015 20:13:36 -0700 (PDT) In-Reply-To: References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> Date: Sun, 18 Oct 2015 20:13:36 -0700 Message-ID: From: Rob Sayre To: Tim Bray Content-Type: multipart/alternative; boundary=089e01183c70f1bdf205226c87a2 Archived-At: Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 03:13:51 -0000 --089e01183c70f1bdf205226c87a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 18, 2015 at 4:32 PM, Tim Bray wrote: > Thanks, Carsten. My belief is that ECMA404 meet neither of those criteria= . > > I also believe, based on prior conversation, that the goal of this WG has > nothing to do with with changing the meaning of RFC7159, but rather is > aimed at =E2=80=9Cstandards harmonization=E2=80=9D. While I=E2=80=99m unc= onvinced of the benefits, > if there=E2=80=99s IETF consensus behind such harmonization, I wouldn=E2= =80=99t stand in > the way. But I would hope that there=E2=80=99s a better way to achieve i= t than > with a flagrantly bogus normative reference. And I=E2=80=99ve suggested = a couple. > ECMA404 should be a normative reference. - Rob > > On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann wrote: > >> Rob Sayre wrote: >> >> =E2=80=9CNormative Reference=E2=80=9D has a very specific meaning, a= nd that meaning >> > clearly does not apply in this case. >> > >> > That conclusion is not clear to me. Can you explain? >> >> I'll leave explaining the conclusion to Tim, but here is the premise: >> >> https://www.ietf.org/iesg/statement/normative-informative.html >> >> In particular: "Normative references specify documents that must be read >> to understand or implement the technology in the new RFC, or whose >> technology must be present for the technology in the new RFC to work." >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> 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) > --089e01183c70f1bdf205226c87a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Oct 18, 2015 at 4:32 PM, Tim Bray <tbray@textuality.com> wrote:
Thanks, Carsten. My belief is that ECMA404 meet neither o= f those criteria.

I also believe, based on prior conversation, that the = goal of this WG has nothing to do with with changing the meaning of RFC7159= , but rather is aimed at =E2=80=9Cstandards harmonization=E2=80=9D. While I= =E2=80=99m unconvinced of the benefits, if there=E2=80=99s IETF consensus b= ehind such harmonization, I wouldn=E2=80=99t stand in the way.=C2=A0 But I = would hope that there=E2=80=99s a better way to achieve it than with a flag= rantly bogus normative reference.=C2=A0 And I=E2=80=99ve suggested a couple= .

ECMA404 should be a normative= reference.

- Rob




=C2=A0

On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann <cabo@tzi.org&= gt; wrote:
Rob Sayre wrote:
>>=C2=A0 =E2=80=9CNormative Reference=E2=80=9D has a very specific me= aning, and that meaning
> clearly does not apply in this case.
>
> That conclusion is not clear to me. Can you explain?

I'll leave explaining the conclusion to Tim, but here is the pre= mise:

https://www.ietf.org/iesg/statement/no= rmative-informative.html

In particular: "Normative references specify documents that must be re= ad
to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work."=

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

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



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

--089e01183c70f1bdf205226c87a2-- From nobody Sun Oct 18 21:16: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 8111B1A1A50 for ; Sun, 18 Oct 2015 21:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrRUBkqz_OG4 for ; Sun, 18 Oct 2015 21:16:49 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0108.outbound.protection.outlook.com [104.47.125.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FC31A1A4F for ; Sun, 18 Oct 2015 21:16:48 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0133.jpnprd01.prod.outlook.com (10.161.228.149) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 04:16:45 +0000 To: Tim Bray , Barry Leiba References: From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56246EA8.90207@it.aoyama.ac.jp> Date: Mon, 19 Oct 2015 13:16:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0017.apcprd06.prod.outlook.com (25.164.91.27) To OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0133; 2:+CKilrzdS61Yes4RqbK3Gg4x7RrJ5/ru9sT2mtQXSZ6sks+spx+/u6wWSwXQVF1AgxIdlFQ231I7mLP8WDkHVoL2hjFvtUgYoGoOJBZ4D5bxNkdpMzV/yT22xlyf9nEHoIlMoNk/L1c3V4fXCvC/ek0WUczPOhQ1a/+IP8GoxtM=; 3:JzCzBrDbAN1ubCHIpapZ9TyFprWzIE7C8E+UnjtIu3gDdG1zH9HGS3otBs/S8ejAavGlid880/6TXLBCAaC8a60dhlwkurMTf9XH6daH4Qjmo979egSN0NAfIoSb6XYbSmPg2VZhoKRE2A271CfdQA==; 25:FuOC7JDX2sNJOECgsGB9Z1wpIsGPIylgmjmQhoxuP63I4SsdUmiBm7hxUFwg4RbFFajy1f+zQpUS9Y1yivy8pnSM5AgPwy7ag4nKUMv6iG25+XDvco7ymSA7hbGJhV7uEgQ1q1sBa3U/SRyYRGuK8FijkDNs3D5QZvyy8qLRh9jFLCwIFWSyNA50r7apBG0e0EtryQ+/LReXIdXqmtPfZC0sa+dm61d/mTvc+U2HeuDennlqq0Lm5tSbrsZVmT53nI2yAQJpLllky3J4M6O0zw==; 4:d4BCbIYc6CvOrbAi8xjiZbsrt7Sobzhhk4cL6ymEdjU+e1p0jgn/I5NCa/i6Qjk7/LVOGi/WoZJuGbu+DAECSwTVPh+Su5G+9I9vnq9sgYOnNPHQGgTQgch9xGQppSHeRoUGF5YdFllWT1+MZNy1Rzq+0ME12lMDom7XL1KDAbdg46E9uFDupK6nxfi1UgFkH+CFCEi4Sn3jKJXkv5XjdttoFTi5p+mJmKdMcouXMr0f511Sj7qX4i8WY19TQUrsr65VRxC0dpgM3TlwBBX0LqJEJwZ4DxYlTOVsxk2eFrrqWU4POsHJXj+BNSLCE2Co0vXwBbqRY2AhsmchS0PFIQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0133; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:OS1PR01MB0133; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0133; X-Forefront-PRVS: 07349BFAD2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(199003)(479174004)(24454002)(377454003)(189002)(81156007)(42186005)(101416001)(83506001)(5001960100002)(122386002)(64126003)(189998001)(4001350100001)(5004730100002)(77096005)(40100003)(5008740100001)(74482002)(2950100001)(5001770100001)(50466002)(106356001)(5007970100001)(15975445007)(65956001)(50986999)(19580405001)(97736004)(64706001)(46102003)(66066001)(23676002)(86362001)(105586002)(54356999)(65816999)(87976001)(16799955002)(33656002)(76176999)(19580395003)(92566002)(65806001)(47776003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0133; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:3; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTMzOzIzOkZrUVlHQVB5cXh4YXdvT3hjdzZMajRaSG9i?= =?utf-8?B?ZDNSK2dnY2ozZ2VxTkpobzUzUFRRMG5RZTBnNHM4REdlTWlJbXVrM0Z4UWFU?= =?utf-8?B?akk2NTVFcmhvSDEyM0JYbHd6SjErRnFPWDBzc1Q1RGpiRXJxUzZURFhURTZV?= =?utf-8?B?YVhMd3l3cS93ZkhSRzdiNDdHMkJLRzd0b2VSTjNZMUVpWmVrdGVEQUtTMG5Y?= =?utf-8?B?UjRiU1l6S0U1bC9rRkNVWDJHMVljclZQdkpaNWk3WFdiRWJJNWc0NWhtSXEz?= =?utf-8?B?MXZDMmdVWnMvbUZNMitPMk94NWZScHptdkRyMlVYRDhwOFFrZUNZNWxVclds?= =?utf-8?B?WDhkUFA0T05HaDVxTHlCUVBBYnkxVXdPanBsdzhoaFhuSExHa01TNjZkbjhT?= =?utf-8?B?bGZaZElIR3BOYmhmQjc3K3lWK3V6ZEk5TE5sbEt2TWJRdHZBV0FjK29yNVJW?= =?utf-8?B?Vnd0NkFuN1IyTHV3YU5xZzNrMnZwdmxhb0trUGdTT3ppMHhMejQzVkRJUDFK?= =?utf-8?B?azhIR3RqVmZqOGU0bzM3TVFocGFZcXBZM0x4eXVwQ1RFekZIMFRwS2JNVit2?= =?utf-8?B?WXJsS2hOSjIrK3JVSWtGS1ZLNThSTHhnTUFOK2JqOWd3VHRYQ2xqVzBIMklO?= =?utf-8?B?dkR5ZitvS1YzeEE1MXN5UlhhNUdLa3I1d2cxUkUycDNSYmcvaDZuTUxoMHgx?= =?utf-8?B?dXlML3RyUVRPaXNxckt2UHpNd0FEUVJ5UXZETGkrY0JjUEw0aVY3WE00TUdE?= =?utf-8?B?MldtUDUzWnU1YThZRnRUU0MvY0xrQzNxVkR6ZUQrMkVSTjU4bzVjck9SNC9E?= =?utf-8?B?RlRjald3TjBSM1FTN1E0SEJPKzlySXI5bVZFdUNpMkR2S1c2Vnl0Z3A5RVJQ?= =?utf-8?B?ckZLd1JFZnVBbFhneU5GZG9FSHFJU1lDYk5wV3JFMWh2WWJQMno2VGgxNjhh?= =?utf-8?B?RzBoenQ0ZWVobmlLUHhGVU1aR1BkejJkNkp5WUVyYWdmU1ZyMTlHNlRlSjlr?= =?utf-8?B?Skg3VXRwbXlKckR3d1ZyZGVoNlJMQXhlajkxUzJTRllZSnNPWEw0SVpIUXEx?= =?utf-8?B?R283bVZtYmZra1B0bVRWaDdqaGFSa1hHZlVqU3QxOCtHMlBGcVUvdmxYVlIv?= =?utf-8?B?eGYvTitBN1hUTU5EYk1VVWVjekhMYnp0K3RTbzFmNjJmMGJSYUVzaVRDakl0?= =?utf-8?B?MmFkRVNNRndhanNuRUVxV0k5dm1JZUtCakFvSEs5Ukt1TldEWXlRUTd6VHFV?= =?utf-8?B?M25tZEQ1WG56K1J4anhhbXRuSUI5TTFOK29IWTBGZmlnN0xLL3dLWFN4amRQ?= =?utf-8?B?RkpMNlBVOHlQd2lmb0ROdk9HenZxNVJ3ZElCcVdYTS9uT1FXOWtFUFJZaUhY?= =?utf-8?B?eG55bkQveExGbzdraU50UFluZFpkWC9aY2xIUGZma2dLZ0hiRnlBZmFNVHFz?= =?utf-8?B?ZlBMNHpPSHBiR1Bzc1ZMSVpnVlpoL2tvQ0g1UGRnRkJIa0pyV3VvZy9kRjQz?= =?utf-8?B?SGs0V2lJV0dYbFczRnQ4cG1Ec2U5MHhZcXRzYkJTSExXTFJxbUNrVlE4akZM?= =?utf-8?B?bVY1YTNIcStudFRGYkg0SmRiaTBNWDdwSU1XZ21qZmVycmpCU3dEaThKZjVp?= =?utf-8?B?WklabmxIK1FXWm9mRFFuaFJIczlZYW93M1FpazdKd0lHelAvNU1HMmhiaFNZ?= =?utf-8?B?OWpBYnZ6SU9aa3NyY0tyT1J1U0tCSit5U1NRZTN4Y3JkRjNWTE1oNTQ0WFMr?= =?utf-8?B?N1dHOTd1cGQ1NGFsK3FTQT09?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0133; 5:C9l2HRPD8aamcpTakWD5bSiW8mJoe6lbwWMMNFhAWNjoLL//NsmwR5sK6Z9bZLNGR+vmfOT2HRv1heyTtXdM5d0XsG2ISEPzPqZdGaba5e4NEcVfTqHR+buZmVzZeGCGjVezIfyo40t+9S/JTinZxw==; 24:ILKtNr5Forb8MitAKtgxfDhVMcsXVRkLh5hXlHFaKcm5FcXaWb1JTpPMOfGIXFGGZIVAvojlJYuIsy1kCn/YUTFznPS4XOqO97XfhxJmqm8=; 20:9nRr9LHif+PScYNfWWE5TBHfmhWZmo300zndHihVM9wSTGr/19ByGE2i2GdbaMX1vc8GbnSa6O0TEhTjLGqK+A== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2015 04:16:45.0146 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0133 Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 04:16:53 -0000 Hello Tim, I suggest to send it directly to the relevant mail address (internet-drafts@ietf.org, see https://datatracker.ietf.org/submit/), i.e. to use the old way of submission. In your mail, explain the circumstances and cc. the chairs and Barry (AD). Submissions per mail are still accepted, and are handled manually, so this should work (as long as you stay within the deadline and Barry confirms). Regards, Martin. On 2015/10/19 11:49, Tim Bray wrote: > It’s not letting me submit the draft because it claims that: > ============ > JavaScript Object Notation > Group exists but is not an active group > ============ > I’ve uploaded the XML & txt & HTML to http://www.tbray.org/ietf/7159bis/ - > if someone else knows how to work around this go ahead, otherwise I could > upload it as an individual submission. > > > On Tue, Oct 13, 2015 at 7:03 AM, Barry Leiba > wrote: > >>> In a nutshell, the goal of this effort is to produce a bis to 7159 that: >>> >>> * promotes JSON to IETF Internet Standard >>> * references ECMA-404 and is a reference for ECMA-404 >>> >>> Tim Bray has agreed to edit 7159bis. >>> >>> As a start, I propose we start with rfc7159 and: >>> >>> 1) Apply verified errata from < >> https://www.rfc-editor.org/errata_search.php?rfc=7159 > >>> 2) Change the reference to ECMA-404 from informative to normative >> >> Can we get a first version of this before the I-D cutoff for Yoko >> (this coming Monday, 19 Oct)? >> >> Barry >> > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Oct 19 00:49: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 5F0AF1A6FA8 for ; Mon, 19 Oct 2015 00:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VgwRCLqS3x2C for ; Mon, 19 Oct 2015 00:49:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 AF0021A6FA6 for ; Mon, 19 Oct 2015 00:49:28 -0700 (PDT) Received: from [192.168.178.20] ([84.187.52.81]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MNHqL-1Zuz5U3l1t-006sLa; Mon, 19 Oct 2015 09:49:22 +0200 To: Tim Bray , Barry Leiba References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> From: Julian Reschke Message-ID: <5624A07E.1000409@gmx.de> Date: Mon, 19 Oct 2015 09:49:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:G9Hby8FvnzpZigHcayeq/3/NgjZ3UJvwHnAolZfGP+/ygEqbwlg gD8N9FFQrOEjBbk3j13pAa7hTnluSNjx3RWEoR6DIQ2Uy/Rf9d3mneot9063rUYolZYFjIU IYuL1Wg/KWf/wnMeH5xKMFUbCyurcOgh0lXMl8o+ks1bKXRVGy7w1deuGDTRJDkpipc86VY 8b5W7L+XGfWgElbjB//3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:NJCN1I6lUHI=:vnCeIJTyWpu0h8pn+U/FCE V3A6O7os+b7iylTIEyPgPm2YqWTfYA9u/SFmy+qK1msxETfjmruHuGNdvJLJJdYEcOJBgxeqD Tqd4b6yW78yn84Io320OBqBf5YQ7CkclI8tIA1fxdWef7qsavT43BQ7WsSXTkAOxCDW8Ae0aj VV3Q3kAjNaMSroYhetbdkE6AKh9MKoggddi0waiVrJ3zujMIpF+BIgPpMl1/WLBaZIPGMbBEJ OAmVxbMg6baLtypi/4KJE4GTmCS/L7f1/XbbSyBW4XrWtJBRoCy4K21TVKA6IKqcGipOmKKVe ze2SDSSe5DZ0z0ECnshRyHWn6lqlsnDd5JqNqLAyUcwF6OLcPLr+Bdw6Ko7mlEvqq4aRtKnpW mHJYmD46J/5LBZ8QR5z5VVUGX46zJHd1OgMCtZChUjy/u6Vj6GxBylCmN7WVD9MJTdtsOHwI2 Fy7TiiCdzfiymWcGgqwyTrEGQ37z4w58e10Zygey4bOKpsweNHbG1UVhDkRlzkrMyPscGSJ0w dg9yAb8Br1nMhe41uhJs3iRD3LxnWCNxYdgDYhg4/tuLbuFyhSk0yxDGVAXs7aRd4oHexlWdl jJuSeihGBXxlBPpwLSt+I7KBl0QiGUl0pAjXmzHCMciL5LSqJqJ2a7sOF432yhdhmSGp+CbD0 TkwkFjChIGgqe+3zsHNOLj6S/ghN1Pt0Rd8uII1fj4wVKbiF1QAPyMuqwCleCx42DUJ0Fcq/e CbWIrA1IONZ+28gw1hmYVwTNl6WqaM7wtgF51iXWNH9o5yo3T80TNdiYv+42Jeu56dLKFrwf1 TWQCHcm Archived-At: Cc: "Matt Miller \(mamille2\)" , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 07:49:30 -0000 On 2015-10-18 20:34, Tim Bray wrote: > [I'll post a 7159bis with errata by end-of-day whether I get an answer > on the errata-wonkery or not. Now, returning to the meat of the > discussion.] > > I have really major heartburn with introducing a Normative Reference to > ECMA404 in 7159bis. Because language in standards documents should be > used carefully, and “Normative Reference” has a very specific meaning, > and that meaning clearly does not apply in this case. However, since Exactly. > there is apparently a feeling that there is some benefit to the > community in achieving “standards harmony”, let me propose three ways > forward: > > 1. Include a normative reference to ECMA404, but accompany it with text > explaining that this reference is marked normative because it is > considered authoritative in the community of JavaScript language > specifiers, not in the normal sense of “normative”; there is no > necessity to read it in order too understand or implement RFC7159bis, > nor does it specify any technology which must be present in an > implementation that is not also described in 7159bis.” Sounds good, but we'd probably also have to talk about what it would mean should both documents disagree. > 2. Do not include a normative reference, but expand the note about > ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered > authoritative in the community of JavaScript implementers. Works for me as well. > 3. Conclude that this effort has no observable benefit to the community > implementing JSON on the Internet and abandon the RFC7159bis project. I believe it's worthwhile to apply *other* errata and publish as full standard, even if we can't achieve "harmony" with ECMA404. > ... Best regards, Julian From nobody Mon Oct 19 02:51: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 A65161A8849 for ; Mon, 19 Oct 2015 02:51:13 -0700 (PDT) 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 CFM3SU-23DQr for ; Mon, 19 Oct 2015 02:51:11 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 1F0801A8846 for ; Mon, 19 Oct 2015 02:51:11 -0700 (PDT) Received: by qgad10 with SMTP id d10so58655162qga.3 for ; Mon, 19 Oct 2015 02:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=r6d2kk0cZSWvcLq1Ooi/f9B4wSRmibwyeqcNf4el2FQ=; b=0DWvWB1Mos7k0Phr/0CqjWRXLmri7W7twz4GgWOaJj8/zVGK8aklzE+/wMdL4g5ERg DmqRWVyvwnvA9kG1wSNu35vQrGyPQVHSV7FbAPc6hwtp+OGiHDI9ztj8HbidPMoI4sOD YqEzW6O5pAwr71P378TDJMWjzmqK+uD5FfyV6PsaHXsvLoHdo/AX1W6OkFuRNS/1DBPh vlgbNhXJO4FpLhPav2x+/JasNT/2rdcBdztZa1pfsPcldbqBFMrzJ9/xtmGsXojZLPVD 9k+ghLWZlIbqVSOaDz2SA9Rut6QbGdVpFu7xtKhetWpP4Nefd3DcmYsVUDlRoypatNq6 6E+Q== X-Received: by 10.140.218.84 with SMTP id o81mr21572194qhb.22.1445248270188; Mon, 19 Oct 2015 02:51:10 -0700 (PDT) Received: from idefix.nuance.com ([199.4.160.88]) by smtp.gmail.com with ESMTPSA id 68sm13980706qgy.16.2015.10.19.02.51.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 02:51:09 -0700 (PDT) To: Rob Sayre , Tim Bray References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> From: "Peter F. Patel-Schneider" Message-ID: <5624BD09.5030301@gmail.com> Date: Mon, 19 Oct 2015 02:51:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 09:51:13 -0000 On 10/18/2015 08:13 PM, Rob Sayre wrote: > On Sun, Oct 18, 2015 at 4:32 PM, Tim Bray > wrote: > > Thanks, Carsten. My belief is that ECMA404 meet neither of those criteria. > > I also believe, based on prior conversation, that the goal of this WG has > nothing to do with with changing the meaning of RFC7159, but rather is > aimed at “standards harmonization”. While I’m unconvinced of the benefits, > if there’s IETF consensus behind such harmonization, I wouldn’t stand in > the way. But I would hope that there’s a better way to achieve it than > with a flagrantly bogus normative reference. And I’ve suggested a couple. > > > ECMA404 should be a normative reference. > > - Rob Please explain your reasoning behind this. Do you believe that ECMA404 meets the technical requirements for being a normative reference for RFC7159bis? peter > On Sun, Oct 18, 2015 at 3:23 PM, Carsten Bormann > wrote: > > Rob Sayre wrote: > >> “Normative Reference” has a very specific meaning, and that meaning > > clearly does not apply in this case. > > > > That conclusion is not clear to me. Can you explain? > > I'll leave explaining the conclusion to Tim, but here is the premise: > > https://www.ietf.org/iesg/statement/normative-informative.html > > In particular: "Normative references specify documents that must be read > to understand or implement the technology in the new RFC, or whose > technology must be present for the technology in the new RFC to work." > > GrĂĽĂźe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > From nobody Mon Oct 19 05:21: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 24B671A0470 for ; Mon, 19 Oct 2015 05:21:51 -0700 (PDT) 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 eOVjVF_IP0Ci for ; Mon, 19 Oct 2015 05:21:50 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 CB8261A039D for ; Mon, 19 Oct 2015 05:21:49 -0700 (PDT) Received: by wicll6 with SMTP id ll6so2927262wic.1 for ; Mon, 19 Oct 2015 05:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=RCwnWpcw6Q3EFVFvryaucx575Nqa8+cqnW5jwIG9XYc=; b=i8hvyISnzvJEaORBusa6OoxtQl4q/V4P88aySSXQE052b1oJpxNW3UzQSOlzWQ4Hoe RsXIM0WyMhrOajHJLVcckktmVcQR3Lep7GMwulnylyjKHLozvCmoP3+2IQgEhOx4In8y sV8Z4/gR1Uepn12a0x0sMI3zv73/p3bose92MwndgSm63ONffLfU8GPJ8wm+02UA0eI9 YXJdHpFRUQLcF8LUEHIOn0C7mdNt8lGc14SkAJiYTi4VOjZWw569EDTz9t7KulXfVqcb ujRquGyLiXpUae3M1IM+niXnAbBJV/Q+SV5sZCMiBghvJYeQfB61kPsRIsIBg+gloEvJ foQA== X-Received: by 10.180.198.174 with SMTP id jd14mr11645597wic.2.1445257308452; Mon, 19 Oct 2015 05:21:48 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id gl7sm28309801wib.1.2015.10.19.05.21.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 05:21:47 -0700 (PDT) To: "Peter F. Patel-Schneider" , Rob Sayre , Tim Bray References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <5624BD09.5030301@gmail.com> From: Anders Rundgren Message-ID: <5624E056.7070803@gmail.com> Date: Mon, 19 Oct 2015 14:21:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5624BD09.5030301@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 19 Oct 2015 12:21:51 -0000 It is a bit sad that you are more interested in solving a problem that maybe only 0.001% of the development community is likely to know about, when the JSON tool feature "Predictive Serializing" is fairly easy to find requests for, in addition to addressing "Signed JSON" in a more useful way than the ugly hack the JOSE WG is currently adding to JWS (due to the obvious push-back on dressing everything in Base64). Anders From nobody Mon Oct 19 08:39:36 2015 Return-Path: X-Original-To: json@ietf.org Delivered-To: json@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A98BC1ACE02; Mon, 19 Oct 2015 08:39:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019153935.25817.62458.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 08:39:35 -0700 Archived-At: Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-jsonbis-rfc7159bis-00.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 15:39:35 -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 Update Working Group of the IETF. Title : The JavaScript Object Notation (JSON) Data Interchange Format Author : Tim Bray Filename : draft-ietf-jsonbis-rfc7159bis-00.txt Pages : 15 Date : 2015-10-18 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jsonbis-rfc7159bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-jsonbis-rfc7159bis-00 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 Fri Oct 23 05:29: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 611611B359F; Fri, 23 Oct 2015 05:29:53 -0700 (PDT) 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 eUYyx3WZj8R3; Fri, 23 Oct 2015 05:29:52 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 D43DC1B359E; Fri, 23 Oct 2015 05:29:51 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so29114975wic.1; Fri, 23 Oct 2015 05:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=omjMwgNfkDdpLQXHjRNNWTmNCXS6NOAahuVw8txYFzQ=; b=Oy6cRTlnOQzqfqtDmRiXyHJyVXtWnsCnujGD96n/7COH+NGv70RwtcT4nBwjzlnVdw m8PvAvOPSSWDXFqs+Sypd0FfOW1KxYNp4qPvVMSFLM1XUo6IQBYz6YrgmDPAL+TMbUdw iwuZNxV4Ai4GA3OfkHaFgMPN8gX+Gv43wZK/W+v0SRpwLs7mhoQpSu/0J4gyjwQYW2fo PsyVyB6spMgMzdhaY8ODrAS/uex0hrYXE5ik3vY+CRr2ZXjQLKCt84KUqvv23QVnj2s/ aDum2YPqR3FnkInPzWQ968UWEzQsAmCyiO8oiovKVhWCU0wW3qieEV2Q5pPFnzcrJ1VZ vK8w== X-Received: by 10.180.74.177 with SMTP id u17mr4524289wiv.5.1445603390464; Fri, 23 Oct 2015 05:29:50 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id m6sm2838286wif.11.2015.10.23.05.29.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 05:29:49 -0700 (PDT) From: Anders Rundgren To: "jose@ietf.org" , "json@ietf.org" Message-ID: <562A283C.40703@gmail.com> Date: Fri, 23 Oct 2015 14:29:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] draft-rundgren-predictable-serialization-for-json-tools-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 12:29:53 -0000 Since the I-D submission service is closed until the IETF F2F is finished, I took the liberty sending this draft directly. http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.txt http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html Anders From nobody Sun Oct 25 02:08: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 0B95A1B2CBB; Sun, 25 Oct 2015 02:08:53 -0700 (PDT) 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 xkXsAFOYnW21; Sun, 25 Oct 2015 02:08:51 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 99B811B2CBA; Sun, 25 Oct 2015 02:08:51 -0700 (PDT) Received: by wikq8 with SMTP id q8so126739125wik.1; Sun, 25 Oct 2015 02:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=xaZAXxDFfMuF0ZaUmsGPssMJ8RBGY1qyCEGs6xMqVvI=; b=hZWIstj+oBTHI1zWtA7uUYxPT2zs4SlornkPEGX0gym4qj6uoYCAt6KnouE7on68Fm 0QXHznTn4Ex37zt+MWLCmy4NapHAbTgIbVi7OFbPmeHnWjZSahyDLePFCZmBQEykMdBP /p0M4kbNskXyB+sKVejbbJ+1sr4qsOzUUKODMviMGCfybmGkVp+T3L3Zuy1BxAQ8vSwr 4i0Q8G1TrCD4lkAUfNoz2MDNo2NEHkxNF/47+0I4lywfseRJuClsH8mcFVE+w/YEdeO6 KFofa39Z9Nn75+WwhunXKtcgr366K/0SqKkzN5rVrQxmwJnv0DbgQnTlk1w9bGnSN7qs xj3w== X-Received: by 10.194.89.40 with SMTP id bl8mr7861071wjb.107.1445764130190; Sun, 25 Oct 2015 02:08:50 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id gd11sm9496699wic.20.2015.10.25.02.08.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2015 02:08:49 -0700 (PDT) To: "jose@ietf.org" , "json@ietf.org" From: Anders Rundgren Message-ID: <562C9C1F.6020507@gmail.com> Date: Sun, 25 Oct 2015 10:08:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] EcmaScript V6 - Defined Property Order X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 09:08:53 -0000 http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations: - Integer property names doesn't work. - Numeric values would have to be normalized. Java, Python, and C# already manages this as well. Yay! Anders From nobody Sun Oct 25 08:32: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 C89F71B3057; Sun, 25 Oct 2015 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 Uw03uZ8bhZ5u; Sun, 25 Oct 2015 08:32:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 4270D1B3058; Sun, 25 Oct 2015 08:32:41 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so85507403wic.0; Sun, 25 Oct 2015 08:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=RI61SlPE8BjOyeFkIaF194ZdvJdsi+DJ2iDg+p/vTyo=; b=RMKYmyo0pQvfBlUJjcjUTETGf8YPuae+w1ruj7sYoZ39/9JkNMYft38Xv7yZia3km6 YY3DF8GM23IRs1QtdLOmKyoAEj2R9aS3PuyNKzALStqJG59pRB9h4yoYIsrj0cc1FClT 7akz1yZYNvqXYTTVxfJe2fpC6SMMv8Ovj+1ueluwxNH4nLwG8iZM9Vk2JWYCe8YZaBHD 2RT3bf91lT4EOzmiuS6nY2C094ipNRgGZKUjX2w8o8+20zHv3T9A6SGn0UMoV6SzqWLW D68jc6r+mTdKORNDeSDuqAGmrUIaxxgZj5p2wylj9HS/cyK7dYSS8j9Ip5KnezZ5k9R/ Iqow== X-Received: by 10.194.91.164 with SMTP id cf4mr15229417wjb.139.1445787159589; Sun, 25 Oct 2015 08:32:39 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id gl4sm34062495wjd.49.2015.10.25.08.32.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2015 08:32:38 -0700 (PDT) To: "jose@ietf.org" , "json@ietf.org" References: <562C9C1F.6020507@gmail.com> From: Anders Rundgren Message-ID: <562CF614.4020200@gmail.com> Date: Sun, 25 Oct 2015 16:32:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562C9C1F.6020507@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] EcmaScript V6 - Defined Property Order X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 15:32:42 -0000 Since the ES6 Number type is 64-bit IEEE, there's no need to worry about number canonicalization either if you base the signature system on ES6 which seems like a pretty safe bet. http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-applied-to-the-number-type That is, AFAICT, clear-text in-object JSON signatures are already compatible with ES6 (and I must drop my "number preservation" stuff...). Folks working with constrained devices will probably settle for CBOR. On 2015-10-25 10:08, Anders Rundgren wrote: > http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys > > I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations: > > - Integer property names doesn't work. > - Numeric values would have to be normalized. > > Java, Python, and C# already manages this as well. > > Yay! > > Anders > From nobody Sun Oct 25 16:10: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 2210A1B3346 for ; Sun, 25 Oct 2015 16:10:47 -0700 (PDT) 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 VkI_ehryMKXv for ; Sun, 25 Oct 2015 16:10:45 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 223F71B3344 for ; Sun, 25 Oct 2015 16:10:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.20,198,1444654800"; d="scan'208";a="34669436" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Oct 2015 10:10:41 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,7965"; a="331556597" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 26 Oct 2015 10:10:41 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 26 Oct 2015 10:10:40 +1100 From: "Manger, James" To: Anders Rundgren , "json@ietf.org" Date: Mon, 26 Oct 2015 10:10:37 +1100 Thread-Topic: [jose] EcmaScript V6 - Defined Property Order Thread-Index: AdEPOmjXLZmwIwhmQxSI92S/9J0VkwANwI1w Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com> References: <562C9C1F.6020507@gmail.com> <562CF614.4020200@gmail.com> In-Reply-To: <562CF614.4020200@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Json] [jose] EcmaScript V6 - Defined Property Order X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 23:10:47 -0000 Hi Anders, I agree that the EcmaScript string format for numbers is a better basis for= a canonical JSON format than, say, normalized scientific notation - partic= ularly for the dominant case of integers less than 2^64. However, EcmaScrip= t's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5 s= ays "the least significant digit of s is not necessarily uniquely determine= d by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) give= s the same number x, but that is not quite what we need for signing. We nee= d ToString(ToNumber(s)) to give the same string. I guess you could sign the= 8 bytes of a 64-bit float, instead of the JSON decimal digits. James Manger -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren Sent: Monday, 26 October 2015 2:33 AM To: jose@ietf.org; json@ietf.org Subject: Re: [jose] EcmaScript V6 - Defined Property Order Since the ES6 Number type is 64-bit IEEE, there's no need to worry about nu= mber canonicalization either if you base the signature system on ES6 which = seems like a pretty safe bet. http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-appl= ied-to-the-number-type That is, AFAICT, clear-text in-object JSON signatures are already compatibl= e with ES6 (and I must drop my "number preservation" stuff...). Folks working with constrained devices will probably settle for CBOR. On 2015-10-25 10:08, Anders Rundgren wrote: > http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-ob= ject-internal-methods-and-internal-slots-ownpropertykeys > > I can't say I'm able "deciphering" the ES6 specification but it seems tha= t the largest base of JSON parsers (the browsers), now are compliant with i= n-object JSON clear-text signature schemes of the kind I have proposed (pus= hing maybe...), albeit with some (IMO for practical purposes insignificant)= limitations: > > - Integer property names doesn't work. > - Numeric values would have to be normalized. > > Java, Python, and C# already manages this as well. > > Yay! > > Anders > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Sun Oct 25 16:25: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 721FE1B335D for ; Sun, 25 Oct 2015 16:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_35=0.6, 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 uKF0x43fztQV for ; Sun, 25 Oct 2015 16:25:37 -0700 (PDT) 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 0B3251B335B for ; Sun, 25 Oct 2015 16:25:37 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1ZqUfK-0005QJ-VL; Sun, 25 Oct 2015 19:25:31 -0400 Date: Sun, 25 Oct 2015 19:25:30 -0400 From: John Cowan To: "Manger, James" Message-ID: <20151025232530.GK22559@mercury.ccil.org> References: <562C9C1F.6020507@gmail.com> <562CF614.4020200@gmail.com> <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "json@ietf.org" , Anders Rundgren Subject: Re: [Json] [jose] EcmaScript V6 - Defined Property Order X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 23:25:38 -0000 Manger, James scripsit: > However, EcmaScript's ToString(number) doesn't quite give a canonical > form. 7.1.12.1 step 5 says "the least significant digit of s is > not necessarily uniquely determined by these criteria". EcmaScript > guarantees that ToNumber(ToString(x)) gives the same number x, but that > is not quite what we need for signing. We need ToString(ToNumber(s)) > to give the same string. The Scheme community has for many years prescribed the use of read and print (i.e. decimal-to-binary and binary-to-decimal) algorithms that are fully accurate. They are also slow, but for the limited purpose of canonicalization, they might be employed. A summary can be found at , with links to the original papers. > I guess you could sign the 8 bytes of a 64-bit float, instead of the > JSON decimal digits. That would be hard to do in JavaScript. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org There was an old man Said with a laugh, "I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two." --Emmet O'Brien From nobody Sun Oct 25 22:15: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 EAAF71AC447; Sun, 25 Oct 2015 22:14:57 -0700 (PDT) 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 kLlhdMbdBYnk; Sun, 25 Oct 2015 22:14:56 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 E0E2E1AC425; Sun, 25 Oct 2015 22:14:55 -0700 (PDT) Received: by wikq8 with SMTP id q8so147621810wik.1; Sun, 25 Oct 2015 22:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=OFs7LkpGk1vTHC2meYwOEAfTP9atl/x53Yma6raa2ow=; b=QQqAUOOwtMhJnFRoeKDAmpJedKiebY6LKCcCPzH7HQSoFv5VNpsRJ6GnTM4vdnzeZf xPIJ4IL6hBDrijpuFy/cUBHPEhuCCSNR4JUZibM5iB5WiSzU4ywViZI6TrlArr6P8Vuu OMeInwKUIMCPvmXTo0sdYltZPIA46nbz3r0hbmOZfXXSKVV50j5mGwDbjRuJ6iVtShXL KDckzp3FzutokhCS+m72RKAQNnI4Og6hCTJ48Z/K4WXYLbd1uG6AsRm+hyQ9eLBSgNsu s3ZsQVQuf1i95cGdnYSWWS8IBoXABeNlmlFC5qOrImi/BHPUEMHKPwIIKIfq48usLnKc YwMA== X-Received: by 10.180.10.5 with SMTP id e5mr12097996wib.56.1445836494360; Sun, 25 Oct 2015 22:14:54 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id ki7sm36802186wjc.28.2015.10.25.22.14.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Oct 2015 22:14:53 -0700 (PDT) To: "Manger, James" , "json@ietf.org" , "jose@ietf.org" References: <562C9C1F.6020507@gmail.com> <562CF614.4020200@gmail.com> <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com> From: Anders Rundgren Message-ID: <562DB6CA.6070904@gmail.com> Date: Mon, 26 Oct 2015 06:14:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB107BC65@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] [jose] EcmaScript V6 - Defined Property Order X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 26 Oct 2015 05:14:58 -0000 On 2015-10-26 00:10, Manger, James wrote: > Hi Anders, > > I agree that the EcmaScript string format for numbers is a better basis for a canonical JSON format than, say, normalized scientific notation - particularly for the dominant case of integers less than 2^64. However, EcmaScript's ToString(number) doesn't quite give a canonical form. 7.1.12.1 step 5 says "the least significant digit of s is not necessarily uniquely determined by these criteria". EcmaScript guarantees that ToNumber(ToString(x)) gives the same number x, but that is not quite what we need for signing. We need ToString(ToNumber(s)) to give the same string. I guess you could sign the 8 bytes of a 64-bit float, instead of the JSON decimal digits. Hi James, Thanx for pointing out this, it is apparently always a very good idea testing concepts with other knowledgeable people before you actually start building something :-) I guess the ES committee wasn't entirely happy about having to adjust their spec. due to improper reliance on JavaScript property order by parts of the development community. But they probably did the right thing. I'm thinking in a similar way. Why let an edge-case spoil all the fun? Maybe the ES6 vendors implement the same broken ToString algorithm or the improved version mentioned as a note after the section you referred to? I won't research this issue now because I consider Ecma the sole "owner" of this problem :-) So this is my (latest) suggestion for an upgraded in-object JSON clear-text signature specification: "Due to limitations in the EcmaScript V6 [ECMA-262] specification regarding the ToString(number) method, it is for interoperability reasons RECOMMENDED to utilize a maximum of 18 digits of precision for non-integer Numbers." It sure isn't pretty but since "business messaging" can't even use JSON/ES numbers for expressing monetary amounts, it is hardly a show-stopper. Anders Rundgren > > James Manger > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren > Sent: Monday, 26 October 2015 2:33 AM > To: jose@ietf.org; json@ietf.org > Subject: Re: [jose] EcmaScript V6 - Defined Property Order > > Since the ES6 Number type is 64-bit IEEE, there's no need to worry about number canonicalization either if you base the signature system on ES6 which seems like a pretty safe bet. > > http://www.ecma-international.org/ecma-262/6.0/index.html#sec-tostring-applied-to-the-number-type > > That is, AFAICT, clear-text in-object JSON signatures are already compatible with ES6 (and I must drop my "number preservation" stuff...). > > Folks working with constrained devices will probably settle for CBOR. > > On 2015-10-25 10:08, Anders Rundgren wrote: >> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ordinary-object-internal-methods-and-internal-slots-ownpropertykeys >> >> I can't say I'm able "deciphering" the ES6 specification but it seems that the largest base of JSON parsers (the browsers), now are compliant with in-object JSON clear-text signature schemes of the kind I have proposed (pushing maybe...), albeit with some (IMO for practical purposes insignificant) limitations: >> >> - Integer property names doesn't work. >> - Numeric values would have to be normalized. >> >> Java, Python, and C# already manages this as well. >> >> Yay! >> >> Anders >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Tue Oct 27 07:46: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 55C5A1A8AC1; Tue, 27 Oct 2015 07:46:15 -0700 (PDT) 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 0mcMZMnUDPtx; Tue, 27 Oct 2015 07:46:14 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 B2E4E1A8ABB; Tue, 27 Oct 2015 07:46:13 -0700 (PDT) Received: by wikq8 with SMTP id q8so215134325wik.1; Tue, 27 Oct 2015 07:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=4YmrKZgcg52srdx868IIaZJofvOl0qAhqbOLxLZIImw=; b=GkSCrqyaJyVANyqjo+Yy2u5sVvkgJNQ3lcvdsqUPap8WALZASQ3z4THkUQQCHnWsdg rFTj6tKstLSjzWj0kv8b+ftEDUJcAwpS2aCQc3/KsRsMhC0shjgYnxm8qYFQK/uBj1+Q 3BLByS63PipD1UOTJE2tsCTSliUazwKxgIyZVNNsmM2S1Q9BRy1YIuqZCejLwTbfNH4y cXtFnijmCu3Li/rW4Awd7ekhFCCqEGEQJBIqjgDck7OlbUcZ3nEy1Mw9FA8h9b/N+RXt ovGRTamqeQcAJpMB+KxrpymwfIKgjNhBFCfX6GVturf3XZOmRelyjglZ52PADhfJ9JzV xrAg== X-Received: by 10.180.85.134 with SMTP id h6mr29145444wiz.75.1445957171951; Tue, 27 Oct 2015 07:46:11 -0700 (PDT) Received: from [192.168.1.79] (148.198.130.77.rev.sfr.net. [77.130.198.148]) by smtp.googlemail.com with ESMTPSA id pi5sm18048986wic.3.2015.10.27.07.46.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2015 07:46:11 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" , "jose@ietf.org" Message-ID: <562F8E2F.7050605@gmail.com> Date: Tue, 27 Oct 2015 15:46:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Update: Signed JavaScript/JSON Objects using ES6 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 14:46:15 -0000 I believe the following (thanx to James Manger...) should be correct: http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html#rfc.section.3.3 I have used this scheme (modulo floating point) in practice for more than a year with all the major browsers without any hiccups but now it feels much better since the "black magic/guessing" is gone :-) Anders From nobody Thu Oct 29 04:26: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 72FA71A897C for ; Thu, 29 Oct 2015 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 5pEkIyYlBSMJ for ; Thu, 29 Oct 2015 04:26:32 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 361E51A6FEA for ; Thu, 29 Oct 2015 04:26:32 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so224605100wic.1 for ; Thu, 29 Oct 2015 04:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr_us.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=Yf5rseNZBpqT6nfNih9q5LbLRnQVthm0txbzg6b8r5Y=; b=UKaMoSAl+C7rKwe6RXPDyAEeUDOC9nrlC6F7YG7d7fPgacK3U1SXqacalDl54RLtwR ao5Cdp5udF5rXlJMXcnPYUhxNUa/ek6CBKpBWXAZVd3xv9yNOURZrDHaHb7SPwz25ZM7 mdp/XiBINDVV1/8FM1Gt9wFoATnfOgO5sKw4ksgSyo4vP9urbI/i2i4OBYIsDCkPO28f SwgZ4Ls5h3u5eqbw7k0bkD3BnaII4L3N6tTbA4polaOWunsGxPe+0iVwt25r+yuyKjSq 6l/YslRt8JjT/w1uqGqH+2emj7Aj9gkuMcOVHZzI71d7EWIK4s8QaNCgRAbdBGQ9wYKE JAbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Yf5rseNZBpqT6nfNih9q5LbLRnQVthm0txbzg6b8r5Y=; b=CUFlPyY3+mem7QRDOFXCz318o4v9+IV/YCeDutn204eqlc/FepYtiK++BgQrzPEPMd 9xs/43GQue2+lJLqaQSyQEq3vec9ZXriyt5wlPAluj3ZT7ivnJgKO6zQ4V8sKAMyTtiR O+Vd2F5JrdpvrbaTMpPVjuVMCxRc3fr5nrY9e8BsbDCu1nQI2+WbMTI2v+zE5Qqj07ak hqziBXsfK3CqghwB6O5GIkFryoEf5V94dp6qWAxPzfqkNZL50U3Li4oOzzsTq7BN1gbU lZapoMfKA43pIqPHq9a9pVCZ++1uAYawfj3Y/EUbMosznzWlBDp2/rEGvzylU5AuRkjm xg2Q== X-Gm-Message-State: ALoCoQm+nN/+yWklAD5sqgglebmjuJo0VTzZoBUp9qRcaDsYX4yiZ9am6JlACqPT/saxPmV5tF+w MIME-Version: 1.0 X-Received: by 10.194.235.37 with SMTP id uj5mr1688658wjc.115.1446117990847; Thu, 29 Oct 2015 04:26:30 -0700 (PDT) Received: by 10.194.91.134 with HTTP; Thu, 29 Oct 2015 04:26:30 -0700 (PDT) X-Originating-IP: [96.241.188.13] Date: Thu, 29 Oct 2015 07:26:30 -0400 Message-ID: From: Andrew Newton To: JSON WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Json] JSON Content Rules -05 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 11:26:33 -0000 All, We've updated JCR to -05. (We meaning I now have a co-author, Pete Cordell) http://www.ietf.org/id/draft-newton-json-content-rules-05.txt -05 is not compatible with -04 because the syntax has been simplified and made more consistent and new features have been added, along with thoughts toward testing software and not just spec writing. We also have an issues list on GitHub: https://github.com/arineng/jcr/issues and two implementations in the works. -andy From nobody Fri Oct 30 19:43: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 C86351B32F2 for ; Fri, 30 Oct 2015 19:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, 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 KOm10J0nn3cy for ; Fri, 30 Oct 2015 19:43:18 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396BF1B32F0 for ; Fri, 30 Oct 2015 19:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1446259398; x=1447468998; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1eDvpP45GtzelBGKT5z0TTLGUyP4j0zsEvn0YLRH5/E=; b=WpP1MitvSZ13zq5AmvRKSI9hxWaC/h3uSbTMBVTO2b5pZnzsS/GmCxjr wDMX+2qjfJ1CbqCTvPnI2JHJINJBZ+Q9RrRAUoDIj8S2TByJlKPCPHCbH 5dr17A307iFiRDa2PE+OT7ktBz50dS4009X4yzqDtDNr9N3uF5YhJ4GZo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALAgBHKjRW/5BdJa1egztTbwa/LQENgVohhXgCHIEbOBQBAQEBAQEBfwuENgEBBCMRPRgCAQgaAiYCAgIwFRACBBOIMA2yRpEfAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIEihVWCEIJuhFyDHzGBFAWWQwGIDIUYgVmHY5J9AR8BAUKEBHIBhHaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,221,1444694400"; d="scan'208";a="203528844" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 31 Oct 2015 02:43:17 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9V2hHDk019920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 31 Oct 2015 02:43:17 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 30 Oct 2015 22:42:50 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.000; Fri, 30 Oct 2015 22:42:49 -0400 From: "Joe Hildebrand (jhildebr)" To: "json@ietf.org" Thread-Topic: [Json] Kicking Off JSONbis Thread-Index: AQHQ+wFMLqPttJCICkCj26yPdE/GxJ5p3bGAgADqgACAAAV+gIAAvKQAgAAJCoCABnHOAIAAPJKAgAADbwCAE6qGAA== Date: Sat, 31 Oct 2015 02:42:49 +0000 Message-ID: <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> In-Reply-To: <56241BFE.5080609@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.245.171] Content-Type: text/plain; charset="utf-8" Content-ID: <8E35F446418CA241A7E8D67112DCDA76@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 02:43:19 -0000 KFNvcnJ5IEkgZGlkbid0IGdldCB0byB0aGlzIHVudGlsIG5vdykNCg0KT24gMTAvMTgvMTUsIDQ6 MjMgUE0sICJqc29uIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4iIDxqc29uLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNhYm9AdHppLm9yZz4gd3JvdGU6DQoNCj5JJ2xsIGxlYXZl IGV4cGxhaW5pbmcgdGhlIGNvbmNsdXNpb24gdG8gVGltLCBidXQgaGVyZSBpcyB0aGUgcHJlbWlz ZToNCj4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9ub3JtYXRpdmUtaW5m b3JtYXRpdmUuaHRtbA0KPg0KPkluIHBhcnRpY3VsYXI6ICJOb3JtYXRpdmUgcmVmZXJlbmNlcyBz cGVjaWZ5IGRvY3VtZW50cyB0aGF0IG11c3QgYmUgcmVhZA0KPnRvIHVuZGVyc3RhbmQgb3IgaW1w bGVtZW50IHRoZSB0ZWNobm9sb2d5IGluIHRoZSBuZXcgUkZDLCBvciB3aG9zZQ0KPnRlY2hub2xv Z3kgbXVzdCBiZSBwcmVzZW50IGZvciB0aGUgdGVjaG5vbG9neSBpbiB0aGUgbmV3IFJGQyB0byB3 b3JrLiINCg0KVGhlcmUncyBhbiBhcmd1bWVudCB0byBiZSBtYWRlIHRoYXQgaWYgeW91IHdhbnQg dG8gaW50ZXJvcGVyYXRlIHdpdGggSlNPTiBpbXBsZW1lbnRhdGlvbnMgaW4gYnJvd3NlcnMsIHlv dSBzaG91bGQgcHJvYmFibHkgcmVhZCBFQ01BLTQwNC4gIFNldmVyYWwgb2YgdGhlIHBsYWNlcyB3 aGVyZSA3MTU5IHNheXMgImludGVyb3BlcmFibGUgaW4gdGhlIHNlbnNlIiBoYXZlIHNwZWNpZmlj IGNob2ljZXMgaW4gRUNNQS00MDQuDQoNCkNvbnZlcnNlbHksIHNlcmlvdXMgaW1wbGVtZW50b3Jz IG9mIEVDTUEtNDA0IHJlYWxseSBvdWdodCB0byByZWFkIDcxNTliaXMgaW4gb3JkZXIgdG8gdW5k ZXJzdGFuZCBzb21lIG9mIHRoZSBlZGdlIGNhc2VzIG9mIGludGVyb3BlcmFiaWxpdHkgYSBsaXR0 bGUgYmV0dGVyLg0KDQpUaGUgYXJndW1lbnQgdGhhdCB3ZSBzaG91bGRuJ3QgYm90aGVyIHdpdGgg NzE1OSBhdCBhbGwgd2FzIGRpc2N1c3NlZCB0aGUgbGFzdCB0aW1lIHRocm91Z2guICBFQ01BLTQw NCBvbmx5IHNwZWNpZmllcyB3aGF0IHRvIGRvIGluIGFuIEVDTUFzY3JpcHQgZW52aXJvbm1lbnQs IGFuZCBzb21lb25lIG5lZWRlZCB0byBzcGVjaWZ5IGludGVyb3BlcmFiaWxpdHkgZm9yIG90aGVy IGVudmlyb25tZW50cywgc3VjaCBhcyB0aG9zZSB0aGF0IGRvbid0IHVzZSBVVEYtMTYgY29kZSB1 bml0cyBvciA2NGJpdCBmbG9hdHMgYXMgdGhlaXIgaW1wbGVtZW50YXRpb24gc3Vic3RyYXRlLg0K DQpXaGV0aGVyIG9uZSBzaG91bGQgYm90aGVyIHdpdGggRUNNQS00MDQgaXMgb3V0IG9mIG91ciBj b250cm9sLCBhbmQgb3ZlcmNvbWUgYnkgZXZlbnRzLiAgQm90aCBkb2N1bWVudHMgZXhpc3QsIGFu ZCB3ZSBuZWVkIHRvIGVuc3VyZSB0aGF0IHRoZXkgc3RheSBpbiBzeW5jIGdvaW5nIGZvcndhcmQu ICBXZSBjb3VsZCBhZGQgYSBzdGF0ZW1lbnQgdG8gc2VjdGlvbiAxLjIgc3VjaCBhczoNCg0KDQoi VGhpcyBkb2N1bWVudCBpbnRlbmRzIHRvIGRvY3VtZW50IHRoZSBleGFjdCBzYW1lIGRhdGEgbW9k ZWwgYXMgZGVzY3JpYmVkIGluIEVDTUEtNDA0LCB3aGljaCBpcyB0aGUgbWFpbiBkb2N1bWVudCB1 c2VkIGJ5IEVDTUFzY3JpcHQgaW1wbGVtZW50b3JzLiAgSW1wbGVtZW50b3JzIHRoYXQgd2FudCB0 byBpbnRlcm9wZXJhdGUgd2l0aCBFQ01Bc2NyaXB0IGltcGxlbWVudGF0aW9ucyAoc3VjaCBhcyB3 ZWIgYnJvd3NlcnMpIGFyZSBhZHZpc2VkIHRvIGFsc28gcmVhZCBFQ01BLTQwNCB0byB1bmRlcnN0 YW5kIGFueSBwb3RlbnRpYWwgaW50ZXJvcGVyYWJpbGl0eSBjaGFsbGVuZ2VzLiBBbnkgZGlmZmVy ZW5jZXMgaW4gdGhlIG1vZGVsIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHdpdGggdGhhdCBk ZXNjcmliZWQgaW4gRUNNQS00MDQgYXJlIG5vdCBpbnRlbnRpb25hbCwgYW5kIHdpbGwgcmVxdWly ZSB0aGUgSUVURiBhbmQgRUNNQSB0byB3b3JrIHRvZ2V0aGVyIHRvIHJlc29sdmUgdGhlIGRpZmZl cmVuY2UuIg0KDQoNClRoYXQgbWFrZXMgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgdW5kZXJzdGFu ZGFibGUsIGFuZCBtYWtlcyBjbGVhciB0aGF0IHRoZSBJRVRGIGFuZCBFQ01BIGFyZSBwYXJ0bmVy cyBpbiBtYWludGFpbmluZyBKU09OIGdvaW5nIGZvcndhcmQuDQoNCi0tIA0KSm9lIEhpbGRlYnJh bmQNCg== From nobody Fri Oct 30 19:57: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 3A4A81B3300 for ; Fri, 30 Oct 2015 19:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 04xAdTudMJzD for ; Fri, 30 Oct 2015 19:57:54 -0700 (PDT) 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 0670D1B32FE for ; Fri, 30 Oct 2015 19:57:53 -0700 (PDT) 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 t9V2vkLN023304; Sat, 31 Oct 2015 03:57:46 +0100 (CET) Received: from nar.local (unknown [133.93.52.27]) (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 3nnlYP0ngqz2FS4; Sat, 31 Oct 2015 03:57:44 +0100 (CET) Message-ID: <56342E23.6000509@tzi.org> Date: Sat, 31 Oct 2015 11:57:39 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: <88A80A45-E673-4D0A-995B-3872874C23AE@cisco.com> <56241BFE.5080609@tzi.org> <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> In-Reply-To: <2DB105A8-AB80-4386-915D-D9AD1FBF77AD@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Kicking Off JSONbis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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 Oct 2015 02:57:55 -0000 I like that approach. GrĂĽĂźe, Carsten Joe Hildebrand (jhildebr) wrote: > "This document intends to document the exact same data model as described in ECMA-404, which is the main document used by ECMAscript implementors. Implementors that want to interoperate with ECMAscript implementations (such as web browsers) are advised to also read ECMA-404 to understand any potential interoperability challenges. Any differences in the model described in this document with that described in ECMA-404 are not intentional, and will require the IETF and ECMA to work together to resolve the difference." > > > That makes the normative reference understandable, and makes clear that the IETF and ECMA are partners in maintaining JSON going forward. >