From jsontest@yahoo.com Fri Aug 2 21:36:31 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41A311E80E2 for ; Fri, 2 Aug 2013 21:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DtsoX3KPQiv for ; Fri, 2 Aug 2013 21:36:26 -0700 (PDT) Received: from nm42-vm3.bullet.mail.bf1.yahoo.com (nm42-vm3.bullet.mail.bf1.yahoo.com [216.109.114.190]) by ietfa.amsl.com (Postfix) with ESMTP id 548B411E80DC for ; Fri, 2 Aug 2013 21:36:26 -0700 (PDT) Received: from [98.139.212.150] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 03 Aug 2013 04:36:25 -0000 Received: from [68.142.230.75] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 03 Aug 2013 04:36:25 -0000 Received: from [127.0.0.1] by smtp232.mail.bf1.yahoo.com with NNFMP; 03 Aug 2013 04:36:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375504585; bh=A8qUrkSMcdaPnSJyW1zqbbrj620DcZ4caXixwmv5s0s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=bECYhJRthtTRnbxa8+tbxRtcNfRiY2pnJ48H1vdkdfYsTZD8QhrJ/D+p30A75F1sLY4QBRQCCIey92MiaY7Ttw2tRTdW4QdjSP9BMmJGGZjmX/JwSpHUtWnFQPO+rOJvVRivU/I7sffDP5KUgQ9Avu//7rIJwZRzeEohQKCq/Zg= X-Yahoo-Newman-Id: 577576.52672.bm@smtp232.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: sbybWhcVM1mtejn4.4jU90y.zNm.BBTEm8dHK7NfjVurCMY O0dORS0v4hPHzVGcf6BcaqWjk6INQ08xAT7GoH6YjQq9GvjHe0SMTJ7PUVfQ Lai1XMFuYrvFJ0IyNV3rRrvNDM4GaLSlSJqEDY6MFTaw_YQZ.kyUXOrNeuoI vUbgkxWJKf1A2QgD4eG3KEQpSgSNkccGuVXX6AeC0SHSA42xn7ziWiLSjukU N5QQlfM0x7.2kgrslkdydLQtSlViwwXqDwRwiaMKpyIu10kqE7EVWSxbAglQ BI1sjXgK.GJ6h.wN8uk3t2A5ta3jZWkr4zdDBMcDzGj43Cx13fl_rWRC2GjU _1LrSDIowD1m_uKxayahMHAM7AehHCgPBoaLiO3JsNWkuOlZD8lk8.Fr4_89 EHaRl3ifat7moB86MeqMj4SYimO0SaPqCzFmICiL0JbV5gsExxkFhmMHE_XE wlKi5UdYNevRUiqcPtkOFQAoUm8VrOwxYHRRcJV9vntiKa_PmioAfkE_pcTW .VQAbUZMHH6pq3zUafW6V2kxWYKP8pEXd.vVH5xzUab7ZLraGwTbM0ks5P_O e_U9dG4E5RGcKmbwpIXu4i5008KclQiZLBsEivVPcIhZNXINzGKOEeq79K2C BcyPA.btYAQ7Aano- X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp232.mail.bf1.yahoo.com with SMTP; 03 Aug 2013 04:36:25 +0000 UTC References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-8DC10F8D-6075-4F03-BB16-2AC455826D2C Content-Transfer-Encoding: 7bit Message-Id: <0D68A6B5-99B5-4613-A877-0FE566BBA332@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Fri, 2 Aug 2013 23:36:20 -0500 To: Tim Bray Cc: John Levine , "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Aug 2013 04:36:31 -0000 --Apple-Mail-8DC10F8D-6075-4F03-BB16-2AC455826D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 30, 2013, at 11:39 AM, Tim Bray wrote: > Has anyone any personal knowledge of an app whose correct function depends= on the use of duplicate keys? -T Fortunately (or unfortunately, depending on personal views) a YC News comme= nt thread cropped up today regarding this very issue. See https://news.ycomb= inator.com/item?id=3D6146880 Many of the comments in the above thread advocate the use of duplicate keys a= s a form of comments. Others are against the idea of duplicated keys, noting= the problems with streaming parsers. A lot of the discussion within the thread mirrors the conversation we've had= in this mailing list for the past few months; I highly recommend reading it= since this list has been looking for examples of real-world JSON uses. ----------------- Vinny www.jsontest.com --Apple-Mail-8DC10F8D-6075-4F03-BB16-2AC455826D2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 30, 2013, at 11= :39 AM, Tim Bray <tbray@textualit= y.com> wrote:

Has anyone any personal knowledge of an ap= p whose correct function depends on the use of duplicate keys?  -T

Fortunately (or unfortunately, depending= on personal views)  a YC News comment thread cropped up today regardin= g this very issue. See https://news.ycombinator.c= om/item?id=3D6146880

Many of the com= ments in the above thread advocate the use of duplicate keys as a form of co= mments. Others are against the idea of duplicated keys, noting the problems w= ith streaming parsers.

A lot of the discussion with= in the thread mirrors the conversation we've had in this mailing list for th= e past few months; I highly recommend reading it since this list has been lo= oking for examples of real-world JSON uses.


-----------= ------
Vinny
= --Apple-Mail-8DC10F8D-6075-4F03-BB16-2AC455826D2C-- From jhildebr@cisco.com Sat Aug 3 16:09:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C221F9798 for ; Sat, 3 Aug 2013 16:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.678 X-Spam-Level: X-Spam-Status: No, score=-10.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC28KwZcu4-p for ; Sat, 3 Aug 2013 16:09:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2F97A21F95DD for ; Sat, 3 Aug 2013 16:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1666; q=dns/txt; s=iport; t=1375571388; x=1376780988; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=DMeWEtMQZ5GAwVuoP6ay/egP7+RQ0ba/58+NqsdFo84=; b=l/7NZwS3/Lj29gwcfbJSRIyKiA94JnArsbB2z8h9wPeFjngS33AXjh/U cp/6GtzivPy+foIpQ4AM8SqGVNtQQRj5wGelBUTmFxUUUjNaZf0fi9KTV il4ecfPb2+wVbO33hKF2iapHsOmdYjkzlsMGNVRFErm5pgzHRDhyQz1tp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOaM/VGtJXHB/2dsb2JhbABagwaBBb8UgR4WdIImAQEDOj8SAQgOFBQxESUCBAENBQiHdgMPrVINiF6NJ4JBMQeDGXQDlXeOEYUngxeCKg X-IronPort-AV: E=Sophos;i="4.89,809,1367971200"; d="scan'208";a="243159161" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2013 23:09:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r73N9kdB020770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 23:09:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Sat, 3 Aug 2013 18:09:46 -0500 From: "Joe Hildebrand (jhildebr)" To: Tatu Saloranta , Tim Bray Thread-Topic: [Json] fun with streaming, was The names within an object SHOULD be unique. Thread-Index: AQHOjUPkuhc07XaFCESqCMV81yMt45l91Y4AgAap/wA= Date: Sat, 3 Aug 2013 23:09:45 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.65.244] Content-Type: text/plain; charset="us-ascii" Content-ID: <4FB7C3461339304CBB8DA43A063C9B43@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Levine , "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Aug 2013 23:09:53 -0000 On 7/30/13 7:56 PM, "Tatu Saloranta" wrote: >This is a common use case for processing large JSON files; either output >as JSON arrays, or just sequences of space-separate objects. Typical data >sets are log output, processing from map/reduce style jobs and batch jobs. You're saying that you either produce {"a": 1, "b": 2} {"a": 3, "b": 4} or: [{"a": 1, "b": 2},{"a": 3, "b": 4}] right? In neither of those cases does the producer have a problem ensuring name uniqueness. If you've got a programming language description the objects in either of those cases, they are known to have unique names. If you're parsing either of those as a stream and generating 2 events each, you'll have to deal with unique names in one of the four ways we've seen(*), but not when acting as an eventing parser, only when creating the programming language construct to hold the objects from the events fired. =20 >Separation between streaming part and higher layers is for good >separation of concern, as well as practical matter for reusing components. That is a perfectly valid design, yes. I even like it. It doesn't get away from the fact that when you reduce the events to objects in your programming language, you'll need to deal with duplicate names in one of the four ways. Therefore, you SHOULD NOT send duplicates, since you don't know how they are going to be treated by the receiver. If you control both ends of the conversation, then it doesn't matter what the standard says, and you can send any data you want, including duplicates. (*) Reminder: error, first, last, all --=20 Joe Hildebrand From tsaloranta@gmail.com Sat Aug 3 19:30:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15B11E80E8 for ; Sat, 3 Aug 2013 19:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1owTbZICpsoZ for ; Sat, 3 Aug 2013 19:30:08 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C10DF11E80D7 for ; Sat, 3 Aug 2013 19:30:07 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so1491248wgh.3 for ; Sat, 03 Aug 2013 19:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F/INwHYwSMZ3nm+34y56UIin6l2nEiZIyx5helVnDfc=; b=mAbxVLq95WnmI4wOlTC0+9SxHYvoU9XeqiwHo6B3pp3Z90DbbEfuCoDLPkRuwU+2SB 3co0Bo8eTm5xA+uJrH3QVABkz1mp8EJvq6jEWuLgq/QG1jQ4pQOszV1h5LUJgMYhnC9u Nc1xlCh8fSCMX8PAnHXVadwZBNJy31YMufSzBI4cswqoK6UezeprLqT36aOnTyIy5W9N 4WgBDgP++eY4PALZy2KNWhTbcfmy4kfD/f1Jbu4AZKVnrqcx/iH33HxSH4ruPKCoQc0X V7MuQXUmNrUJmOg/oCu9ilSsnIIqEUlcyvUIFwMmJD4NiHLzjJPN4BGJLQK0vqA89KHL BhNg== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr9141484wjx.84.1375583406843; Sat, 03 Aug 2013 19:30:06 -0700 (PDT) Received: by 10.216.233.196 with HTTP; Sat, 3 Aug 2013 19:30:06 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Aug 2013 19:30:06 -0700 Message-ID: From: Tatu Saloranta To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7bfcf01e52ebec04e315f84a Cc: John Levine , Tim Bray , "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Aug 2013 02:30:11 -0000 --047d7bfcf01e52ebec04e315f84a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 3, 2013 at 4:09 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 7/30/13 7:56 PM, "Tatu Saloranta" wrote: > > >This is a common use case for processing large JSON files; either output > >as JSON arrays, or just sequences of space-separate objects. Typical data > >sets are log output, processing from map/reduce style jobs and batch jobs. > > You're saying that you either produce > > {"a": 1, "b": 2} {"a": 3, "b": 4} > > or: > > [{"a": 1, "b": 2},{"a": 3, "b": 4}] > > right? In neither of those cases does the producer have a problem > ensuring name uniqueness. If you've got a programming language > description the objects in either of those cases, they are known to have > unique names. If you're parsing either of those as a stream and > generating 2 events each, you'll have to deal with unique names in one of > the four ways we've seen(*), but not when acting as an eventing parser, > only when creating the programming language construct to hold the objects > from the events fired. > Yes. > > >Separation between streaming part and higher layers is for good > >separation of concern, as well as practical matter for reusing components. > > That is a perfectly valid design, yes. I even like it. It doesn't get > away from the fact that when you reduce the events to objects in your > programming language, you'll need to deal with duplicate names in one of > the four ways. Therefore, you SHOULD NOT send duplicates, since you don't > know how they are going to be treated by the receiver. If you control > both ends of the conversation, then it doesn't matter what the standard > says, and you can send any data you want, including duplicates. > > (*) Reminder: error, first, last, all > Yes to all of above as well. -+ Tatu +- --047d7bfcf01e52ebec04e315f84a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 3, 2013 at 4:09 PM, Joe Hildebrand (jhildebr) = <jhildebr@cisco.com> wrote:
<= div class=3D"gmail_quote">
On 7/30/13 7:56 PM, "= Tatu Saloranta" <tsaloranta= @gmail.com> wrote:

>This is a common use case for processing large JSON files; either outpu= t
>as JSON arrays, or just sequences of space-separate objects. Typical da= ta
>sets are log output, processing from map/reduce style jobs and batch jo= bs.

You're saying that you either produce

{"a": 1, "b": 2} {"a": 3, "b": 4}
or:

[{"a": 1, "b": 2},{"a": 3, "b": 4}]=

right? =A0In neither of those cases does the producer have a problem
ensuring name uniqueness. =A0If you've got a programming language
description the objects in either of those cases, they are known to have unique names. =A0If you're parsing either of those as a stream and
generating 2 events each, you'll have to deal with unique names in one = of
the four ways we've seen(*), but not when acting as an eventing parser,=
only when creating the programming language construct to hold the objects from the events fired.

Yes.
=A0

>Separation between streaming part and higher layers is for good
>separation of concern, as well as practical matter for reusing componen= ts.

That is a perfectly valid design, yes. =A0I even like it. =A0It doesn= 't get
away from the fact that when you reduce the events to objects in your
programming language, you'll need to deal with duplicate names in one o= f
the four ways. =A0Therefore, you SHOULD NOT send duplicates, since you don&= #39;t
know how they are going to be treated by the receiver. =A0If you control both ends of the conversation, then it doesn't matter what the standard=
says, and you can send any data you want, including duplicates.


(*) Reminder: error, first, last, all

Yes to all o= f above as well.

-+ Tatu +-
=A0
--047d7bfcf01e52ebec04e315f84a-- From paul.hoffman@vpnc.org Sun Aug 4 19:55:33 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A821E80C0; Sun, 4 Aug 2013 19:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.528 X-Spam-Level: X-Spam-Status: No, score=-101.528 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg2jZvdT3CjP; Sun, 4 Aug 2013 19:55:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C441A11E8120; Sun, 4 Aug 2013 19:55:32 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r752tUaJ050094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Aug 2013 19:55:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Aug 2013 19:55:30 -0700 Message-Id: <69713A81-95ED-4129-816D-E766B7F1FC51@vpnc.org> To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "iesg-secretary@ietf.org" Subject: [Json] Virtual interim meeting for the JSON WG X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 02:55:33 -0000 Greetings again. The WG's first virtual interim meeting will happen on = Wednesday August 21, 2013, at 1500 UTC. It will last for up to three = hours. The agenda will be published soon, but it will basically be how = to incorporate the topics that are now active on the list into the main = document. (FWIW, 1500 UTC is the same as: 0800 San Francisco 1100 New York 1700 Paris 2400 Tokyo) --Matt Miller and Paul Hoffman= From mamille2@cisco.com Mon Aug 5 12:55:06 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E648621F9D5D for ; Mon, 5 Aug 2013 12:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD91lXm2QALx for ; Mon, 5 Aug 2013 12:55:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A043321F949F for ; Mon, 5 Aug 2013 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6282; q=dns/txt; s=iport; t=1375732501; x=1376942101; h=from:to:subject:date:message-id:reply-to:mime-version; bh=y6kuIFGrM8O8Fw43FFNQW+dDRK4Ncc/IeC7QyvBlrfY=; b=fISsHpm/V/ptazWpxfL4RyUwXW/Gv9nfaXIIhgTuMdOuBCuZbnZ6cvsI HM9QlzzhdXn1NAE24UiKbwGDSHTbODGa8k4X3F/bYh9+nDMhs2YCvkXdC woxsQiXW1V5xyuqLlTYC08SxkgRQ9MaRNqb8sihkCFfPsEQmAuTR2x4jC M=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAG0CAFKtJXG9/2dsb2JhbABbgwY1UIJJvCyBIRZ0giYBBIELASomMA4ZBBsBBYgCDJRkhnyZTI9og1F0A5ATgS2Xb4MXgio X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="p7s'?scan'208";a="243817952" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2013 19:55:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r75Jt0AA028778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Aug 2013 19:55:00 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.144]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 14:54:59 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: IETF87 Minutes Posted Thread-Index: AQHOkhWqtE4okj3XKkib+8ywv+FWqg== Date: Mon, 5 Aug 2013 19:54:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.27] Content-Type: multipart/signed; boundary="Apple-Mail=_3224068E-9E2C-460A-AA4E-F890D496A9A5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] IETF87 Minutes Posted X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "json-chairs@tools.ietf.org" List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:55:07 -0000 --Apple-Mail=_3224068E-9E2C-460A-AA4E-F890D496A9A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The minutes for the JSON WG session have been posted: < = http://www.ietf.org/proceedings/87/minutes/minutes-87-json > Please send the Chairs any corrections. Thanks, - Paul Hoffman and Matt Miller= --Apple-Mail=_3224068E-9E2C-460A-AA4E-F890D496A9A5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MDUxOTU0 NTlaMCMGCSqGSIb3DQEJBDEWBBS24YoG78RB37zFnxvkt81Pi/EW0TCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBABIR iyGjsKLWHWWkZ+vUTeVcQQ/ZJjAzuhAInZnElbZfhxi5S+vMMSE0h0J0JTToi3YILtVTjXzQUpCb kTMg2r00T/3qS8qRShE3rxOpithiKawG1Sl4owZKoJgjZfO5DBlkeHvd9mHgLPb+ds6PxPQP3JpF doMb7lCMN8V3rj1pWlZTp9DXohnrilEajayRr28ZgIj6bFWkNnz8rLa6u0u7tVgNS8xQYW+MnRtP kW1WKaQKzXMQyc9A0jfQPEV61iGQdMkxjlbN7bqtCkK4SDAbIrh8qQz5vMmzGZeeTZsuYbcRL7TP CzFzNTlUMCMRqFVEE+t3os0Ie7j3kh3zAyoAAAAAAAA= --Apple-Mail=_3224068E-9E2C-460A-AA4E-F890D496A9A5-- From paul.hoffman@vpnc.org Mon Aug 5 13:03:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F194021F963C for ; Mon, 5 Aug 2013 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOLR6uXRjIus for ; Mon, 5 Aug 2013 13:03:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EFA7221F8C93 for ; Mon, 5 Aug 2013 13:02:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-3.dsl.dynamic.fusionbroadband.com [50.1.51.3]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r75K2tl4078815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 5 Aug 2013 13:02:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-3.dsl.dynamic.fusionbroadband.com [50.1.51.3] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51F8D4AC.7080301@qti.qualcomm.com> Date: Mon, 5 Aug 2013 13:02:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <63F65DA7-81A8-4990-94D6-69600C5BC955@vpnc.org> References: <51F8D4AC.7080301@qti.qualcomm.com> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:03:02 -0000 A general nudge to the WG to comment on Pete's message from last week. From tbray@textuality.com Mon Aug 5 13:34:05 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB88421F9BA2 for ; Mon, 5 Aug 2013 13:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpdENcdrvFh2 for ; Mon, 5 Aug 2013 13:34:00 -0700 (PDT) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7F21F995A for ; Mon, 5 Aug 2013 13:34:00 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so3296443vbg.39 for ; Mon, 05 Aug 2013 13:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JZ7i0LidgAFu2Jh/57jDT+ZmoQOAAGJr5H9UioPKRO8=; b=W2mW9YN56GcTFHVg1PHtKqwNxiZqhZjPckNNTwLYVQa2jVK/icYUQMa8AxsDbSK6pT bczIs4k1bFmsotMI+htTmtXEyDkwFS9a8gCYj/p2WIzObGrleH63ce5P+ko38cBnkTyy IEyGup4MlByAimhhvsLsdxdQLW8rLSDzC+OV296PAvUAKvyhtTMjoI0OvbtrNoJeT+0T IXemk3/3lyLXh/WXqBS+dIcSwtFDILpBaiBV2cyuV7gNUCSMlDiurI0I3++o1EWlUPBW QMuVMrXh8RfXK1ybQuwDABgoZ/2VaYfpiWKGmMsAC42Pu7is9J/RxBk6fcYh7zgnQrQe SftA== MIME-Version: 1.0 X-Received: by 10.58.155.37 with SMTP id vt5mr6433479veb.41.1375734839693; Mon, 05 Aug 2013 13:33:59 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Mon, 5 Aug 2013 13:33:59 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51F8D4AC.7080301@qti.qualcomm.com> References: <51F8D4AC.7080301@qti.qualcomm.com> Date: Mon, 5 Aug 2013 13:33:59 -0700 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b67239a6ceacc04e3393adc X-Gm-Message-State: ALoCoQnEq6vjrRj6/ys0y8vYSFrR42hpl+dGj+89P6K9NguAJzKn8zmnVprrrbLxeOIA9Uf3ugQs Cc: "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:34:05 -0000 --047d7b67239a6ceacc04e3393adc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2013 at 2:11 AM, Pete Resnick wr= ote: - The discussion at the beginning regarding "a JSON object" vs. "a JSON > text" was very revealing to me because it leads me to believe that nowher= e > do we have a general concept of a "JSON entity" aside from it encoding or > representation in memory. I think that has made some of the discussion mo= re > difficult, but my sense is that we now share a more general view of what > such a thing might be. This leads to another point: > Since I look at the world through HTTP-colored lenses, I think of JSON in the context of an HTTP message body. So at the top level, a JSON message is the bytes between the CR-NL/CR-NL and the end of message; or, what comes out of the generic JSON parser when I feed it bytes purported to contain JSON. > - The use of the terms "JSON parser" and "JSON generator" is often > conflated with things that I would refer to as a "JSON lexer" on the > parsing end of things and an "JSON encoder" or maybe a "JSON token > producer" on the generator end of things. That is, when I think of a "JSO= N > parser", I think of something that understands the semantics of the JSON > entity it is creating out of the JSON text it is parsing, and conversely = a > "JSON generator" knows about the semantics of the JSON entity it is turni= ng > into a JSON text from some in-memory representation. Some of the difficul= ty > in the conversation is that we know of pieces of code that don't know abo= ut > the semantics and therefore don't "know" whether they are dealing with > Unicode characters or just a series of Unicode scalar values. (This cause= d > similar confusions in the duplicate names discussion.) Requirements on > things that have to know the semantics are different than the requirement= s > on things that are simply lexers or encoders. How we explain that (and wh= at > language we use for it) in the documents is independent of the point that > they are different requirements. > tl;dr: I agree about the source of difficulty: Generic JSON library-ware is almost always used and almost never aware of application-level semantics. Long version: From where I sit, the situation you=E2=80=99re describing, wi= th application-sensitive encoders/decoders, is extremely unusual. The application programmer takes some data structure that it understands, passes it to a 100%-generic JSON encoder, and gets some bytes back, which it usually then interchanges over the network. At the other end, the programmer gets some bytes, passes them to a 100%-generic JSON decoder, and maps what it gets back onto its semantic view of the world. The details of what sort of interfaces the encoders and decoders use, and how you map from the JSON parse result to your own semantics, vary strongly from language to language - I have direct experience with Java, Ruby, and Go. In strongly-typed languages like Java and Go this means application programers have to do quite a bit of extra work to pull their view of the data out of a org.json.JSONObject (Java) or interface{} (Go). In dynamic languages such as Ruby the mapping between JSON and native data structures is pretty transparent and effortless. Hence my motivation: Since application programmers universally depend on application-oblivious libraries, I want to stamp out anything that makes these libraries function less well. One glaring instance of this is broken Unicode, which has the potential to cause breakage in libraries that think they=E2=80=99re dealing with strings of Unicode characters. For those prog= rammers who are encoding/decoding their JSON in an application-sensitive way, those issues would be much less severe. > For each of these three items, I think if we end up with some explanatory > text in the documents that helps make the appropriate distinctions (and > note that I am being purposely agnostic on what the WG should say about > each of them), I think that would help the clarity and implementability o= f > the spec. > > I'll leave it to the chairs to decide where to take the discussion from > here. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7b67239a6ceacc04e3393adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2013 at 2:11 AM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:

- The discussion at the b= eginning regarding "a JSON object" vs. "a JSON text" wa= s very revealing to me because it leads me to believe that nowhere do we ha= ve a general concept of a "JSON entity" aside from it encoding or= representation in memory. I think that has made some of the discussion mor= e difficult, but my sense is that we now share a more general view of what = such a thing might be. This leads to another point:

Since I look at the world through HTTP-col= ored lenses, I think of JSON in the context of an HTTP message body.=C2=A0 = So at the top level, a JSON message is the bytes between the CR-NL/CR-NL an= d the end of message; or, what comes out of the generic JSON parser when I = feed it bytes purported to contain JSON.
=C2=A0
- The use of the terms "JSON parser" and "JSON generator&quo= t; is often conflated with things that I would refer to as a "JSON lex= er" on the parsing end of things and an "JSON encoder" or ma= ybe a "JSON token producer" on the generator end of things. That = is, when I think of a "JSON parser", I think of something that un= derstands the semantics of the JSON entity it is creating out of the JSON t= ext it is parsing, and conversely a "JSON generator" knows about = the semantics of the JSON entity it is turning into a JSON text from some i= n-memory representation. Some of the difficulty in the conversation is that= we know of pieces of code that don't know about the semantics and ther= efore don't "know" whether they are dealing with Unicode char= acters or just a series of Unicode scalar values. (This caused similar conf= usions in the duplicate names discussion.) Requirements on things that have= to know the semantics are different than the requirements on things that a= re simply lexers or encoders. How we explain that (and what language we use= for it) in the documents is independent of the point that they are differe= nt requirements.

tl;dr: I agree about the source of difficu= lty: Generic JSON library-ware is almost always used and almost never aware= of application-level semantics.

Long version:= From where I sit, the situation you=E2=80=99re describing, with applicatio= n-sensitive encoders/decoders, is extremely unusual.=C2=A0 The application = programmer takes some data structure that it understands, passes it to a 10= 0%-generic JSON encoder, and gets some bytes back, which it usually then in= terchanges over the network.=C2=A0 At the other end, the programmer gets so= me bytes, passes them to a 100%-generic JSON decoder, and maps what it gets= back onto its semantic view of the world.=C2=A0 The details of what sort o= f interfaces the encoders and decoders use, and how you map from the JSON p= arse result to your own semantics, vary strongly from language to language = - I have direct experience with Java, Ruby, and Go.=C2=A0 In strongly-typed= languages like Java and Go this means application programers have to do qu= ite a bit of extra work to pull their view of the data out of a org.json.JS= ONObject (Java) or interface{} (Go).=C2=A0 In dynamic languages such as Rub= y the mapping between JSON and native data structures is pretty transparent= and effortless.

Hence my motivation: Since application programmers universal= ly depend on application-oblivious libraries, I want to stamp out anything = that makes these libraries function less well.=C2=A0 One glaring instance o= f this is broken Unicode, which has the potential to cause breakage in libr= aries that think they=E2=80=99re dealing with strings of Unicode characters= .=C2=A0 For those programmers who are encoding/decoding their JSON in an ap= plication-sensitive way, those issues would be much less severe.
=C2=A0
For each of these three items, I think if we end up with some explanatory t= ext in the documents that helps make the appropriate distinctions (and note= that I am being purposely agnostic on what the WG should say about each of= them), I think that would help the clarity and implementability of the spe= c.

I'll leave it to the chairs to decide where to take the discussion from= here.

pr

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

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

--047d7b67239a6ceacc04e3393adc-- From nico@cryptonector.com Mon Aug 5 14:05:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1F21F9F12 for ; Mon, 5 Aug 2013 14:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spd3848FozCb for ; Mon, 5 Aug 2013 14:05:55 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C199721F9F00 for ; Mon, 5 Aug 2013 14:05:52 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 48D26B805C for ; Mon, 5 Aug 2013 14:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=gSuQXSdK7QpIutdUZx50cvhwam8=; b=qd/pDk+A/oH gv/siL1hq62DAcb+tVJyL63TlkcdxnHZcpRKUEjx8sEJe1izZV8Q0NuHyr5BjpZ2 kWnzPWb7HtHovv5aHWyXK/IufmmZ8CtwqM1Cw37FFgJFoppZn5MLNFVY4pJI2k/q uZRGV3k527acxzdhm/Og6kaajIY1Cz0U= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id B8D19B8074 for ; Mon, 5 Aug 2013 14:05:50 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so2972814wes.31 for ; Mon, 05 Aug 2013 14:05:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zccgABMkxhzu8l4znqvvJxVUD0sEKu9KyqqQX0vLNGU=; b=nf7Fam2EpWn0lZ/nu0ymlsLp3wfU2CdHaIT/QHB5MtMPXg8QUuHUq4JiWGgpNOKv7w s2UT7JdSUiAxIx8kXqzsPNvQ1CFhN8jtCawINEKe0U7jgdCqYSky0Alk+PMOgjrLU1hh VOX1wzbX0t1yCQY9d2jl82TToPZVNLA1x5Kq+wc4h0Wi5bQmJdhhzAHtUiclFrezj7Do wT99B/qZtZCf6uXMdQY02qHtyIKZQid0FRKvTCsH+zNzSf8NoqX3O75CxDi4gtEe8FmT tD7JsLDp26QnglB2H7LmtMm7/QnhSKF0OuuoiM75nqhPgWVUE54uX5dL3ArR5on90ZEO xp2A== MIME-Version: 1.0 X-Received: by 10.195.13.202 with SMTP id fa10mr14787060wjd.14.1375736749198; Mon, 05 Aug 2013 14:05:49 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Mon, 5 Aug 2013 14:05:49 -0700 (PDT) In-Reply-To: References: <51F8D4AC.7080301@qti.qualcomm.com> Date: Mon, 5 Aug 2013 16:05:49 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:06:00 -0000 On Mon, Aug 5, 2013 at 3:33 PM, Tim Bray wrote: > On Wed, Jul 31, 2013 at 2:11 AM, Pete Resnick > wrote: > >> - The discussion at the beginning regarding "a JSON object" vs. "a JSON >> text" was very revealing to me because it leads me to believe that nowhe= re >> do we have a general concept of a "JSON entity" aside from it encoding o= r >> representation in memory. I think that has made some of the discussion m= ore >> difficult, but my sense is that we now share a more general view of what >> such a thing might be. This leads to another point: > > > Since I look at the world through HTTP-colored lenses, I think of JSON in > the context of an HTTP message body. So at the top level, a JSON message= is > the bytes between the CR-NL/CR-NL and the end of message; or, what comes = out > of the generic JSON parser when I feed it bytes purported to contain JSON= . If you're going to look at it that way then you kinda have to mention content-encoding... That's a total nitpick on my part, but it may be the sort of thing Pete's a= fter. >> - The use of the terms "JSON parser" and "JSON generator" is often >> ... > > Long version: From where I sit, the situation you=E2=80=99re describing, = with > application-sensitive encoders/decoders, is extremely unusual. The > application programmer takes some data structure that it understands, pas= ses > it to a 100%-generic JSON encoder, and gets some bytes back, which it > usually then interchanges over the network. At the other end, the > programmer gets some bytes, passes them to a 100%-generic JSON decoder, a= nd > maps what it gets back onto its semantic view of the world. The details = of > what sort of interfaces the encoders and decoders use, and how you map fr= om > the JSON parse result to your own semantics, vary strongly from language = to > language - I have direct experience with Java, Ruby, and Go. In > strongly-typed languages like Java and Go this means application programe= rs > have to do quite a bit of extra work to pull their view of the data out o= f a > org.json.JSONObject (Java) or interface{} (Go). In dynamic languages suc= h > as Ruby the mapping between JSON and native data structures is pretty > transparent and effortless. There's a bit more to it. Often the data has a schema that it needs to conform to -- whether the schema is baked into the app or actually expressed as a schema is irrelevant. Then again, often the data is free-form-ish. If I have a... "JSON text" and I parse it I might actually want to inspect it manually in a python REPL, or using jq. Or by eye (and people do write JSON texts by hand too). In practice though, any JSON API I care about has a schema, and the data is not really free-form. But then, an app could easily allow arbitrary user inputs to be represented as schema-free JSON, and then I'd have to care. > Hence my motivation: Since application programmers universally depend on > application-oblivious libraries, I want to stamp out anything that makes > these libraries function less well. One glaring instance of this is brok= en > Unicode, which has the potential to cause breakage in libraries that thin= k > they=E2=80=99re dealing with strings of Unicode characters. For those pr= ogrammers > who are encoding/decoding their JSON in an application-sensitive way, tho= se > issues would be much less severe. But how often does the naked surrogate thing actually cause problems? Are we merely trying to up the spec or are we really solving a problem that needs solving? Another possibility: we're trying to prevent a problem from coming up. Personally I think we should do something about naked surrogates and such: provide recommendations, and possibly also requirements for I-JSON. Aside: If we pursue I-JSON, how do you envision implementations actually handling it? As more parser/encoder options? As distinct interfaces/classes/whatever? Nico -- From iesg-secretary@ietf.org Mon Aug 5 17:27:54 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A4A21F9EC4; Mon, 5 Aug 2013 17:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLRjrh3LnkuJ; Mon, 5 Aug 2013 17:27:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E218F21F9DAD; Mon, 5 Aug 2013 17:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130806002753.23268.59519.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2013 17:27:53 -0700 Cc: json@ietf.org Subject: [Json] JSON WG Virtual Interim Meeting Wednesday August 21, 2013 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:27:54 -0000 The JSON Working Group will hold a virtual interim meeting on Wednesday Aug= ust 21, 2013, at 1500 UTC. It will last for up to three hours. The agenda w= ill be published soon, but it will basically be how to incorporate the topi= cs that are now active on the list into the main document. (FWIW, 1500 UTC is the same as: 0800 San Francisco 1100 New York 1700 Paris 2400 Tokyo) From paul.hoffman@vpnc.org Thu Aug 8 11:27:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB7A21F9E69 for ; Thu, 8 Aug 2013 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giDyYLckFkEG for ; Thu, 8 Aug 2013 11:27:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A919921F9E4F for ; Thu, 8 Aug 2013 11:27:44 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-3.dsl.dynamic.fusionbroadband.com [50.1.51.3]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r78IRaa1006577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Aug 2013 11:27:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-3.dsl.dynamic.fusionbroadband.com [50.1.51.3] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <63F65DA7-81A8-4990-94D6-69600C5BC955@vpnc.org> Date: Thu, 8 Aug 2013 11:27:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F8D4AC.7080301@qti.qualcomm.com> <63F65DA7-81A8-4990-94D6-69600C5BC955@vpnc.org> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 18:27:45 -0000 Another general nudge to the WG to comment on Pete's message from last = week. The topic is pretty fundamental to the -bis document. From tbray@textuality.com Thu Aug 8 11:45:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3211E8204 for ; Thu, 8 Aug 2013 11:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GV+yeHGqmIm for ; Thu, 8 Aug 2013 11:45:41 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id B711011E8211 for ; Thu, 8 Aug 2013 11:45:38 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so3398364veb.17 for ; Thu, 08 Aug 2013 11:45:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5yeNkILOp1ldF0pi9zQL7JJlzsXAr/Ub+mDEVj5XUo8=; b=Csp2fnYnnYsOjWjCD8a0EFOLjWMz0q8x5Tlks3Vu7bxrDgreN9mDuWKw4FWuEAaPBX WqYM04DwES6KnZByzXo+B8thjDVER3CtM8eA7yBXCmkO2/NnZcSVkX2Be1b6bzxzCOeL LWpJylBzE0mu794oGd7cPbd50W1odVHIipVWq4y7MrhsypaEG/7msqWqrq6stVlrycmg LlZhFakW02HFuf4pxqOC2TlQXs2RE8RdU5jKdhzE52z/69QZognzrslnjCRm/cdprkOI XU8o9wAJVi8KHCwZGPLADAY0hKRoyhPsWWNF4F/+jUtd8bNt7+YBsz6uoBEjtJ2YTpFB ZvJQ== X-Gm-Message-State: ALoCoQn23wYDLB4YTd0Lm8836dX8Afv6rpK0PyHEZjX8ymO6G6o4XN/qupRAndIS49zs1ggER6Re MIME-Version: 1.0 X-Received: by 10.58.54.70 with SMTP id h6mr3981781vep.36.1375987537137; Thu, 08 Aug 2013 11:45:37 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Thu, 8 Aug 2013 11:45:37 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <51F8D4AC.7080301@qti.qualcomm.com> References: <51F8D4AC.7080301@qti.qualcomm.com> Date: Thu, 8 Aug 2013 11:45:37 -0700 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0122ad065de42a04e3741037 Cc: "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Aug 2013 18:45:45 -0000 --089e0122ad065de42a04e3741037 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, since general discussion has not broken out, let=E2=80=99s be very spec= ific in answer to Pete=E2=80=99s question: On Wed, Jul 31, 2013 at 2:11 AM, Pete Resnick wr= ote: > For each of these three items, I think if we end up with some explanatory > text in the documents that helps make the appropriate distinctions (and > note that I am being purposely agnostic on what the WG should say about > each of them), I think that would help the clarity and implementability o= f > the spec. > I propose this as the explanatory text for the -bis: <<<<<<<<<<<<<<<< A JSON text which is composed entirely of Unicode characters (however encoded) will be interoperable in the sense that all Unicode-capable software which parses it will agree on the contents of names and values of object members. However, the ABNF in this specification allows member names and string values to contain bit sequences which cannot encode Unicode characters, for example "\udddd" (an unpaired UTF-16 surrogate). Instances of this have been observed, for example when a library truncates a UTF-16 string to a maximum allowable length without checking whether the truncation split a surrogate pair. The behavior of software which receives JSON texts containing such values is unpredictable; for example, two different implementations might return different values for the length of a string value, or even suffer a fatal runtime exception. <<<<<<<<<<<<<<<<< That=E2=80=99s all. Point out the problem as exactly and clearly as possibl= e, then shut up. > > I'll leave it to the chairs to decide where to take the discussion from > here. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --089e0122ad065de42a04e3741037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, since general discussion has not broken out, let=E2=80= =99s be very specific in answer to Pete=E2=80=99s question:

On Wed, Jul 31, 2013 at = 2:11 AM, Pete Resnick <presnick@qti.qualcomm.com> wr= ote:
For each of these three items, I think if we= end up with some explanatory text in the documents that helps make the app= ropriate distinctions (and note that I am being purposely agnostic on what = the WG should say about each of them), I think that would help the clarity = and implementability of the spec.

I propose this as the explanatory text for= the -bis:

<<<<<<<<<<<<<<&= lt;<
A JSON text which is composed entirely of Unicode cha= racters (however encoded) will be interoperable in the sense that all Unico= de-capable software which parses it will agree on the contents of names and= values of object members.=C2=A0 However, the ABNF in this specification al= lows member names and string values to contain bit sequences which cannot e= ncode Unicode characters, for example "\udddd" (an unpaired UTF-1= 6 surrogate).=C2=A0 Instances of this have been observed, for example when = a library truncates a UTF-16 string to a maximum allowable length without c= hecking whether the truncation split a surrogate pair.=C2=A0 The behavior o= f software which receives JSON texts containing such values is unpredictabl= e; for example, two different implementations might return different values= for the length of a string value, or even suffer a fatal runtime exception= .
<<<<<<<<<<<<<<<<= <

That=E2=80=99s all. Point out the problem as exactly= and clearly as possible, then shut up.
=C2=A0

I'll leave it to the chairs to decide where to take the discussion from= here.

pr

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

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

--089e0122ad065de42a04e3741037-- From Jeff.Hodges@KingsMountain.com Thu Aug 8 20:12:55 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E911E80F7 for ; Thu, 8 Aug 2013 20:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=1.870, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65Mm7vCx+dmc for ; Thu, 8 Aug 2013 20:12:50 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 14D3311E80E0 for ; Thu, 8 Aug 2013 20:12:49 -0700 (PDT) Received: (qmail 32622 invoked by uid 0); 9 Aug 2013 03:12:23 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.mail.unifiedlayer.com with SMTP; 9 Aug 2013 03:12:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=t+vtAeEw6AP+JkWjXLJcWqV6+QMAPwlBJk53oIg8k0U=; b=sBr9Q3EWVlDEfi/ywAiVSnxnpZOjWHwiNn353unsSupQ4BpT6XtBwq/6Auo/C76Np6kd/BFxz44CeofvM5GzoPn2lc9rOG5XgLKuMWvyjnbTVk84W4gQ39RN62V/+BDn; Received: from [24.4.122.173] (port=52195 helo=[192.168.11.14]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1V7d7m-00005E-TL for json@ietf.org; Thu, 08 Aug 2013 21:12:23 -0600 Message-ID: <52045E16.9090501@KingsMountain.com> Date: Thu, 08 Aug 2013 20:12:22 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF JSON WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [Json] Some thoughts on the "text model" discussion - terminology X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 03:12:55 -0000 presnick@qti.qualcomm.com said: > > - The discussion at the beginning regarding "a JSON object" vs. "a JSON > text" was very revealing to me because it leads me to believe that > nowhere do we have a general concept of a "JSON entity" aside from [its] > encoding or representation in memory. Although I agree the above touches upon the overall issue, I think it sort of misstates the issue. The issue is, IMV, that people use the term "JSON object" to refer to either, or both, "serialized data in JSON format" or/and "structured data [in memory]" -- e.g., the latter often occurs as "object literals" or "array literals" in JavaScript. Thus the term in common usage for what you're referring to as a "JSON entity" /is/ (for the most part, AFAICT) "JSON object". And, because RFC4627 is inconsistent in its terminology, it isn't successful in unambiguously differentiating between (a) "serialized data in JSON format" and (b) "structured data [in memory]", and also does not provide clearly distinct names for each of those things. Now, since RFC4627 is explicitly a MIME Media Type registration vehicle, it was clear to me, when I was referred to it, that it is describing "serialized data in JSON format". But this isn't necessarily clear to all readers, an example being the folks writing the JWT spec, hence my comments on that spec, which I related here to the JSON WG a while back [1]. In terms of rectifying the lack of clarity in RFC4627 between (a) and (b), I suggest making some changes to the terminology in RFC4627 -- i.e., via draft-ietf-json-rfc4627bis -- along the below (rough draft) lines [2]. HTH, =JeffH [1] [Json] terminology issues in RFC4627 JSON https://www.ietf.org/mail-archive/web/json/current/msg00211.html [2] ... > Network Working Group D. Crockford > Request for Comments: 4627 JSON.org > Category: Informational July 2006 > > > > The application/json Media Type for JavaScript Object Notation (JSON) > > > > 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. > > 1. Introduction > > > JSON can represent four primitive types (strings, numbers, booleans, > and null) and two structured types (objects and arrays). > > A string is a sequence of zero or more Unicode characters [UNICODE]. > > An object is an unordered collection of zero or more name/value > pairs, where a name is a string and a value is a string, number, > boolean, null, object, or array. > > An array is an ordered sequence of zero or more values. rewrite the immediately above four paragraphs as: A JSON text is data serialized according to the grammar specified in Section 2. A JSON text is composed of some combination of four primitive JSON text entities: strings, numbers, booleans, and null; as well as two structured JSON text entities: objects and arrays. A JSON text string is a sequence of zero or more Unicode characters [UNICODE]. A JSON text object is an unordered collection of zero or more name/value pairs, where a name is a JSON text string and a value is a one of the following JSON text entities: string, number, boolean, null, object, or array. A JSON text array is an ordered sequence of zero or more JSON text values. > The terms "object" and "array" come from the conventions of > JavaScript. > > JSON's design goals were for it to be minimal, portable, textual, and > a subset of JavaScript. > > > > 1.1. Conventions Used in This Document > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > The grammatical rules in this document are to be interpreted as > described in [RFC4234]. > > 2. JSON Grammar > > > A JSON text is a sequence of tokens. The set of tokens includes six > structural characters, strings, numbers, and three literal names. > > A JSON text is a serialized object or array. > > JSON-text = object / array rewrite the immediately above two paragraphs as: A JSON text is a serialized object or array, described by this ABNF [RFC5234]: JSON-text = object / array The serialized object or array is constructed as a sequence of tokens. The set of tokens includes six structural characters, as well as JSON text strings, JSON text numbers, and three literal tokens. The structural characters are used to delimit objects, arrays, names, and values. > These are the six structural characters: > > begin-array = ws %x5B ws ; [ left square bracket > > begin-object = ws %x7B ws ; { left curly bracket > > end-array = ws %x5D ws ; ] right square bracket > > end-object = ws %x7D ws ; } right curly bracket > > name-separator = ws %x3A ws ; : colon > > value-separator = ws %x2C ws ; , comma > > Insignificant whitespace is allowed before or after any of the six > structural characters. > > ws = *( > %x20 / ; Space > %x09 / ; Horizontal tab > %x0A / ; Line feed or New line > %x0D ; Carriage return > ) > > 2.1. Values > > > A JSON value MUST be an object, array, number, or string, or one of > the following three literal names: rewrite the immediately above paragraph as: A JSON text value MUST be an object, array, number, or string, or one of the following three literal names: > > false null true > > > The literal names MUST be lowercase. No other literal names are > allowed. > > value = false / null / true / object / array / number / string > > false = %x66.61.6c.73.65 ; false > > null = %x6e.75.6c.6c ; null > > true = %x74.72.75.65 ; true > > 2.2. Objects 2.2. JSON Text Objects > > > An object structure is represented as a pair of curly brackets > surrounding zero or more name/value pairs (or members). A JSON text object constructed as a pair of curly brackets surrounding zero or more name/value pairs (or members). > A name is a > string. A single colon comes after each name, separating the name > from the value. A single comma separates a value from a following > name. The names within an object SHOULD be unique. > > object = begin-object [ member *( value-separator member ) ] > end-object > > member = string name-separator value > > 2.3. Arrays > > An array structure is represented as square brackets surrounding zero > or more values (or elements). Elements are separated by commas. 2.3. JSON Text Arrays A JSON text array is constructed as square brackets surrounding zero or more values, also known as array elements. Array elements are separated by commas. > array = begin-array [ value *( value-separator value ) ] end-array > > 2.4. Numbers > > > The representation of numbers is similar to that used in most > programming languages. A number contains an integer component that > may be prefixed with an optional minus sign, which may be followed by > a fraction part and/or an exponent part. 2.4. JSON Text Numbers The representation of numbers is similar to that used in most programming languages. A JSON text number contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. > Octal and hex forms are not allowed. Leading zeros are not allowed. > > A fraction part is a decimal point followed by one or more digits. > > An exponent part begins with the letter E in upper or lowercase, > which may be followed by a plus or minus sign. The E and optional > sign are followed by one or more digits. > > Numeric values that cannot be represented as sequences of digits > (such as Infinity and NaN) are not permitted. > > > number = [ minus ] int [ frac ] [ exp ] > > decimal-point = %x2E ; . > > digit1-9 = %x31-39 ; 1-9 > > e = %x65 / %x45 ; e E > > exp = e [ minus / plus ] 1*DIGIT > > frac = decimal-point 1*DIGIT > > int = zero / ( digit1-9 *DIGIT ) > > minus = %x2D ; - > > plus = %x2B ; + > > zero = %x30 ; 0 > > 2.5. Strings > > > The representation of strings is similar to conventions used in the C > family of programming languages. A string begins and ends with > quotation marks. 2.5. JSON Text Strings The representation of strings is similar to conventions used in the C family of programming languages. A JSON text string begins and ends with quotation marks. > All Unicode characters may be placed within the > quotation marks except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F). > > Any character may be escaped. If the character is in the Basic > Multilingual Plane (U+0000 through U+FFFF), then it may be > represented as a six-character sequence: a reverse solidus, followed > by the lowercase letter u, followed by four hexadecimal digits that > encode the character's code point. The hexadecimal letters A though > F can be upper or lowercase. So, for example, a string containing > only a single reverse solidus character may be represented as > "\u005C". > > Alternatively, there are two-character sequence escape > representations of some popular characters. So, for example, a > string containing only a single reverse solidus character may be > represented more compactly as "\\". > > To escape an extended character that is not in the Basic Multilingual > Plane, the character is represented as a twelve-character sequence, > encoding the UTF-16 surrogate pair. So, for example, a string > containing only the G clef character (U+1D11E) may be represented as > "\uD834\uDD1E". > > string = quotation-mark *char quotation-mark > > char = unescaped / > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ; uXXXX U+XXXX > > escape = %x5C ; \ > > quotation-mark = %x22 ; " > > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF > > 3. Encoding > > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > > Since the first two characters of a JSON text will always be ASCII > characters [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. > > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx xx xx xx UTF-8 > < snip off rest of spec, you get the idea, changes of the above flavor ought to be carried throughout the doc > --- end From jorge@jorgechamorro.com Fri Aug 9 10:31:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A881D11E81A1 for ; Fri, 9 Aug 2013 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg-3hnWDYwDq for ; Fri, 9 Aug 2013 10:31:14 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF4021F9C72 for ; Fri, 9 Aug 2013 10:26:41 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id j17so1871632wiw.5 for ; Fri, 09 Aug 2013 10:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4vh9NyP1xmIwwHhd85vvCOg2ioDSNa5BntYwBWUtQ4U=; b=UQKLvSo5fO5/wRdyjXy4G0nma68JGhjdmX/kCJ+pJgybBV/owJut62cLPefxUBbHwb 18gN2s0V6odvyz1QwD5psM4jh5d3BaV1YVlep9o2sz1tn+HsBN5ryQn1BkO6QKVV7QiB Ehviq4AHJgMKcVvRuIpe4cwZmDE0HDLHcSOpnFEwEBX918WXbcjVM8nHPHLe8cgW2+jU qFpgxqpvc/JZi34pKqLDxKARZ3JYIxP6nm34Vuf+0wjTUghHjVLKtsHOLrUKwqQqqDkj yvJgeETjb/jS3TDvIQpV+bxeOGzjkcFE04iSGdV1iTB6wNN4PXYZKYr0fMv9Om8Ezn/a mwIw== X-Gm-Message-State: ALoCoQlhz2dC5w+9joIF49L/AMz8Os48pQ3wqmAUk4BCRv1lq3kNQHG0WGUIpZOwZstu4TTDHZd5 X-Received: by 10.194.232.40 with SMTP id tl8mr6883840wjc.42.1376069201234; Fri, 09 Aug 2013 10:26:41 -0700 (PDT) Received: from [192.168.10.50] (134.Red-88-0-161.dynamicIP.rima-tde.net. [88.0.161.134]) by mx.google.com with ESMTPSA id e7sm3952155wiy.4.2013.08.09.10.26.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 10:26:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Jorge Chamorro In-Reply-To: Date: Fri, 9 Aug 2013 19:26:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <430CA692-D68F-4CC4-AB57-19759B7F4003@jorgechamorro.com> References: <51F8D4AC.7080301@qti.qualcomm.com> To: Tim Bray X-Mailer: Apple Mail (2.1085) Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Aug 2013 17:31:20 -0000 On 08/08/2013, at 20:45, Tim Bray wrote: >=20 >=20 > I propose this as the explanatory text for the -bis: >=20 > <<<<<<<<<<<<<<<< > A JSON text which is composed entirely of Unicode characters (however = encoded) will be interoperable in the sense that all Unicode-capable = software which parses it will agree on the contents of names and values = of object members. However, the ABNF in this specification allows = member names and string values to contain bit sequences which cannot = encode Unicode characters, for example "\udddd" (an unpaired UTF-16 = surrogate). Instances of this have been observed, for example when a = library truncates a UTF-16 string to a maximum allowable length without = checking whether the truncation split a surrogate pair. The behavior of = software which receives JSON texts containing such values is = unpredictable; for example, two different implementations might return = different values for the length of a string value, or even suffer a = fatal runtime exception. > <<<<<<<<<<<<<<<<< >=20 > That=E2=80=99s all. Point out the problem as exactly and clearly as = possible, then shut up. > =20 +1 "extraneous" illegal bit sequences might also happen to be converted to = 0xfffd (the all too often seen =EF=BF=BD) --=20 ( Jorge )();= From masinter@adobe.com Sun Aug 11 05:41:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4463321F9A49 for ; Sun, 11 Aug 2013 05:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRRlIqdxqJCd for ; Sun, 11 Aug 2013 05:41:18 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3721F9808 for ; Sun, 11 Aug 2013 05:34:41 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUgeE3xYwJDg6BTfJ+uC8LggJq+5mu3iL@postini.com; Sun, 11 Aug 2013 05:34:41 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7BCV9D8022874 for ; Sun, 11 Aug 2013 05:31:10 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7BCYcw7006143 for ; Sun, 11 Aug 2013 05:34:38 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 11 Aug 2013 05:34:38 -0700 From: Larry Masinter To: "json@ietf.org" Date: Sun, 11 Aug 2013 05:34:37 -0700 Thread-Topic: [Json] Some thoughts on the "text model" discussion Thread-Index: Ac6UZ44j3bt/aZMrT2i45+Ze7XOD4gB7fVPg Message-ID: References: <51F8D4AC.7080301@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D34728C1388nambxv01acorp_" MIME-Version: 1.0 Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Aug 2013 12:41:23 -0000 --_000_C68CB012D9182D408CED7B884F441D4D34728C1388nambxv01acorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gZ2VuZXJhbCwgYSDigJxtZWRpYSB0eXBl4oCdIGlkZW50aWZpZXMgYSBtZWFucyBvZiBzZXJp YWxpemluZyBhbiBhYnN0cmFjdCBtb2RlbCBvZiBzb21ldGhpbmc7IOKAnGltYWdlL2pwZWfigJ0g aXMgYSBieXRlIHNlcXVlbmNlIG1lYW5zIG9mIGV4cHJlc3NpbmcgYW4gaW1hZ2UsIOKAnHRleHQv aHRtbOKAnSBhIG1lYW5zIG9mIGV4cHJlc3NpbmcgYSBoeXBlcnRleHQgZG9jdW1lbnQuIFhNTCBp cyBhIHNlcmlhbGl6YXRpb24g4oCcYXBwbGljYXRpb24vanNvbuKAnSBpcyBhIG1lYW5zIG9mIGV4 cHJlc3NpbmcgYW4gb2JqZWN0IGluIGEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UuDQoNCkFzIHdpdGgg WE1MIGFuZCBvdGhlciAsIHRoZSBzZXJpYWxpemF0aW9uIG9mIHRoZSBKU09OIG1vZGVsIGlzIGNv bmNlcHR1YWxseSBoYW5kbGVkIG9uIG11bHRpcGxlIGxldmVsczoNCg0KMSkgICAgICBhIGRhdGEg c3RydWN0dXJlIGluIGEgc3BlY2lmaWMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgKEphdmFTY3JpcHQs IEVDTUFTY3JpcHQsIFB5dGhvbiwgTGlzcCkNCjIpICAgICAgYW4gYWJzdHJhY3Qgb2JqZWN0IGRh dGEgc3RydWN0dXJlLCBjb21tb24gYmV0d2VlbiBhbGwgSlNPTiBpbXBsZW1lbnRhdGlvbnMNCjMp ICAgICAgYXMgYSBzZXF1ZW5jZSBvZiBhYnN0cmFjdCBVbmljb2RlIGNoYXJhY3RlcnMgKGlkZW50 aWZpZWQgYnkgdGhlaXIgY29kZSBwb2ludHMpDQo0KSAgICAgIGFzIGEgc2VxdWVuY2Ugb2YgYnl0 ZXMsIHdoZXJlIHRoZSBieXRlIHNlcXVlbmNlIGlzIGFuIGVuY29kaW5nIG9mIHRoZSBVbmljb2Rl IGNoYXJhY3RlcnMsIHVzaW5nIG9uZSBvZiB0aGUgVW5pY29kZSB0cmFuc2ZlciBmdW5jdGlvbnMs IFVURjgsIFVURjE2Lg0KDQpUaGUgbWFwcGluZyBiZXR3ZWVuICgzKSB0byAoNCkgaXMgZGVmaW5l ZCBieSBVbmljb2RlLg0KVGhlIG1hcHBpbmcgYmV0d2VlbiAoMSkgYW5kICgyKSBpcyBkZWZpbmVk IGJ5IHRoZSBiaW5kaW5nIG9mIEpTT04gdG8gYSBwYXJ0aWN1bGFyIHByb2dyYW1taW5nIGxhbmd1 YWdlOyBFQ01BIFhYWFggZGVmaW5lcyB0aGUgbWFwcGluZyBmb3IgRUNNQVNjcmlwdC4NClRoZSBz eW50YXggYWxsb3dlZCBmb3IgKDMpIGFuZCB0aGUgbWFwcGluZyBiZXR3ZWVuICgyKSBhbmQgKDMp IGFyZSBkZWZpbmVkIGJ5IEVDTUEgWVlZWS4NCg0KVGhlIGFic3RyYWN0IG1vZGVsIGZvciAoMikg aXMgbGltaXRlZCBzbyBhcyB0byBzdXBwb3J0IG1hbnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIGFu ZCBhIHNpbXBsZSBtYXBwaW5nIOKAkyB0aGVyZSBhcmUgbWFueSAobGV2ZWwgMSkgcHJvZ3JhbW1p bmcgbGFuZ3VhZ2UgZGF0YSBzdHJ1Y3R1cmVzIGFuZCB0eXBlcyB3aGljaCBjYW5ub3QgYmUgcmVw cmVzZW50ZWQgaW4gSlNPTi4gRm9yIGV4YW1wbGUsIEpTT04gKDIpIGRvZXMgbm90IGRpc3Rpbmd1 aXNoIGJldHdlZW4gYXJyYXlzIGFuZCBsaXN0cy4gSlNPTiAoMikgZG9lcyBub3QgYWxsb3cgcmVw ZWF0ZWQgYXR0cmlidXRlcy4NCg0KSG93ZXZlciwgYSBKU09OIHBhcnNlciAobWFwcGluZyBmcm9t IDMgdG8gMikgbWF5IGVuY291bnRlciByZXBlYXRlZCBhdHRyaWJ1dGVzLCBhbmQgTVVTVCBpZ25v cmUgYWxsIGJ1dCB0aGUgbGFzdCBpdCBlbmNvdW50ZXJzLiAgQSBKU09OIGVtaXR0ZXIgTUFZIHBy b2R1Y2UgcmVwZWF0ZWQgYXR0cmlidXRlcy4NCg0KDQoNCg0KDQoNCg0KDQpGcm9tOiBqc29uLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqc29uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBUaW0gQnJheQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwOCwgMjAxMyA4OjQ2IFBNDQpUbzog UGV0ZSBSZXNuaWNrDQpDYzoganNvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtKc29uXSBTb21l IHRob3VnaHRzIG9uIHRoZSAidGV4dCBtb2RlbCIgZGlzY3Vzc2lvbg0KDQpPSywgc2luY2UgZ2Vu ZXJhbCBkaXNjdXNzaW9uIGhhcyBub3QgYnJva2VuIG91dCwgbGV04oCZcyBiZSB2ZXJ5IHNwZWNp ZmljIGluIGFuc3dlciB0byBQZXRl4oCZcyBxdWVzdGlvbjoNCg0KT24gV2VkLCBKdWwgMzEsIDIw MTMgYXQgMjoxMSBBTSwgUGV0ZSBSZXNuaWNrIDxwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tPG1h aWx0bzpwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tPj4gd3JvdGU6DQpGb3IgZWFjaCBvZiB0aGVz ZSB0aHJlZSBpdGVtcywgSSB0aGluayBpZiB3ZSBlbmQgdXAgd2l0aCBzb21lIGV4cGxhbmF0b3J5 IHRleHQgaW4gdGhlIGRvY3VtZW50cyB0aGF0IGhlbHBzIG1ha2UgdGhlIGFwcHJvcHJpYXRlIGRp c3RpbmN0aW9ucyAoYW5kIG5vdGUgdGhhdCBJIGFtIGJlaW5nIHB1cnBvc2VseSBhZ25vc3RpYyBv biB3aGF0IHRoZSBXRyBzaG91bGQgc2F5IGFib3V0IGVhY2ggb2YgdGhlbSksIEkgdGhpbmsgdGhh dCB3b3VsZCBoZWxwIHRoZSBjbGFyaXR5IGFuZCBpbXBsZW1lbnRhYmlsaXR5IG9mIHRoZSBzcGVj Lg0KDQpJIHByb3Bvc2UgdGhpcyBhcyB0aGUgZXhwbGFuYXRvcnkgdGV4dCBmb3IgdGhlIC1iaXM6 DQoNCjw8PDw8PDw8PDw8PDw8PDwNCkEgSlNPTiB0ZXh0IHdoaWNoIGlzIGNvbXBvc2VkIGVudGly ZWx5IG9mIFVuaWNvZGUgY2hhcmFjdGVycyAoaG93ZXZlciBlbmNvZGVkKSB3aWxsIGJlIGludGVy b3BlcmFibGUgaW4gdGhlIHNlbnNlIHRoYXQgYWxsIFVuaWNvZGUtY2FwYWJsZSBzb2Z0d2FyZSB3 aGljaCBwYXJzZXMgaXQgd2lsbCBhZ3JlZSBvbiB0aGUgY29udGVudHMgb2YgbmFtZXMgYW5kIHZh bHVlcyBvZiBvYmplY3QgbWVtYmVycy4gIEhvd2V2ZXIsIHRoZSBBQk5GIGluIHRoaXMgc3BlY2lm aWNhdGlvbiBhbGxvd3MgbWVtYmVyIG5hbWVzIGFuZCBzdHJpbmcgdmFsdWVzIHRvIGNvbnRhaW4g Yml0IHNlcXVlbmNlcyB3aGljaCBjYW5ub3QgZW5jb2RlIFVuaWNvZGUgY2hhcmFjdGVycywgZm9y IGV4YW1wbGUgIlx1ZGRkZCIgKGFuIHVucGFpcmVkIFVURi0xNiBzdXJyb2dhdGUpLiAgSW5zdGFu Y2VzIG9mIHRoaXMgaGF2ZSBiZWVuIG9ic2VydmVkLCBmb3IgZXhhbXBsZSB3aGVuIGEgbGlicmFy eSB0cnVuY2F0ZXMgYSBVVEYtMTYgc3RyaW5nIHRvIGEgbWF4aW11bSBhbGxvd2FibGUgbGVuZ3Ro IHdpdGhvdXQgY2hlY2tpbmcgd2hldGhlciB0aGUgdHJ1bmNhdGlvbiBzcGxpdCBhIHN1cnJvZ2F0 ZSBwYWlyLiAgVGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHdoaWNoIHJlY2VpdmVzIEpTT04gdGV4 dHMgY29udGFpbmluZyBzdWNoIHZhbHVlcyBpcyB1bnByZWRpY3RhYmxlOyBmb3IgZXhhbXBsZSwg dHdvIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgcmV0dXJuIGRpZmZlcmVudCB2YWx1 ZXMgZm9yIHRoZSBsZW5ndGggb2YgYSBzdHJpbmcgdmFsdWUsIG9yIGV2ZW4gc3VmZmVyIGEgZmF0 YWwgcnVudGltZSBleGNlcHRpb24uDQo8PDw8PDw8PDw8PDw8PDw8PA0KVGhhdOKAmXMgYWxsLiBQ b2ludCBvdXQgdGhlIHByb2JsZW0gYXMgZXhhY3RseSBhbmQgY2xlYXJseSBhcyBwb3NzaWJsZSwg dGhlbiBzaHV0IHVwLg0KDQoNCkknbGwgbGVhdmUgaXQgdG8gdGhlIGNoYWlycyB0byBkZWNpZGUg d2hlcmUgdG8gdGFrZSB0aGUgZGlzY3Vzc2lvbiBmcm9tIGhlcmUuDQoNCnByDQoNCi0tDQpQZXRl IFJlc25pY2s8aHR0cDovL3d3dy5xdWFsY29tbS5jb20vfnByZXNuaWNrLz4NClF1YWxjb21tIFRl Y2hub2xvZ2llcywgSW5jLiAtICsxICg4NTgpNjUxLTQ0Nzg8dGVsOiUyQjElMjAlMjg4NTglMjk2 NTEtNDQ3OD4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmpzb24gbWFpbGluZyBsaXN0DQpqc29uQGlldGYub3JnPG1haWx0bzpqc29uQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qc29uDQoNCg== --_000_C68CB012D9182D408CED7B884F441D4D34728C1388nambxv01acorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxQ0U5NjY5LkVBQzczN0Ew Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0 aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29y ZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6 R3JhbW1hclN0YXRlPkNsZWFuPC93OkdyYW1tYXJTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6 VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNj aGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0K PHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFs d2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhl bWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpM aWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3 OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3Jh cHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVu VHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTptYXRoRm9u dCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06 YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8 bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAi Lz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBtOnZhbD0i MTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2YWw9InVu ZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9 ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVm UUZvcm1hdD0iZmFsc2UiIERlZlByaW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMjY3Ij4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3Jt YXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM5IiBOYW1lPSJ0b2MgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzOSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJjYXB0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjEwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i UGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJM aWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYz IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlz dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2Ug UXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlz dCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50 ZW5zZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzciIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRp bmciLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA5MjkyOSAxMDczNzg2MTExIDkgMCA0MTUgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p bHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJl Oi01MjAwODE2NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJl bnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2lu YXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0 ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9l bnpiOw0KCW1zby1zdHlsZS11bmhpZGU6bm87fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglt c28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5TcGVsbEUN Cgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLXNwbC1lOnllczt9DQpzcGFuLkdyYW1FDQoJe21z by1zdHlsZS1uYW1lOiIiOw0KCW1zby1ncmFtLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjouNWluOw0KCW1zby1m b290ZXItbWFyZ2luOi41aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6ODA0NTQ1MzYwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo5MTkzNzY5NzggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlIHN0eWxlPSd0YWItaW50ZXJ2YWw6LjVpbic+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1D YWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29s b3I6IzFGNDk3RCc+SW4gZ2VuZXJhbCwgYSDigJxtZWRpYSB0eXBl4oCdIGlkZW50aWZpZXMgYSBt ZWFucyBvZiBzZXJpYWxpemluZyBhbiBhYnN0cmFjdCBtb2RlbCBvZiBzb21ldGhpbmc7IOKAnGlt YWdlL2pwZWfigJ0gaXMgYSBieXRlIHNlcXVlbmNlIG1lYW5zIG9mIGV4cHJlc3NpbmcgYW4gaW1h Z2UsIOKAnHRleHQvaHRtbOKAnSBhIG1lYW5zIG9mIGV4cHJlc3NpbmcgYSBoeXBlcnRleHQgZG9j dW1lbnQuIFhNTCBpcyBhIHNlcmlhbGl6YXRpb24g4oCcYXBwbGljYXRpb24vPHNwYW4gY2xhc3M9 U3BlbGxFPmpzb248L3NwYW4+4oCdIGlzIGEgbWVhbnMgb2YgZXhwcmVzc2luZyBhbiBvYmplY3Qg aW4gYSBwcm9ncmFtbWluZyBsYW5ndWFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJy aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+QXMgd2l0 aCBYTUwgYW5kIDxzcGFuIGNsYXNzPUdyYW1FPm90aGVyICw8L3NwYW4+IHRoZSBzZXJpYWxpemF0 aW9uIG9mIHRoZSBKU09OIG1vZGVsIGlzIGNvbmNlcHR1YWxseSBoYW5kbGVkIG9uIG11bHRpcGxl IGxldmVsczo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFb aWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGli cmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4x KTxmb250IHNpemU9MSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0yIGNv bG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5hIGRhdGEgc3RydWN0dXJlIGluIGEgc3Bl Y2lmaWMgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgKEphdmFTY3JpcHQsIDxzcGFuIGNsYXNzPVNwZWxs RT5FQ01BU2NyaXB0PC9zcGFuPiwgUHl0aG9uLCBMaXNwKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxmb250IHNpemU9MSBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48L3NwYW4+ PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNl PUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtj b2xvcjojMUY0OTdEJz5hbiBhYnN0cmFjdCBvYmplY3QgZGF0YSBzdHJ1Y3R1cmUsIGNvbW1vbiBi ZXR3ZWVuIGFsbCBKU09OIGltcGxlbWVudGF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZv bnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zKTxmb250IHNpemU9MSBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48L3NwYW4+PC9z cGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNh bGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xv cjojMUY0OTdEJz5hcyBhIHNlcXVlbmNlIG9mIGFic3RyYWN0IFVuaWNvZGUgY2hhcmFjdGVycyAo aWRlbnRpZmllZCBieSB0aGVpciBjb2RlIHBvaW50cyk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxm b250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NCk8Zm9udCBzaXplPTEgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwv c3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxzcGFuIGNsYXNzPUdyYW1FPjxmb250IHNpemU9MiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+YXM8L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9u dCBzaXplPTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPiBhIHNlcXVlbmNlIG9m IGJ5dGVzLCB3aGVyZSB0aGUgYnl0ZSBzZXF1ZW5jZSBpcyBhbiBlbmNvZGluZyBvZiB0aGUgVW5p Y29kZSBjaGFyYWN0ZXJzLCB1c2luZyBvbmUgb2YgdGhlIFVuaWNvZGUgdHJhbnNmZXIgZnVuY3Rp b25zLCBVVEY4LCBVVEYxNi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0y IGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5UaGUgbWFwcGluZyA8c3BhbiBjbGFz cz1HcmFtRT5iZXR3ZWVuICgzKSB0byAoNCk8L3NwYW4+IGlzIGRlZmluZWQgYnkgVW5pY29kZS48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFi LXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0 OTdEJz5UaGUgbWFwcGluZyBiZXR3ZWVuICgxKSBhbmQgKDIpIGlzIGRlZmluZWQgYnkgdGhlIGJp bmRpbmcgb2YgSlNPTiB0byBhIHBhcnRpY3VsYXIgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2U7IEVDTUEg WFhYWCBkZWZpbmVzIHRoZSBtYXBwaW5nIGZvciA8c3BhbiBjbGFzcz1TcGVsbEU+RUNNQVNjcmlw dDwvc3Bhbj4uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J3RhYi1zdG9wczo0Ni41cHQnPjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 Y29sb3I6IzFGNDk3RCc+VGhlIHN5bnRheCBhbGxvd2VkIGZvciAoMykgYW5kIHRoZSBtYXBwaW5n IGJldHdlZW4gKDIpIGFuZCAoMykgYXJlIGRlZmluZWQgYnkgRUNNQSBZWVlZLjxzcGFuIHN0eWxl PSdtc28tc3BhY2VydW46eWVzJz7CoCA8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RhYi1zdG9wczo0Ni41cHQnPjxmb250IHNpemU9 MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RhYi1zdG9wczo0Ni41cHQn Pjxmb250IHNpemU9MiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+VGhlIGFic3Ry YWN0IG1vZGVsIGZvciAoMikgaXMgbGltaXRlZCBzbyBhcyB0byBzdXBwb3J0IG1hbnkgcHJvZ3Jh bW1pbmcgbGFuZ3VhZ2VzIGFuZCBhIHNpbXBsZSBtYXBwaW5nIOKAkyB0aGVyZSBhcmUgbWFueSAo bGV2ZWwgMSkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgZGF0YSBzdHJ1Y3R1cmVzIGFuZCB0eXBlcyB3 aGljaCBjYW5ub3QgYmUgcmVwcmVzZW50ZWQgaW4gSlNPTi4gRm9yIGV4YW1wbGUsIEpTT04gKDIp IGRvZXMgbm90IGRpc3Rpbmd1aXNoIGJldHdlZW4gYXJyYXlzIGFuZCBsaXN0cy4gSlNPTiAoMikg ZG9lcyBub3QgYWxsb3cgcmVwZWF0ZWQgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQg c2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2 LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz5Ib3dl dmVyLCBhIEpTT04gcGFyc2VyIChtYXBwaW5nIGZyb20gMyB0byAyKSBtYXkgZW5jb3VudGVyIHJl cGVhdGVkIGF0dHJpYnV0ZXMsIGFuZCBNVVNUIGlnbm9yZSBhbGwgYnV0IHRoZSBsYXN0IGl0IGVu Y291bnRlcnMuPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgIDwvc3Bhbj5BIEpTT04g ZW1pdHRlciBNQVkgcHJvZHVjZSByZXBlYXRlZCBhdHRyaWJ1dGVzLiA8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0 b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNl PUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIj MWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVwdCc+PGZvbnQgc2l6 ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGFiLXN0b3BzOjQ2LjVw dCc+PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMWY0OTdkIiBmYWNlPUNhbGlicmk+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjttc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9Q2FsaWJyaT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT1DYWxpYnJpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2ZvbnQtd2VpZ2h0OmJvbGQnPkZy b206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjttc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+IGpzb24tYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmpzb24tYm91bmNlc0BpZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9J2ZvbnQt d2VpZ2h0OmJvbGQnPk9uIEJlaGFsZiA8c3BhbiBjbGFzcz1HcmFtRT5PZjwvc3Bhbj4gPC9zcGFu PjwvYj5UaW0gQnJheTxicj48Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8 L3NwYW4+PC9iPiBUaHVyc2RheSwgQXVndXN0IDA4LCAyMDEzIDg6NDYgUE08YnI+PGI+PHNwYW4g c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IFBldGUgUmVzbmljazxicj48 Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4ganNvbkBpZXRm Lm9yZzxicj48Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+ PC9iPiBSZTogW0pzb25dIDxzcGFuIGNsYXNzPUdyYW1FPlNvbWU8L3NwYW4+IHRob3VnaHRzIG9u IHRoZSAmcXVvdDt0ZXh0IG1vZGVsJnF1b3Q7IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdCc+T0ssIHNpbmNlIGdlbmVyYWwgZGlzY3Vzc2lvbiBoYXMgbm90IGJyb2tlbiBvdXQsIGxl dOKAmXMgYmUgdmVyeSBzcGVjaWZpYyBpbiBhbnN3ZXIgdG8gUGV0ZeKAmXMgcXVlc3Rpb246PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTIuMHB0Jz5PbiBXZWQsIEp1bCAzMSwgMjAxMyBhdCAyOjExIEFNLCBQZXRl IFJlc25pY2sgJmx0OzxhIGhyZWY9Im1haWx0bzpwcmVzbmlja0BxdGkucXVhbGNvbW0uY29tIiB0 YXJnZXQ9Il9ibGFuayI+cHJlc25pY2tAcXRpLnF1YWxjb21tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5G b3IgZWFjaCBvZiB0aGVzZSB0aHJlZSBpdGVtcywgSSB0aGluayBpZiB3ZSBlbmQgdXAgd2l0aCBz b21lIGV4cGxhbmF0b3J5IHRleHQgaW4gdGhlIGRvY3VtZW50cyB0aGF0IGhlbHBzIG1ha2UgdGhl IGFwcHJvcHJpYXRlIGRpc3RpbmN0aW9ucyAoYW5kIG5vdGUgdGhhdCBJIGFtIGJlaW5nIHB1cnBv c2VseSBhZ25vc3RpYyBvbiB3aGF0IHRoZSBXRyBzaG91bGQgc2F5IGFib3V0IGVhY2ggb2YgdGhl bSksIEkgdGhpbmsgdGhhdCB3b3VsZCBoZWxwIHRoZSBjbGFyaXR5IGFuZCBpbXBsZW1lbnRhYmls aXR5IG9mIHRoZSBzcGVjLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkkgcHJvcG9zZSB0aGlzIGFz IHRoZSBleHBsYW5hdG9yeSB0ZXh0IGZvciB0aGUgLWJpczo8YnI+PGJyPiZsdDsmbHQ7Jmx0OyZs dDsmbHQ7Jmx0OyZsdDsmbHQ7Jmx0OyZsdDsmbHQ7Jmx0OyZsdDsmbHQ7Jmx0OyZsdDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIu MHB0Jz5BIEpTT04gdGV4dCB3aGljaCBpcyBjb21wb3NlZCBlbnRpcmVseSBvZiBVbmljb2RlIGNo YXJhY3RlcnMgKGhvd2V2ZXIgZW5jb2RlZCkgd2lsbCBiZSBpbnRlcm9wZXJhYmxlIGluIHRoZSBz ZW5zZSB0aGF0IGFsbCBVbmljb2RlLWNhcGFibGUgc29mdHdhcmUgd2hpY2ggcGFyc2VzIGl0IHdp bGwgYWdyZWUgb24gdGhlIGNvbnRlbnRzIG9mIG5hbWVzIGFuZCB2YWx1ZXMgb2Ygb2JqZWN0IG1l bWJlcnMuJm5ic3A7IEhvd2V2ZXIsIHRoZSBBQk5GIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBhbGxv d3MgbWVtYmVyIG5hbWVzIGFuZCBzdHJpbmcgdmFsdWVzIHRvIGNvbnRhaW4gYml0IHNlcXVlbmNl cyB3aGljaCBjYW5ub3QgZW5jb2RlIFVuaWNvZGUgY2hhcmFjdGVycywgZm9yIGV4YW1wbGUgJnF1 b3Q7XHVkZGRkJnF1b3Q7IChhbiB1bnBhaXJlZCBVVEYtMTYgc3Vycm9nYXRlKS4mbmJzcDsgSW5z dGFuY2VzIG9mIHRoaXMgaGF2ZSBiZWVuIG9ic2VydmVkLCBmb3IgZXhhbXBsZSB3aGVuIGEgbGli cmFyeSB0cnVuY2F0ZXMgYSBVVEYtMTYgc3RyaW5nIHRvIGEgbWF4aW11bSBhbGxvd2FibGUgbGVu Z3RoIHdpdGhvdXQgY2hlY2tpbmcgd2hldGhlciB0aGUgdHJ1bmNhdGlvbiBzcGxpdCBhIHN1cnJv Z2F0ZSBwYWlyLiZuYnNwOyBUaGUgYmVoYXZpb3Igb2Ygc29mdHdhcmUgd2hpY2ggcmVjZWl2ZXMg SlNPTiB0ZXh0cyBjb250YWluaW5nIHN1Y2ggdmFsdWVzIGlzIHVucHJlZGljdGFibGU7IGZvciBl eGFtcGxlLCB0d28gZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBtaWdodCByZXR1cm4gZGlmZmVy ZW50IHZhbHVlcyBmb3IgdGhlIGxlbmd0aCBvZiBhIHN0cmluZyB2YWx1ZSwgb3IgZXZlbiBzdWZm ZXIgYSBmYXRhbCBydW50aW1lIGV4Y2VwdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMi4wcHQnPiZsdDsmbHQ7Jmx0OyZsdDsmbHQ7Jmx0OyZsdDsmbHQ7Jmx0OyZsdDsmbHQ7 Jmx0OyZsdDsmbHQ7Jmx0OyZsdDsmbHQ7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhhdOKAmXMgYWxsLiBQ b2ludCBvdXQgdGhlIHByb2JsZW0gYXMgZXhhY3RseSBhbmQgY2xlYXJseSBhcyBwb3NzaWJsZSwg dGhlbiBzaHV0IHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48YnI+SSdsbCBsZWF2ZSBpdCB0byB0aGUg Y2hhaXJzIHRvIGRlY2lkZSB3aGVyZSB0byB0YWtlIHRoZSBkaXNjdXNzaW9uIGZyb20gaGVyZS48 Zm9udCBjb2xvcj0iIzg4ODg4OCI+PHNwYW4gc3R5bGU9J2NvbG9yOiM4ODg4ODgnPjxicj48YnI+ PHNwYW4gY2xhc3M9aG9lbnpiPnByPC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPi0t IDwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPlBldGUgUmVzbmljayZsdDs8YSBocmVmPSJo dHRwOi8vd3d3LnF1YWxjb21tLmNvbS9+cHJlc25pY2svIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3d3dy5xdWFsY29tbS5jb20vfnByZXNuaWNrLzwvYT4mZ3Q7PC9zcGFuPjxicj48c3BhbiBjbGFz cz1ob2VuemI+UXVhbGNvbW0gVGVjaG5vbG9naWVzLCBJbmMuIC0gPGEgaHJlZj0idGVsOiUyQjEl MjAlMjg4NTglMjk2NTEtNDQ3OCIgdGFyZ2V0PSJfYmxhbmsiPisxICg4NTgpNjUxLTQ0Nzg8L2E+ PC9zcGFuPjxicj48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3BhbiBjbGFzcz1ob2VuemI+anNv biBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuIGNsYXNzPWhvZW56Yj48YSBocmVmPSJtYWls dG86anNvbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpzb25AaWV0Zi5vcmc8L2E+PC9zcGFu Pjxicj48c3BhbiBjbGFzcz1ob2VuemI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qc29uIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qc29uPC9hPjwvc3Bhbj48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_C68CB012D9182D408CED7B884F441D4D34728C1388nambxv01acorp_-- From johnl@iecc.com Sun Aug 11 08:15:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54C21F9A26 for ; Sun, 11 Aug 2013 08:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.715 X-Spam-Level: X-Spam-Status: No, score=-105.715 tagged_above=-999 required=5 tests=[AWL=-3.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e5NpBB9UcRv for ; Sun, 11 Aug 2013 08:15:48 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9D21F9AA2 for ; Sun, 11 Aug 2013 08:08:22 -0700 (PDT) Received: (qmail 45465 invoked from network); 11 Aug 2013 15:08:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Aug 2013 15:08:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5207a8e5.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=1vrOSQMhV9jBjlglOpHG2MuADXNWGXIO2RxCjhjgGrQ=; b=u9pI6kptzGFDhYg8MfwiAS/wEB+0kiaZCgGu87Z2pZ2KAjv/Djs7glR/p9fngsnL/37RzuIdJt1tHKJcLhftrFsDI+TR8ejLCkYLzIjmprnw09dQakkRspONyYgetdVzv12dWUWb/7ffsY3/58NX4SrydzpLk8FCvx1nppolHdZVMq4ZRIe3hFuOTLRO8O0+uYa2yeAgBtrtqhPHGZLiZSmb62gfj06Cja/uURDDzp5hdXrQS+OsRUyajk51mLAO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5207a8e5.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=1vrOSQMhV9jBjlglOpHG2MuADXNWGXIO2RxCjhjgGrQ=; b=CSiW1R96V/ROCXotVDnMgPGdHHocF9LZeD09J7UY2z7lQ+UdXmEO9+372Vi+g7QAXIHIiRoYWWkug130VBWzeGvucnaBtNTXuqvxRunXCz5rdQzFar7ejoOMVy5c42ffBPydnVppGJK80NBE2pyuJDnmWbV6PZBWm19Y2aXzOqaT7mM1ER4LBWzd7+mo7uIb5d80jItqgbNYk5g91R9a5tLmmafxb9JGV2Rten6NQVZz6OfxTaNP8DxBxUXFPxeZ Date: 11 Aug 2013 15:07:59 -0000 Message-ID: <20130811150759.14085.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: masinter@adobe.com Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Aug 2013 15:15:53 -0000 >As with XML and other , the serialization of the JSON model is conceptually handled on >multiple levels:: ... looks great up to >However, a JSON parser (mapping from 3 to 2) may encounter repeated attributes, and MUST >ignore all but the last it encounters. Uh, no. If there were any hope of agreeing to that, we wouldn't be having this argument. From masinter@adobe.com Sun Aug 11 19:30:23 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8521E808C for ; Sun, 11 Aug 2013 19:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULf+sUdzD2Xk for ; Sun, 11 Aug 2013 19:30:17 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id CDECF21F949F for ; Sun, 11 Aug 2013 19:24:38 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUghHS2iXshnJbH/d2CBTWudBJPfZjWyJ@postini.com; Sun, 11 Aug 2013 19:24:40 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7C2O9lQ015118; Sun, 11 Aug 2013 19:24:10 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7C2O86A025272; Sun, 11 Aug 2013 19:24:08 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sun, 11 Aug 2013 19:24:08 -0700 From: Larry Masinter To: John Levine , "json@ietf.org" Date: Sun, 11 Aug 2013 19:24:04 -0700 Thread-Topic: [Json] Some thoughts on the "text model" discussion Thread-Index: Ac6WpKCHEJi/C560SL6a0s+lvqnMvgAW4DaQ Message-ID: References: <20130811150759.14085.qmail@joyce.lan> In-Reply-To: <20130811150759.14085.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Aug 2013 02:30:24 -0000 TXkgaG9wZSB3YXMgdGhhdCBieSBiZWluZyBjbGVhciBhYm91dCB0aGUgcmVwcmVzZW50YXRpb24g bGF5ZXJzDQooMSBwcm9ncmFtbWluZy1sYW5ndWFnZSAvIDIgYWJzdHJhY3QgSlNPTiAvIDMgc2Vx dWVuY2Utb2YtY2hhcmFjdGVycyAvIDQgc2VxdWVuY2Utb2YtYnl0ZXMpDQoNCnRoZSBkZXNpZ24g Y2hvaWNlcyBmb3IgInJlcGVhdGVkIGF0dHJpYnV0ZXMiIG1pZ2h0IGZpbmQgc29tZSByZXNvbHV0 aW9uLg0KDQpTb21lIDEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzIHdoaWNoIGhhdmUgSlNPTiBzdXBw b3J0IG1pZ2h0IHN1cHBvcnQgZHVwbGljYXRlDQplbGVtZW50cyAoZS5nLiwgdXNpbmcgYW4gICdh LWxpc3QnIGluIExpc3ApIHdoaWxlIG90aGVycyB3aWxsIG5vdCAoYW4gb2JqZWN0IGluIEphdmFT Y3JpcHQpLg0KDQpSZXF1aXJpbmcgdGhlIDEgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgdG8gc3VwcG9y dCBkdXBsaWNhdGUgYXR0cmlidXRlIG5hbWVzDQp3b3VsZCBiZSBhbiB1bnJlYXNvbmFibGUgYnVy ZGVuLiAgRm9yIHRoaXMgcmVhc29uLCB0aGUgMiBhYnN0cmFjdCBKU09OIG1vZGVsDQpzaG91bGQg KElNTykgYXZvaWQgc3VwcG9ydGluZyBkdXBsaWNhdGUgbmFtZXMuDQoNCkhvd2V2ZXIsIGl0J3Mg cHJldHR5IGNsZWFyIHRoYXQgYXQgdGhlIDQgc2VxdWVuY2Utb2YtYnl0ZXMgYW5kIDMgc2VxdWVu Y2Utb2YtY2hhcmFjdGVyDQpsZXZlbCB0aGF0IGR1cGxpY2F0ZSBhdHRyaWJ1dGUgbmFtZXMgYXJl IHBvc3NpYmxlLCBhbmQgdGhlIGJlaGF2aW9yIG9mIDMtPjIgIHBhcnNlcnMNCndoZW4gZW5jb3Vu dGVyaW5nIHN1Y2ggbWlnaHQgYmUgc3BlY2lmaWVkLCBhbHRob3VnaCB0aGUgY2hvaWNlIGJldHdl ZW4NCiJzaWduYWwgZXJyb3IiIGFuZCAidGFrZSBsYXN0IiBhcmUgYm90aCBjb25zaXN0ZW50IHdp dGggIm1pZ2h0IG9jY3VyIGluIDMgYnV0DQpub3Qgc3VwcG9ydGVkIGluIDIiLg0KDQpXaXRoIG5v bi1Vbmljb2RlIGNvZGUgcG9pbnRzIGluIHN0cmluZ3MsIHRoZXJlIGlzIGEgc2ltaWxhciBsYXll ciBzaGlmdCwgYWx0aG91Z2gNCnRoZXJlIGlzIGEgZG91YmxlLWVuY29kaW5nICBpbiBzdHJpbmcg dmFsdWVzIC0tIGlmIDQgLT4gMyBpcyBhY3R1YWxseSBVVEY4DQpvciBVVEYxNiBvbmx5LCB0aGVu ICAiXHUwMDVDIiBpcyBzdGlsbCBhIHNlcXVlbmNlIG9mIDYgVW5pY29kZSBjaGFyYWN0ZXJzLCAN CmFuZCAzLT4yIG5lZWRzIHRvIGFsc28gaGFuZGxlIG9yIGVycm9yIG9uIG5vbi1Vbmljb2RlIGNv ZGUgcG9pbnRzIA0Kd2hpY2ggKElNTykgc2hvdWxkbid0IGJlIGFsbG93ZWQgYXQgMi1hYnN0cmFj dC1KU09OLg0KDQpUaGUgZ29hbCBpcyB0byBhY2tub3dsZWRnZSBsaWJlcmFsIGFjY2VwdGFuY2Ug b2YgMy1zZXF1ZW5jZS1vZi1jaGFyYWN0ZXINCmRpdmVyc2lvbnMgZXZlbiBpZiAyLWFic3RyYWN0 LUpTT04gaXMgbGltaXRlZCBhcyB0byBub3QgaW1wb3NlIHVuZHVlIGJ1cmRlbnMNCmF0IDEtcHJv Z3JhbW1pbmctbGFuZ3VhZ2UtbW9kZWwuDQoNCkxhcnJ5DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRvOmpvaG5sQHRhdWdoLmNvbV0N Cj4gU2VudDogU3VuZGF5LCBBdWd1c3QgMTEsIDIwMTMgNTowOCBQTQ0KPiBUbzoganNvbkBpZXRm Lm9yZw0KPiBDYzogTGFycnkgTWFzaW50ZXINCj4gU3ViamVjdDogUmU6IFtKc29uXSBTb21lIHRo b3VnaHRzIG9uIHRoZSAidGV4dCBtb2RlbCIgZGlzY3Vzc2lvbg0KPiANCj4gPkFzIHdpdGggWE1M IGFuZCBvdGhlciAsIHRoZSBzZXJpYWxpemF0aW9uIG9mIHRoZSBKU09OIG1vZGVsIGlzIGNvbmNl cHR1YWxseQ0KPiBoYW5kbGVkIG9uDQo+ID5tdWx0aXBsZSBsZXZlbHM6Og0KPiANCj4gIC4uLiBs b29rcyBncmVhdCB1cCB0bw0KPiANCj4gPkhvd2V2ZXIsIGEgSlNPTiBwYXJzZXIgKG1hcHBpbmcg ZnJvbSAzIHRvIDIpIG1heSBlbmNvdW50ZXIgcmVwZWF0ZWQNCj4gYXR0cmlidXRlcywgYW5kIE1V U1QNCj4gPmlnbm9yZSBhbGwgYnV0IHRoZSBsYXN0IGl0IGVuY291bnRlcnMuDQo+IA0KPiBVaCwg bm8uICBJZiB0aGVyZSB3ZXJlIGFueSBob3BlIG9mIGFncmVlaW5nIHRvIHRoYXQsIHdlIHdvdWxk bid0IGJlDQo+IGhhdmluZyB0aGlzIGFyZ3VtZW50Lg0KDQo= From tbray@textuality.com Sun Aug 11 20:03:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684E121F9D7E for ; Sun, 11 Aug 2013 20:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hseIrf+4VYSv for ; Sun, 11 Aug 2013 20:03:19 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93E21E80A5 for ; Sun, 11 Aug 2013 19:57:09 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ht10so2414963vcb.10 for ; Sun, 11 Aug 2013 19:57:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fkLiOurbktyLze0GeCxZ8T77zgBT2dxXflD5274bIRo=; b=Bn5twT7ezhi7YJp/G4Fm0qIXa/8m3DGo0kWdSe0Y8tEd8bn5hOlbpoCtp3XOU1PRxl mVsey2HgLwmf6c+OzRy1P4n7VoaT9OndgT79qfVtMGIqilPzzXa4MGYwIVmjuXygysmC xZbkfI9CnJFxCazSUQFiARIdhGKAwlb+3ly0TKNkjzVBD5FlmN3w6meEjU+LXgJmiUhH C4/O8meiLlIQsHY9Og5Fz0WqeC4wzkQCBQkGrSTSDlg2A52l0GDMH1q7rNgMApNNgGvE GJVCoMtUGyOdXUFWLDxv1M4ZppSBvAfUP0eczLRRldOTHp4SJOs0Q1+3GKgzkz84CTmc egcg== X-Gm-Message-State: ALoCoQmBTfsEwEPHVY0OncqhBAWfpwrkF2OY993zD8rSXvAHceNiQh90hqHoo6spLr7enNa08mFJ MIME-Version: 1.0 X-Received: by 10.59.7.1 with SMTP id cy1mr5485597ved.79.1376276226709; Sun, 11 Aug 2013 19:57:06 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Sun, 11 Aug 2013 19:57:06 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20130811150759.14085.qmail@joyce.lan> Date: Sun, 11 Aug 2013 19:57:06 -0700 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=047d7bf0dff09b1f3f04e3b747d6 Cc: John Levine , "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Aug 2013 03:03:24 -0000 --047d7bf0dff09b1f3f04e3b747d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From where I sit there are only two levels that matter: 1. Application-level: A developer needs to ship some data over the network. 2. Everything else: turn the data into a byte sequence, arrange to get them received as transmitted, turn them back from a byte sequence into something useful at the application layer. >From the level-1 point of view (which is shared by everyone who is using JSON for their HTTP-based APIs), duplicate keys are always bugs. Anything that=E2=80=99s not a Unicode character is always a bug. But we can=E2=80=99= t fix that in the -bis, so we should just describe what is interoperable and what isn=E2= =80=99t. -T On Sun, Aug 11, 2013 at 7:24 PM, Larry Masinter wrote: > My hope was that by being clear about the representation layers > (1 programming-language / 2 abstract JSON / 3 sequence-of-characters / 4 > sequence-of-bytes) > > the design choices for "repeated attributes" might find some resolution. > > Some 1 programming languages which have JSON support might support > duplicate > elements (e.g., using an 'a-list' in Lisp) while others will not (an > object in JavaScript). > > Requiring the 1 programming language to support duplicate attribute names > would be an unreasonable burden. For this reason, the 2 abstract JSON > model > should (IMO) avoid supporting duplicate names. > > However, it's pretty clear that at the 4 sequence-of-bytes and 3 > sequence-of-character > level that duplicate attribute names are possible, and the behavior of > 3->2 parsers > when encountering such might be specified, although the choice between > "signal error" and "take last" are both consistent with "might occur in 3 > but > not supported in 2". > > With non-Unicode code points in strings, there is a similar layer shift, > although > there is a double-encoding in string values -- if 4 -> 3 is actually UTF= 8 > or UTF16 only, then "\u005C" is still a sequence of 6 Unicode characters= , > and 3->2 needs to also handle or error on non-Unicode code points > which (IMO) shouldn't be allowed at 2-abstract-JSON. > > The goal is to acknowledge liberal acceptance of 3-sequence-of-character > diversions even if 2-abstract-JSON is limited as to not impose undue > burdens > at 1-programming-language-model. > > Larry > > > > -----Original Message----- > > From: John Levine [mailto:johnl@taugh.com] > > Sent: Sunday, August 11, 2013 5:08 PM > > To: json@ietf.org > > Cc: Larry Masinter > > Subject: Re: [Json] Some thoughts on the "text model" discussion > > > > >As with XML and other , the serialization of the JSON model is > conceptually > > handled on > > >multiple levels:: > > > > ... looks great up to > > > > >However, a JSON parser (mapping from 3 to 2) may encounter repeated > > attributes, and MUST > > >ignore all but the last it encounters. > > > > Uh, no. If there were any hope of agreeing to that, we wouldn't be > > having this argument. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7bf0dff09b1f3f04e3b747d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From where I sit there are only two le= vels that matter:

1. Application-level: A developer needs to s= hip some data over the network.
2. Everything else: turn the data = into a byte sequence, arrange to get them received as transmitted, turn the= m back from a byte sequence into something useful at the application layer.=

From the level-1 point of view (which is shared by everyone who i= s using JSON for their HTTP-based APIs), duplicate keys are always bugs. An= ything that=E2=80=99s not a Unicode character is always a bug. But we can= =E2=80=99t fix that in the -bis, so we should just describe what is interop= erable and what isn=E2=80=99t.

=C2=A0-T




On Sun, Aug 11, 2013 at 7:24 P= M, Larry Masinter <masinter@adobe.com> wrote:
My hope was that by being clear about the re= presentation layers
(1 programming-language / 2 abstract JSON / 3 sequence-of-characters / 4 se= quence-of-bytes)

the design choices for "repeated attributes" might find some reso= lution.

Some 1 programming languages which have JSON support might support duplicat= e
elements (e.g., using an =C2=A0'a-list' in Lisp) while others will = not (an object in JavaScript).

Requiring the 1 programming language to support duplicate attribute names would be an unreasonable burden. =C2=A0For this reason, the 2 abstract JSON= model
should (IMO) avoid supporting duplicate names.

However, it's pretty clear that at the 4 sequence-of-bytes and 3 sequen= ce-of-character
level that duplicate attribute names are possible, and the behavior of 3-&g= t;2 =C2=A0parsers
when encountering such might be specified, although the choice between
"signal error" and "take last" are both consistent with= "might occur in 3 but
not supported in 2".

With non-Unicode code points in strings, there is a similar layer shift, al= though
there is a double-encoding =C2=A0in string values -- if 4 -> 3 is actual= ly UTF8
or UTF16 only, then =C2=A0"\u005C" is still a sequence of 6 Unico= de characters,
and 3->2 needs to also handle or error on non-Unicode code points
which (IMO) shouldn't be allowed at 2-abstract-JSON.

The goal is to acknowledge liberal acceptance of 3-sequence-of-character diversions even if 2-abstract-JSON is limited as to not impose undue burden= s
at 1-programming-language-model.

Larry


> -----Original Message-----
> From: John Levine [mailto:johnl@tau= gh.com]
> Sent: Sunday, August 11, 2013 5:08 PM
> To: json@ietf.org
> Cc: Larry Masinter
> Subject: Re: [Json] Some thoughts on the "text model" discus= sion
>
> >As with XML and othe= r , the serialization of the JSON model is conceptually
> handled on
> >multiple levels::
>
> =C2=A0... looks great up to
>
> >However, a JSON parser (mapping from 3 to 2) may encounter repeate= d
> attributes, and MUST
> >ignore all but the last it encounters.
>
> Uh, no. =C2=A0If there were any hope of agreeing to that, we wouldn= 9;t be
> having this argument.

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

--047d7bf0dff09b1f3f04e3b747d6-- From johnl@taugh.com Sun Aug 11 20:11:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1859A21F9A27 for ; Sun, 11 Aug 2013 20:11:12 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaZLXNhKK26s for ; Sun, 11 Aug 2013 20:11:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8011421F9BFF for ; Sun, 11 Aug 2013 20:03:22 -0700 (PDT) Received: (qmail 69772 invoked from network); 12 Aug 2013 03:03:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1108b.52085077.k1308; bh=0peiA0cgfs6qGbC9MjMuGvHUyVt1AtxWedv36lMr+3s=; b=ZJkE/fFJyfNt3kQ8iXOtlkQ/++IX8tEcDfUfl2Re7CflDJecEVT+tq6SUgwD0betqvjGuRSn/Yjzd9j7krQPSr9b7pfreF28alI8CbJZ+0yATfMNReJ2pls9uzERMy+cAlcmz+o7YkyhmgrED9cMbGaVnfUe846N2uFfixnxoa6+ofd2T/PApmWNB1ZAJSGeR1jbQLyiEwQyTzawz65zJdY5JjInnICOL6JRTc6cqciO60jUd7kMS/HmnQGvml38 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1108b.52085077.k1308; bh=0peiA0cgfs6qGbC9MjMuGvHUyVt1AtxWedv36lMr+3s=; b=ZSkicsZuNsA6s7Ot/KM0dW3fR+UIdUjPK2Mlf3wNrkBt+7cAmb5MuVnRkR8Jrqmr5PyNK1NjszV/LqzxpT78zetfpLiTBwYVXIfdROEQO/ndhuMOhG1440m2wcjA9DocbiHHCOdXqX7N8DmG2XvaQF5v0PkavEvkPsldsiik2Ijl3gmYKZaSN4U/J3Z0V02ODorscK94rDrR7TEenn1FOoaB7kwqIIz4NYBWkdmsSexHJkh17gQ3zQyzutfWhHSu Received: (ofmipd 127.0.0.1); 12 Aug 2013 03:02:57 -0000 Date: 11 Aug 2013 23:03:19 -0400 Message-ID: From: "John R Levine" To: "Larry Masinter" In-Reply-To: References: <20130811150759.14085.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Aug 2013 03:11:14 -0000 > The goal is to acknowledge liberal acceptance of 3-sequence-of-character > diversions even if 2-abstract-JSON is limited as to not impose undue burdens > at 1-programming-language-model. If you'll review the previous thousand messages or so on this topic, I don't think you'll find any that argue that duplicate keys are a good idea, but you'll find plenty that say for whatever reason there is real json that has dup keys. It's a decade too late to wave our hands and make it go away. Javascript, which is still probably the dominant json environment, has a concrete way to deal with dup keys, so the undue burden argument isn't very persusasive. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From tbray@textuality.com Sun Aug 11 21:02:16 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8D21E80AF for ; Sun, 11 Aug 2013 21:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbL2SGYW4JFn for ; Sun, 11 Aug 2013 21:02:11 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8B07721F9DDC for ; Sun, 11 Aug 2013 20:56:47 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id id13so2000077vcb.18 for ; Sun, 11 Aug 2013 20:56:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oLhLIxWc7ktc8b184noVv7KI8l7fykp4/WL/lzF32Dc=; b=QpaOBHSN76Mb6fNZBYqwJw8uzYagqDGQgoeSlCE6/oBILsKej2UsooDlPvw/d+GU4/ HKJKde1zR6L98LvFwOKF+VXxCisPLKIqugPDJ+0vP60FzImORBsIW3wvPnvNlFEaY8A3 dzbvRe4MVdr54uptEXjuEjE8TSAVmYIJBDbv+iF3xZEjgqX6iY4Vm0fHgEVE401yE57h RcTRKivfBHNgrcwpD0yDfg/MF5f9gblydrSyPyTvG59/GmNF0OYlN/vH++kM1nn+hLgR Ejp7loyNcwmD6gsKvnLl1oZbYi83wkBlsGz+kw8kRUgTVY0DqG4Um/0JJPnz5VT7SQx9 0mvw== X-Gm-Message-State: ALoCoQnqSbTDYgPmVcTJ0lQnYZwYPrNGblMZcq1/Occu9HGouAhirh6AsZcmQXpmkA91ChTljVDc MIME-Version: 1.0 X-Received: by 10.220.184.202 with SMTP id cl10mr11833361vcb.69.1376279806791; Sun, 11 Aug 2013 20:56:46 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Sun, 11 Aug 2013 20:56:46 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20130811150759.14085.qmail@joyce.lan> Date: Sun, 11 Aug 2013 20:56:46 -0700 Message-ID: From: Tim Bray To: John R Levine Content-Type: multipart/alternative; boundary=001a11c1bc64fee6d304e3b81ce9 Cc: "json@ietf.org" , Larry Masinter Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Aug 2013 04:02:16 -0000 --001a11c1bc64fee6d304e3b81ce9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 11, 2013 at 8:03 PM, John R Levine wrote: > Javascript, which is still probably the dominant json environment, has a > concrete way to deal with dup keys, so the undue burden argument isn't ve= ry > persusasive. > I=E2=80=99ve used a whole lot of JSON over the years in Ruby, Java, and Go,= but never JavaScript. Your claim of JavaScript=E2=80=99s =E2=80=9Cdominance=E2= =80=9D is entirely without supporting evidence and can safely be ignored. Having said that; yeah, I don=E2=80=99t think there=E2=80=99s consensus eit= her for saying dupe keys etc are a good thing, or for trying to abolish them in the -bis. That leaves documenting what=E2=80=99s interoperable and what=E2=80=99s not= . -T > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --001a11c1bc64fee6d304e3b81ce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 11, 2013 at 8:03 PM, John R Levine <johnl@tau= gh.com> wrote:
Javascript, which is still probably the domi= nant json environment, has a concrete way to deal with dup keys, so the und= ue burden argument isn't very persusasive.

I=E2=80=99ve used a whole lot of JSON over= the years in Ruby, Java, and Go, but never JavaScript. Your claim of JavaS= cript=E2=80=99s =E2=80=9Cdominance=E2=80=9D is entirely without supporting = evidence and can safely be ignored.

Having said that; yeah, I don=E2=80=99t think there=E2=80=99= s consensus either for saying dupe keys etc are a good thing, or for trying= to abolish them in the -bis.=C2=A0 That leaves documenting what=E2=80=99s = interoperable and what=E2=80=99s not.=C2=A0 -T

=C2=A0

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

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

--001a11c1bc64fee6d304e3b81ce9-- From sayrer@gmail.com Mon Aug 12 19:14:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53021E8054 for ; Mon, 12 Aug 2013 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYKVZTPYyQOz for ; Mon, 12 Aug 2013 19:14:56 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB4511E80FE for ; Mon, 12 Aug 2013 19:14:53 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so81934wib.3 for ; Mon, 12 Aug 2013 19:14:52 -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=bYm3afy4UDR1yLMOa8j20qD3uXLuPm7/jnXRASDOliU=; b=rXCBbylEFCcNKa3hJK6osmL9KZPpE7JOeHBRbI+wqJTpjoOSP4spVT5ltK4cP6G5Vi Q1vtdMVKCQmJqrJTwltsHSeIsTW4NGw9COZV21VbgtSyecgX3Pn2K81aTHipOK7r8R5H +REB/rKu9qDqn5RcKZ/aEipd7jTRnTSGgLS5WyD2Xm2KdfOqbOJxg3n4PI/29a6PnCNe rPD1f8e/siV5DnPRKITQIPD89b8ra3bq6V2ymD1zrv4y8V8fLNXH5A5T2z2AbdCE/dHs PkQlwpWUsH4q7XlU9dmKErXqMq2ElSL8gGQbHLTMxW4FiZKTQixp9+OZZtNF73tfA9Kp 6jCg== MIME-Version: 1.0 X-Received: by 10.180.13.43 with SMTP id e11mr1017338wic.21.1376360091990; Mon, 12 Aug 2013 19:14:51 -0700 (PDT) Received: by 10.194.43.129 with HTTP; Mon, 12 Aug 2013 19:14:51 -0700 (PDT) In-Reply-To: References: <20130811150759.14085.qmail@joyce.lan> Date: Mon, 12 Aug 2013 19:14:51 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c247625dbfbd04e3cace56 Cc: Larry Masinter , John R Levine , "json@ietf.org" Subject: Re: [Json] Some thoughts on the "text model" discussion X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 02:14:57 -0000 --001a11c247625dbfbd04e3cace56 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Aug 11, 2013 at 8:56 PM, Tim Bray wrote: > > I=92ve used a whole lot of JSON over the years in Ruby, Java, and Go, but > never JavaScript. Your claim of JavaScript=92s =93dominance=94 is entirel= y > without supporting evidence and can safely be ignored. > Well, "dominance" is probably the wrong word. I'd say "definitiveness" would be more appropriate--it is JavaScript Object Notation. Why would you want a JSON library that blew up on JSON successfully handled by JavaScript implementations, which all interoperate basically perfectly? Even your proposed text doesn't have much proof yet: "or even suffer a fatal runtime exception.". The only example we saw on this list was a Python 3 exception. But its JSON implementation handled unpaired surrogates just fine, the exception was in the print function. Further, JSON library authors generally don't get involved with unicode encoding issues. That's handled by libraries like Mozilla's nsIUnicodeDecoder < http://dxr.mozilla.org/mozilla-central/source/intl/uconv/src> and V8's Unibrow . - Rob --001a11c247625dbfbd04e3cace56 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 11, 2013 at 8:56 PM, Tim Bray <tbray@textu= ality.com> wrote:

I=92ve used a whole lot of JSON= over the years in Ruby, Java, and Go, but never JavaScript. Your claim of = JavaScript=92s =93dominance=94 is entirely without supporting evidence and = can safely be ignored.

Well, "dominance" is probably the wrong word. I'd say &q= uot;definitiveness" would be more appropriate--it is JavaScript Object= Notation. Why would you want a JSON library that blew up on JSON successfu= lly handled by JavaScript implementations, which all interoperate basically= perfectly?

Even your p= roposed text doesn't have much proof yet: "or even suffer a fa= tal runtime exception.". The only example we saw on this list was a Py= thon 3 exception. But its JSON implementation handled unpaired surrogates j= ust fine, the exception was in the print function.

= Further, JSON library authors generally don't get involved with uni= code encoding issues. That's handled by libraries like Mozilla's ns= IUnicodeDecoder <http://dxr.mozilla.org/mozilla-central/source/intl/uconv/src> and= =A0V8's Unibrow <= http://v8reference.com/namespaceunibrow.html>.

- Rob
--001a11c247625dbfbd04e3cace56-- From paul.hoffman@vpnc.org Tue Aug 13 09:22:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6733D11E818B for ; Tue, 13 Aug 2013 09:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3U6dKRHPrgx for ; Tue, 13 Aug 2013 09:22:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E531F11E818F for ; Tue, 13 Aug 2013 09:22:01 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7DGLw5a084210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Aug 2013 09:21:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16B1C52A-04E0-4522-B55D-559217A73FEA@vpnc.org> Date: Tue, 13 Aug 2013 09:21:58 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Agenda for next week's virtual interim WG meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 16:22:02 -0000 Agenda for JSON WG Virtual Interim Meeting Wednesday August 21, 2013, 1500 UTC 1. Introduction What we hope to achieve Practicalities 2. JSON character model 3. Duplicate keys in objects 4. Next steps From masinter@adobe.com Wed Aug 14 08:49:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F221F9B5C for ; Wed, 14 Aug 2013 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhaFB90Kb3rx for ; Wed, 14 Aug 2013 08:49:51 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id E429521F9DE9 for ; Wed, 14 Aug 2013 08:49:50 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUgunFgkE46Qwa3ea/LdvBD/ac+gG8owK@postini.com; Wed, 14 Aug 2013 08:49:51 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7EFnelQ022972; Wed, 14 Aug 2013 08:49:41 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7EFnew7002903; Wed, 14 Aug 2013 08:49:40 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Wed, 14 Aug 2013 08:49:40 -0700 From: Larry Masinter To: Paul Hoffman , "json@ietf.org WG" Date: Wed, 14 Aug 2013 08:49:36 -0700 Thread-Topic: [Json] Agenda for next week's virtual interim WG meeting Thread-Index: Ac6YQUVtUmmzuFm5RFCShCV33OQbOAAxCfFA Message-ID: References: <16B1C52A-04E0-4522-B55D-559217A73FEA@vpnc.org> In-Reply-To: <16B1C52A-04E0-4522-B55D-559217A73FEA@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Agenda for next week's virtual interim WG meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 15:49:56 -0000 How about ECMA/TC39 coordination specifically? > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, August 13, 2013 6:22 PM > To: json@ietf.org WG > Subject: [Json] Agenda for next week's virtual interim WG meeting >=20 > Agenda for JSON WG Virtual Interim Meeting > Wednesday August 21, 2013, 1500 UTC >=20 > 1. Introduction > What we hope to achieve > Practicalities > 2. JSON character model > 3. Duplicate keys in objects > 4. Next steps >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From paul.hoffman@vpnc.org Wed Aug 14 08:57:01 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4281911E817D for ; Wed, 14 Aug 2013 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.094 X-Spam-Level: X-Spam-Status: No, score=-101.094 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, FRT_ADOBE2=2.455, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkWZi7-nX0nz for ; Wed, 14 Aug 2013 08:56:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7821E80B5 for ; Wed, 14 Aug 2013 08:56:54 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7EFun51024274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Aug 2013 08:56:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 14 Aug 2013 08:56:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16B1C52A-04E0-4522-B55D-559217A73FEA@vpnc.org> To: Larry Masinter X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Agenda for next week's virtual interim WG meeting X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 15:57:01 -0000 On Aug 14, 2013, at 8:49 AM, Larry Masinter wrote: > How about ECMA/TC39 coordination specifically? Specifically what? Are you asking that we repeat what was said at the = meeting in Berlin, or is there something more you want? --Paul Hoffman= From mamille2@cisco.com Fri Aug 16 14:46:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7922421F9E21 for ; Fri, 16 Aug 2013 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUTdkawqNCjw for ; Fri, 16 Aug 2013 14:46:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5F11E8194 for ; Fri, 16 Aug 2013 14:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9155; q=dns/txt; s=iport; t=1376689573; x=1377899173; h=from:to:subject:date:message-id:mime-version; bh=Xiq9NVv6tnfajPYNjpzgKVXa37vUr0Zg9LnAOqfzrss=; b=UDlIo1l7IFgjlx6rMR/mluxvhQxdGspFUPeZokGi103cLRT/Sb14N3Pm 7Jeockk+tyHlgYoPkKvMjsjDwZMExAY5l3dWmj19zpVQ/OvNKRMCWjigI jR/pGfXBOerSiTLhR9OLtyD+ikw74XcLbHgP/ZgYvs9FPybvYhiy7xcGM U=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHacDlKtJXHB/2dsb2JhbABBFwODBjVRvyCBKxZ0giYBBFURAiMBHA4KBAwMMCQDBBMIAQWIAgwymGSTG40GhVKHdIE9G4EBCwsKASgHgwN3A5AWgS6CSZUsgktRgXE5 X-IronPort-AV: E=Sophos;i="4.89,897,1367971200"; d="p7s'?scan'208";a="248415281" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 16 Aug 2013 21:46:13 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7GLkD9c024995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Aug 2013 21:46:13 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.132]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 16:46:12 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: Venue details for virtual interim WG meeting 2013-08-21T15:00:00Z Thread-Index: AQHOmsoGfCOz4AhuCEW31j8IC4NNDQ== Date: Fri, 16 Aug 2013 21:46:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.53] Content-Type: multipart/signed; boundary="Apple-Mail=_DAD4F6F9-4E4D-464A-A3A0-D734CEC830EE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Venue details for virtual interim WG meeting 2013-08-21T15:00:00Z X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Aug 2013 21:46:21 -0000 --Apple-Mail=_DAD4F6F9-4E4D-464A-A3A0-D734CEC830EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello All, Below are the the Webex meeting details for the virtual interim WG = meeting on August 21 at 15:00 UTC. This information is also in the = current draft of the agenda at < = http://www.ietf.org/proceedings/interim/2013/08/21/json/agenda/agenda-inte= rim-2013-json-1 >. The chairs will be relying on the Jabber room < = xmpp:json@jabber.ietf.org?join > for all text-based discussion during = the interim (including determination of speaking order, if needed); we = ask that everyone to join both. Thanks, - Paul Hoffman and Matt Miller -----BEGIN WEBEX----- Topic: JSON Date: Wednesday, August 21, 2013 Time: 3:00 pm, Greenwich Time (Reykjavik, GMT) Meeting Number: 644 826 810 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&PW=3DNZD= g3ODljYzIy&RT=3DMiMyMA%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&PW=3DNZD= g3ODljYzIy&ORT=3DMiMyMA%3D%3D ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:644 826 810 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: mconner@amsl.com To add this meeting to your calendar program (for example Microsoft = Outlook), click this link: = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&ICS=3DMI= &LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAprlsAaI34SAsCSkcO8k7VxMsYSMyV4Cg0bS9UDnF= ofo&RT=3DMiMyMA%3D%3D The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x644826810#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. -----END WEBEX----- --Apple-Mail=_DAD4F6F9-4E4D-464A-A3A0-D734CEC830EE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MTYyMTQ2 MTJaMCMGCSqGSIb3DQEJBDEWBBQECyDDtt031mbd5MgnnDV4nCN1tzCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAH73 eNAuo4BPg9vRS+bJSGi3eIU1/zu52wIppcziaOxEkUQHHGzxF/XsPhlX/X/UJoJttg0YxC9G6P46 MKi4xcm67ew9Xd2IKL2NCTFX30ZmFiSnIc4H8vRcwLdQrGVM/hppxeIOts2QtzC3Js8pDd/4tkaw 3HeltwB2cnP04x7PYa+jq7umeNDPOZIoPUjOo62kn/GbKANiRuJ4mrOuR65034gT7a0P7LwcGo6j rnYJPS0eZ1K5L4obATbk6yua7Pre4BJdCuOmleL+Ts7Q1fxmfuYHslnjoZqO4uU4eKJAH+illhvN Z1LNiIovN4Sl5AO0T7sNbaKNM/+LYKBlXfgAAAAAAAA= --Apple-Mail=_DAD4F6F9-4E4D-464A-A3A0-D734CEC830EE-- From paul.hoffman@vpnc.org Mon Aug 19 19:20:35 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8289211E8155 for ; Mon, 19 Aug 2013 19:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+gN3O+mRVgQ for ; Mon, 19 Aug 2013 19:20:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DE11E8328 for ; Mon, 19 Aug 2013 19:20:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7K2KVQQ060977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Aug 2013 19:20:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 19 Aug 2013 19:20:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Venue details for virtual interim WG meeting 2013-08-21T15:00:00Z X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 02:20:35 -0000 [[ Just a brief reminder of the meeting on Wednesday. And that there is = no problem if people want to keep the current topics alive between now = and then! ]] On Aug 16, 2013, at 2:46 PM, Matt Miller (mamille2) = wrote: > Hello All, >=20 > Below are the the Webex meeting details for the virtual interim WG = meeting on August 21 at 15:00 UTC. This information is also in the = current draft of the agenda at < = http://www.ietf.org/proceedings/interim/2013/08/21/json/agenda/agenda-inte= rim-2013-json-1 >. >=20 > The chairs will be relying on the Jabber room < = xmpp:json@jabber.ietf.org?join > for all text-based discussion during = the interim (including determination of speaking order, if needed); we = ask that everyone to join both. >=20 >=20 > Thanks, >=20 > - Paul Hoffman and Matt Miller >=20 > -----BEGIN WEBEX----- > Topic: JSON > Date: Wednesday, August 21, 2013 > Time: 3:00 pm, Greenwich Time (Reykjavik, GMT) > Meeting Number: 644 826 810 > Meeting Password: 1234 >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&PW=3DNZD= g3ODljYzIy&RT=3DMiMyMA%3D%3D > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". >=20 > To view in other time zones or languages, please click the link: > = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&PW=3DNZD= g3ODljYzIy&ORT=3DMiMyMA%3D%3D >=20 > ------------------------------------------------------- > To join the audio conference only=20 > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 >=20 > Access code:644 826 810 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > mconner@amsl.com >=20 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link: > = https://ietf.webex.com/ietf/j.php?ED=3D232085382&UID=3D1613639047&ICS=3DMI= &LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAprlsAaI34SAsCSkcO8k7VxMsYSMyV4Cg0bS9UDnF= ofo&RT=3DMiMyMA%3D%3D >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 >=20 > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial >=20 > http://www.webex.com >=20 > CCP:+16504793208x644826810#=20 >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. >=20 > -----END WEBEX----- From cabo@tzi.org Wed Aug 21 14:56:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0174611E8202 for ; Wed, 21 Aug 2013 14:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.55 X-Spam-Level: X-Spam-Status: No, score=-105.55 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaRiIo4z7UxP for ; Wed, 21 Aug 2013 14:56:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B803011E8129 for ; Wed, 21 Aug 2013 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7LLu8nM026078 for ; Wed, 21 Aug 2013 23:56:08 +0200 (CEST) Received: from [192.168.217.100] (p5489121D.dip0.t-ipconnect.de [84.137.18.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1FDA518E; Wed, 21 Aug 2013 23:56:08 +0200 (CEST) From: Carsten Bormann Content-Type: multipart/alternative; boundary=Apple-Mail-AB52060D-E63E-415D-B0E0-B7CB214A3BF4 X-Mailer: iPad Mail (10B329) Message-Id: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> Date: Wed, 21 Aug 2013 23:56:09 +0200 To: "json@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 21:56:21 -0000 --Apple-Mail-AB52060D-E63E-415D-B0E0-B7CB214A3BF4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Today at the interim, there was some recollection of the enormous pain that e= nsued in the XML community when they had to define their data model (infoset= ). =20 One of the reasons people like JSON over XML is that there is no such pain. I have written up the JSON data model below (I allowed about five minutes, p= lease excuse stupid mistakes). Much of the text is already in 4627, by the w= ay (but I didn't bother to copy it verbatim). I don't know whether and how w= e would use that model in 4627bis, but I'd sure like to know if anyone disag= rees with the fact that this is the JSON data model (modulo word-smithing). Gr=C3=BC=C3=9Fe, Carsten A JSON value is one of: - a special value - a string - a number - a structured value. A special value is one of true, false, or null. A string is a sequence of zero or more Unicode characters. A number is a rational number that can be expressed as a fraction of two int= egers where the denominator is a power of ten. A structured value is an array or an object. An array is an (ordered) sequence of zero or more JSON values. An object is an unordered collection of zero or more key-value pairs, where a= key is a string, a value is a JSON value, and the same key cannot be used m= ore than once in the same collection. For the purposes of this comparison, t= wo keys are the same if they are the same sequence of Unicode characters.= --Apple-Mail-AB52060D-E63E-415D-B0E0-B7CB214A3BF4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Today at the interim, there was some r= ecollection of the enormous pain that ensued in the XML community when they h= ad to define their data model (infoset).  

One= of the reasons people like JSON over XML is that there is no such pain.

I have written up the JSON data model below (I allowed= about five minutes, please excuse stupid mistakes).  Much of the text i= s already in 4627, by the way (but I didn't bother to copy it verbatim). &nb= sp;I don't know whether and how we would use that model in 4627bis, but I'd s= ure like to know if anyone disagrees with the fact that this is the JSON dat= a model (modulo word-smithing).

Gr=C3=BC=C3=9Fe, Ca= rsten

A JSON value is one of:
= - a special value
- a stri= ng
- a number
- a structured value.

A special value is one of true, false, or null.

A string is a sequence of zero or more Unicode characters.

A number is a rational number that can be expressed as= a fraction of two integers where the denominator is a power of ten.

A structured value is an array or an object.

An array is an (ordered) sequence of zero or more JSON v= alues.

An object is an unordered collection of z= ero or more key-value pairs, where a key is a string, a value is a JSON valu= e, and the same key cannot be used more than once in the same collection. &n= bsp;For the purposes of this comparison, two keys are the same if they are t= he same sequence of Unicode characters.
= --Apple-Mail-AB52060D-E63E-415D-B0E0-B7CB214A3BF4-- From sgbeal@googlemail.com Wed Aug 21 15:00:45 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73E11E8202 for ; Wed, 21 Aug 2013 15:00:45 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY4mU7i2Xh4e for ; Wed, 21 Aug 2013 15:00:44 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 17C1021F9ACA for ; Wed, 21 Aug 2013 15:00:43 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so891396wgh.21 for ; Wed, 21 Aug 2013 15:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7dOFpcQo6GGwXvfF6Lxpj2OYcchfYfTF6l5FaCz3KNk=; b=iL3NVU8CqBKXGSUz2rnxqlYBdlZBk6Jla3JaC+d+ULXUSt47Rre0q8Oqn5qKNOjv5/ uSji3XZ8RiwibhnduovPoRzJe6KRrXZiTrZ8rWr2iZniHuWi4n8tLwN31q5L/SMUZErY Cd0RACKonYVU091S62lBio+vihPMdKM3GDpiTGJxzHcjuT7D+x6rEicb791QC/6Fz7FL 1qVG6eiuPGp/WepCMayjHssaxt/MtCdjU8m09fzwFf3KGMCLMQtptyKrrRPFhFUZuHGF 0EA8SGp6ijctfvEocUruVYbKc5V6TeXEVi8Oes28FPp2her02hk2EdHuIIUVsh4C4Q5K 6Giw== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr7574376wjc.1.1377122443234; Wed, 21 Aug 2013 15:00:43 -0700 (PDT) Received: by 10.194.192.162 with HTTP; Wed, 21 Aug 2013 15:00:43 -0700 (PDT) In-Reply-To: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> Date: Thu, 22 Aug 2013 00:00:43 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b873d1a0a926504e47c4e6f Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 22:00:45 -0000 --047d7b873d1a0a926504e47c4e6f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 21, 2013 at 11:56 PM, Carsten Bormann wrote: > One of the reasons people like JSON over XML is that there is no such pain. > An object is an unordered collection of zero or more key-value pairs, > where a key is a string, a value is a JSON value, and the same key cannot > be used more than once in the same collection. For the purposes of this > comparison, two keys are the same if they are the same sequence of Unicode > characters. > Amen! Ship it! -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7b873d1a0a926504e47c4e6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 21, 2013 at 11:56 PM, Carsten Bormann <cabo@tzi.or= g> wrote:
One of the reasons people like JSON over XML is that= there is no such pain.
An object is an unordered collection of zero or more key-v= alue pairs, where a key is a string, a value is a JSON value, and the same = key cannot be used more than once in the same collection. =A0For the purpos= es of this comparison, two keys are the same if they are the same sequence = of Unicode characters.


Amen!

Ship it!

--=A0
----- stephan beal
<= a href=3D"http://wanderinghorse.net/home/stephan/" target=3D"_blank">http:/= /wanderinghorse.net/home/stephan/
--047d7b873d1a0a926504e47c4e6f-- From nico@cryptonector.com Wed Aug 21 15:43:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED4E11E823B for ; Wed, 21 Aug 2013 15:43:53 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPKiszdvaQeG for ; Wed, 21 Aug 2013 15:43:49 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC521F968B for ; Wed, 21 Aug 2013 15:43:48 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 3729D40122425 for ; Wed, 21 Aug 2013 15:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=X+R0yKscM/FAYjBoEAAx LGnuJ4U=; b=UbA8tapk9vM50OBCl1nVrT1EljMlauJdqFuT/wkyhIigUHFT2Rh9 kjPLYv+OttpGapnmnjJrKq8jD0bW2Dh5dmOni84yEGD9MS8IymGhYtM1fso9tCVq VIS7QIUjgnebESycpyrzhdtuZyheAmx1xmjm3xRhK9x3qnEoln5kxmE= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id C9A9B4012241B for ; Wed, 21 Aug 2013 15:43:41 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so956995wes.21 for ; Wed, 21 Aug 2013 15:43:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0fygCvJrkxht7kaCmsO7UJ4eg+jwbkW2OjAzK9F9TJ4=; b=XGpetLjMWnFEJoI/HpL06GJpw2y3w/asJAsk9rSbK4kbW7g9xieWRVdfrkHr+tIO7+ AsU5oF6Stn7a2Afh+wirOhz/fES85WTXHDZijg7T+4L4rPoU+CFaomwmilkVmO+7F2k0 gijamQQovylFf2qz3oU1KlmlgcqMF4b7TUUInm38JnMt1C1LSyj1rYe1BokPHZX4UpLW GKhQbRM8vCvKZTGIPx+6CJ0oXqLKJLPzZjpLumyvJJqVi/m//tuqvDKNqTrHqGhVWBB9 bLPMrp4ugxaAwgodbbGz2MV3twj7U1PazSbLj9s2GNjAowzRpOwQq5AdDp0mRxDmBUf4 ziCA== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr7149189wic.36.1377125020018; Wed, 21 Aug 2013 15:43:40 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 21 Aug 2013 15:43:39 -0700 (PDT) In-Reply-To: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> Date: Wed, 21 Aug 2013 17:43:39 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 22:43:53 -0000 Last I checked the consensus was not that we could say "MUST NOT" have dup keys. Now, your data model text doesn't say that -- it's just a data model, right? So it's agreeable on that score (ditto strings and numbers). This can't cause subsequent agreement on such a requirement, so what do we get from this data model? Likely answer: stop the rot. Nits: - if we're going to speak of structured values vs. not, then let's call them scalars and structured (ideally we could use common terminology, but I hesitate to pick one; if I were to suggest ASN.1's "constructed" instead of "structured" I'd get tomatoes thrown my way) - booleans are not special, IMO; they are booleans, so call them that - that leaves null as the only special value - do we want to speak of a type system? some programming languages have null as a type, of which null is the only possible value, which speaks to null not being special - i.e., there are no special values, even null is not that special :) Or if there's a reason that null, true, and false are special, we should state it. Nico -- From tbray@textuality.com Wed Aug 21 16:09:24 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345B611E8183 for ; Wed, 21 Aug 2013 16:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewZ0lx+k3fSw for ; Wed, 21 Aug 2013 16:09:19 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8C21F9A13 for ; Wed, 21 Aug 2013 16:09:19 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oy10so920277veb.6 for ; Wed, 21 Aug 2013 16:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qT7MTYCfrge16T6Qy6N3oISSE1F3QNE6iG8BTiUIjLY=; b=pnhYjz3vTPsyXTO3xz1vkOm5UVM1aYa0mldmc1ftiuIJuZbOOmCDych43Bcztz16aY mG1MMs6LO+TbI4phvsjlOMJzGwld0adHIluv95wAdfU0EbEbhGh5KGYqYxpw9qZGZ8IS DRZx6duuyX0kbRy3uO1R+XGvHdUixFy/Hd6tc3JG60P46BViFxsEka+lANGopY00pZq+ urKHSdWMiPqkcF4TLX6fZXfRzYI5u53WSXcf5m5AHkNjJfXRrF63WGuBJQmN7uGCUcRA +PKtnROnr9iv98k+qoVOsMcYym8SaU9pQrab+7Q6TC21TUSghKsJVVMwkOE1zgqi7v+t y4Ag== X-Gm-Message-State: ALoCoQl5FJsBzt7ubAmyGwhQU5u+roQ69IOHsEnq8lJyoLsSSuknTVYbothU/xgixtZXFPhLrZ+X MIME-Version: 1.0 X-Received: by 10.220.10.194 with SMTP id q2mr8361009vcq.2.1377126557281; Wed, 21 Aug 2013 16:09:17 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Wed, 21 Aug 2013 16:09:17 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> Date: Wed, 21 Aug 2013 16:09:17 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c3b94441fe5504e47d43e2 Cc: "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 23:09:24 -0000 --001a11c3b94441fe5504e47d43e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t understand what value would be added by having this in the = RFC. JSON has already been terrifically successful, and the interoperability nits we know about have nothing to do with model-level misunderstandings. There are a bunch of different data models I could use for {"a": 1, "b": false} and picking any one of them feels like it=E2=80=99s potentially dec= eiving. -T On Wed, Aug 21, 2013 at 2:56 PM, Carsten Bormann wrote: > Today at the interim, there was some recollection of the enormous pain > that ensued in the XML community when they had to define their data model > (infoset). > > One of the reasons people like JSON over XML is that there is no such pai= n. > > I have written up the JSON data model below (I allowed about five minutes= , > please excuse stupid mistakes). Much of the text is already in 4627, by > the way (but I didn't bother to copy it verbatim). I don't know whether > and how we would use that model in 4627bis, but I'd sure like to know if > anyone disagrees with the fact that this is the JSON data model (modulo > word-smithing). > > Gr=C3=BC=C3=9Fe, Carsten > > A JSON value is one of: > - a special value > - a string > - a number > - a structured value. > > A special value is one of true, false, or null. > > A string is a sequence of zero or more Unicode characters. > > A number is a rational number that can be expressed as a fraction of two > integers where the denominator is a power of ten. > > A structured value is an array or an object. > > An array is an (ordered) sequence of zero or more JSON values. > > An object is an unordered collection of zero or more key-value pairs, > where a key is a string, a value is a JSON value, and the same key cannot > be used more than once in the same collection. For the purposes of this > comparison, two keys are the same if they are the same sequence of Unicod= e > characters. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c3b94441fe5504e47d43e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don=E2=80=99t understand what value would be a= dded by having this in the RFC.=C2=A0 JSON has already been terrifically su= ccessful, and the interoperability nits we know about have nothing to do wi= th model-level misunderstandings.=C2=A0

There are a bunch of different data models I could use for {"a&quo= t;: 1, "b": false}=C2=A0 and picking any one of them feels like i= t=E2=80=99s potentially deceiving.

=C2=A0 -T


On Wed, Aug 21, 2013 at 2:56 PM, Carsten= Bormann <cabo@tzi.org> wrote:
Today at the interim, there was some recollection of= the enormous pain that ensued in the XML community when they had to define= their data model (infoset). =C2=A0

One of the rea= sons people like JSON over XML is that there is no such pain.

I have written up the JSON data model below (I allowed = about five minutes, please excuse stupid mistakes). =C2=A0Much of the text = is already in 4627, by the way (but I didn't bother to copy it verbatim= ). =C2=A0I don't know whether and how we would use that model in 4627bi= s, but I'd sure like to know if anyone disagrees with the fact that thi= s is the JSON data model (modulo word-smithing).

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

A JSON value is one of:
- a special value<= /div>
- a string
- a nu= mber
- a structur= ed value.

A special value is one= of true, false, or null.

A s= tring is a sequence of zero or more Unicode characters.

A number is a rational number th= at can be expressed as a fraction of two integers where the denominator is = a power of ten.

A structured value is an array o= r an object.

=
An array is an (ordere= d) sequence of zero or more JSON values.

An object is an unordered collection of zero or more key-value pairs, where= a key is a string, a value is a JSON value, and the same key cannot be use= d more than once in the same collection. =C2=A0For the purposes of this com= parison, two keys are the same if they are the same sequence of Unicode cha= racters.

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


--001a11c3b94441fe5504e47d43e2-- From cabo@tzi.org Wed Aug 21 16:37:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957E31F0ED0 for ; Wed, 21 Aug 2013 16:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.488 X-Spam-Level: X-Spam-Status: No, score=-105.488 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zsj0nOJGQmSG for ; Wed, 21 Aug 2013 16:37:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1874121F90CC for ; Wed, 21 Aug 2013 16:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7LNbdbS002987; Thu, 22 Aug 2013 01:37:39 +0200 (CEST) Received: from [192.168.217.100] (p5489121D.dip0.t-ipconnect.de [84.137.18.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 878B81A4; Thu, 22 Aug 2013 01:37:39 +0200 (CEST) References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> X-Mailer: iPad Mail (10B329) From: Carsten Bormann Date: Thu, 22 Aug 2013 01:37:38 +0200 To: Nico Williams Cc: "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 23:37:56 -0000 > it's just a > data model, right? No, I'm making the strong claim that this is *the* JSON data model. I'm writing this up because I'd like to meet any people who make a serious c= laim that this is not so. (Of course, there is an unlimited number of isomorphic data models where thi= ngs are called in different ways or grouped in different ways, whatever. Co= nsider this claim to be about the class of isomorphic data models.) What is allowed to be interchanged (by an imaginary protocol police?), and w= hether there is a unique mapping into this data model (or any defined mappin= g at all) for everything that is allowed to be interchanged, is a second que= stion that I have not addressed. Ideally, a data format should have the pro= perty that all representations have such a unique mapping. I think we have a= lready agreed that JSON, as deployed, is not ideal. A third question is whether the data model is faithfully implemented by ever= y implementation. The discussion about numbers should have made clear that a= lmost all implementations map JSON numbers into whatever local approximation= is convenient, and range limits (but not loss of precision) are already exp= licitly called out in section 4. All implementations also have size limits a= nd other quantities creating a subset of the data model that can be represen= ted. More interestingly, a number of processes can be implemented on JSON t= exts that do not need to make use of the data model (pretty-printing is the t= rivial example, although that also can involve some cleanup that does requir= e maintaining the data model; and some implementations convert JSON texts fr= om an internal UTF-16 representation to UTF-8 before interchange) or that ad= apt the data model in some way (streaming processors do not reify even an ap= proximation of the data model). And so on, and so on. The data model isn't everything. But if I understand= Larry correctly, I agree with him that it is worthwhile to identify it and t= o define things in relation to it. Gr=C3=BC=C3=9Fe, Carsten From cowan@ccil.org Wed Aug 21 17:42:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0121F95DD for ; Wed, 21 Aug 2013 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fXjNMLhwa6L for ; Wed, 21 Aug 2013 17:42:31 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E36EC21F949F for ; Wed, 21 Aug 2013 17:42:30 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VCIym-0006M3-An; Wed, 21 Aug 2013 20:42:24 -0400 Date: Wed, 21 Aug 2013 20:42:24 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130822004224.GH23853@mercury.ccil.org> References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 00:42:36 -0000 Carsten Bormann scripsit: > No, I'm making the strong claim that this is *the* JSON data model. Well, in my implementation, the model of objects is a Lisp a-list of the form ((jso) ( . ) ( . ) ...), so tant pis. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" cowan@ccil.org From nico@cryptonector.com Wed Aug 21 20:00:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070D11E81BC for ; Wed, 21 Aug 2013 20:00:10 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3ypq1BVoYHQ for ; Wed, 21 Aug 2013 20:00:05 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7158711E81A6 for ; Wed, 21 Aug 2013 20:00:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4DA6750808D for ; Wed, 21 Aug 2013 20:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8dUGAA3J9kHPgsK2fhmt NY20bfo=; b=C6l6tL6uUxzD2v8sjEkSSOv1/gzYem4ME25TM9UmhKIZJJQjaL0y XsIWWflSRXwlIfcoYW/m5drhNCh2m1H8BsGThFhcbI9uDjdsIwmxwN6ozLIHYWfj +rwfeRP5TB9MKbKycXqTxrRR1dmKw1Svh0CLwNBYRqJbEgdgGcBdlRA= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id EC6B5508084 for ; Wed, 21 Aug 2013 20:00:02 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so1138172wes.15 for ; Wed, 21 Aug 2013 20:00:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hbiOD5jIH1Pxgiv3Q9GbGa4z7/M9V6WCr1hzBNe9rpI=; b=oGGqHH9aFeAobokB1zbfiP2dlecElSpBpt8NpPPa0FarXyy4l/FoHvU35eK/cOdP7z VuSNz7aPeQdSG+/0JQxl9EAef4wy2iFn2FHEiMdW5mdmBQIlOW9L9lIRTEi2PTSXqPEy r00p5rcysW2wjJOH9iOLoBsoskWsBORPDvUS2kLTpnZE6SNurben8xsYvcaFqwAyLOTX fobuqzM6/OsVcv6uI6NvQKhqqjWcy2zgIccgCl2Boki0IYW2BGWIBKJL/8b/uYGMuMPS LHw4cR/xfxX2dweyVkgsADBkLWmvw+sp/2lz2EgL9V//B+gxFK+/fTyx7d5aXKspFUUn Ia3Q== MIME-Version: 1.0 X-Received: by 10.180.77.49 with SMTP id p17mr2582978wiw.36.1377140401127; Wed, 21 Aug 2013 20:00:01 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 21 Aug 2013 20:00:01 -0700 (PDT) In-Reply-To: <20130822004224.GH23853@mercury.ccil.org> References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> <20130822004224.GH23853@mercury.ccil.org> Date: Wed, 21 Aug 2013 22:00:01 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 03:00:10 -0000 Yeah, this isn't going to happen either. What can I say but "give it up, accept the rough consensus (and running code)". From mamille2@cisco.com Thu Aug 22 08:51:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E551911E81EB for ; Thu, 22 Aug 2013 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFlzp0gDrEgM for ; Thu, 22 Aug 2013 08:51:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F09FF21F99F4 for ; Thu, 22 Aug 2013 08:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7390; q=dns/txt; s=iport; t=1377186676; x=1378396276; h=from:to:subject:date:message-id:mime-version; bh=BmN4d1C+ugmGev8kffUq2TkezwxjZuGCXT5Zyx1ObtY=; b=Lob/VBL7g69w/kmOHWDM1tg0F/g08BXmC1yXZ9jnZoYvlyZjMT71aJdv 5cZ2HyO/FHhS3caUyggKFgD7ePlM6tSNGQshIRYaKd/Loeg85Hd/V+HEQ 2yvqpYmPQjDaL7EFce1VwInni5RJiQ1n8iRPTrpY21yWlGLSgHmoVbDfw o=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIQyFlKtJXG+/2dsb2JhbABagwU1UcAIgR0WdIImAQRJQgEqJjAnBBsBBYgCDJVVmVmPLYEIM4MgewOQFoEul3yDH4FyOQ X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="p7s'?scan'208";a="250509754" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 22 Aug 2013 15:51:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7MFpCBA004338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Aug 2013 15:51:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.124]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 10:51:12 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: The General Way Forward Thread-Index: AQHOn09sxOkWRu8KrUua5AywgMh7WQ== Date: Thu, 22 Aug 2013 15:51:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.123] Content-Type: multipart/signed; boundary="Apple-Mail=_FB06DAD5-76FC-4836-9009-33A106771C06"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] The General Way Forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:51:21 -0000 --Apple-Mail=_FB06DAD5-76FC-4836-9009-33A106771C06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Working Group had a very productive discussion on August 21 (15:00 = UTC); minutes will be posted presently. The discussion centered on how = to arrive at an acceptable replacement document for RFC 4627. The = general approach discussed in the interim is to document the known = likely interoperability issues. For each issue, the document will note = the most interoperable behavior, and describe a couple of behaviors that = can lead to interoperability problems. The normative language will = remain unchanged. Matt and I want to verify that the WG agrees with this proposal for a = way forwards from yesterday's WG meeting. If you do not agree with the = above, please say so within the next few days, and certainly say why and = what you would prefer instead. If there is WG agreement about this way forward, expect to see new = proposed text changes -- or revival of previously proposed changes -- = written in this vein. With these proposals, we will try using the = acceptance process first posited in < = www.ietf.org/mail-archive/web/json/current/msg00293.html >. The current list of known issues are: * Unicode surrogates * duplicate names in objects * comparison of strings (for object name uniqueness) * number precision Thank you, Paul Hoffman and Matt Miller= --Apple-Mail=_FB06DAD5-76FC-4836-9009-33A106771C06 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MjIxNTUx MTFaMCMGCSqGSIb3DQEJBDEWBBT8O/vDmBjAdEeP4CmFcKjj1T8AuTCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJOn Zb18Hud2X0/GxOnVY9bg36xZyTB/g9dt1ujHK3nc9qHDQYWF3U9iKcQwzgimVQy8DufnlkPnnEbq KXzlNKkJS6kg2m2eUVwEgTlq/bjhWZ05Sj/yK/Mi/uKI0mIMSuywqGaoammcrGIUFuPPkk/sJvex JD8ssgwFnFoERiKhMDWra4JFI/cY+gwcUCbtSGKnxaFhfa7dPeWoZd8I/6rqKZT+5mgAUWX21X5D urfWm2RTFTPYM7xXiQ3rgba7R9Rm4Po8ut/Y6cy4gGq8yu0obntxwYRhxDjfm+c2JwCp+tCD0OF/ gA6AhrfZrjwJR3DmhuWR6ZfB4pVdDrOFEDwAAAAAAAA= --Apple-Mail=_FB06DAD5-76FC-4836-9009-33A106771C06-- From tbray@textuality.com Thu Aug 22 10:45:56 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22D811E81C5 for ; Thu, 22 Aug 2013 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th2VQTHia1OR for ; Thu, 22 Aug 2013 10:45:50 -0700 (PDT) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0A11E81C1 for ; Thu, 22 Aug 2013 10:45:49 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so1499411vbb.22 for ; Thu, 22 Aug 2013 10:45:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oEqokOacz1Gi0+GJHb4vkWTfEnoRCKf0D5XwEJinDWA=; b=KeogTSHWRf/l1HnecTOR28QKVeLeWYFGty5Lwhunv5/grtv8e8JbhQSc4eWOH9li/f h8XIcd2B09iGyI6vpavUgCVIsCH1nzW3Eg03OPDgmx58CF8DBXEubmiZoE49VdkhCdQO zZAaHyVgNhUcerGhautEAxfjGVkjpbzQqOeWdHva40wGyxRvoCugJyqqYbyiAPujmIZO 7ySM97/GQBNr2NnNPlhsEIUzR6Rz89Uw7Qi8AgPO/HzAjYBbfXDIl4e+9tonTypkdd4/ d25Ju0AF08cJLPbyPtABXzrfRxknRMvzXyWkSE9fSd4XxggSaa+alVb8pkrEgR7rZmLK BukQ== X-Gm-Message-State: ALoCoQm8qLCOTzwdkM7OyJyRQ0NU5PQ3UVWq3ZuYbFqLcL2Vo5Zz9g/5oarM4+8GbkrhDIVlFKAN MIME-Version: 1.0 X-Received: by 10.58.155.68 with SMTP id vu4mr12581959veb.21.1377193547558; Thu, 22 Aug 2013 10:45:47 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 22 Aug 2013 10:45:47 -0700 (PDT) X-Originating-IP: [96.49.81.176] Date: Thu, 22 Aug 2013 10:45:47 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b604d0230811204e48cdcb8 Subject: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:45:56 -0000 --047d7b604d0230811204e48cdcb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we have consensus that naked surrogates are an area we=E2=80=99re g= oing to highlight as potentially leading to interop problems. I=E2=80=99m wondering if Unicode =E2=80=9CNoncharacters=E2=80=9D fall into = the same bucket. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Quoting from Unicode 6.2 section 2.4: Noncharacters. Sixty-six code points are not used to encode characters. Noncharacters consist of U+FDD0..U+FDEF and any code point ending in the value FFFE16 or FFFF16=E2=80=94 that is, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U+10FFFE, U+10FFFF. (See Section 16.7, Noncharacters.) And 16.7 begins: Noncharacters are code points that are permanently reserved in the Unicode Standard for internal use. They are forbidden for use in open interchange of Unicode text data. See Section 3.4, Characters and Encoding, for the formal definition of noncharacters and conformance requirements related to their use. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So, does anyone think there=E2=80=99s any likelihood that generic unicode-processing software is apt to barf or otherwise act in surprising ways if one of these things turns up? Worth calling out in -bis? --047d7b604d0230811204e48cdcb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think we have consensus that naked surrog= ates are an area we=E2=80=99re going to highlight as potentially leading to= interop problems.=C2=A0

I=E2=80=99m wondering if Unicode =E2= =80=9CNoncharacters=E2=80=9D fall into the same bucket.=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Quoting from Unicode 6.2 section 2.4:
=
Noncharacters. Sixty-six code points are not used to encode characters.= Noncharacters
consist of U+FDD0..U+FDEF and any code point ending in th= e value FFFE16 or FFFF16=E2=80=94
that is, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U+10FFFE, U+10FFFF. (See
= Section 16.7, Noncharacters.)

And 16.7 begins:

Nonchar= acters are code points that are permanently reserved in the Unicode Standar= d for internal use. They are forbidden for use in open interchange of Unico= de text data. See Section 3.4, Characters and Encoding, for the formal defi= nition of noncharacters and conformance requirements related to their use.<= br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So, does anyone t= hink there=E2=80=99s any likelihood that generic unicode-processing softwar= e is apt to barf or otherwise act in surprising ways if one of these things= turns up?=C2=A0 Worth calling out in -bis?
--047d7b604d0230811204e48cdcb8-- From cabo@tzi.org Thu Aug 22 11:04:14 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717DC11E815C for ; Thu, 22 Aug 2013 11:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.983 X-Spam-Level: X-Spam-Status: No, score=-105.983 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfRJFI-lcyY5 for ; Thu, 22 Aug 2013 11:04:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9FA21F9E7E for ; Thu, 22 Aug 2013 11:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7MI45KK017925; Thu, 22 Aug 2013 20:04:05 +0200 (CEST) Received: from [192.168.217.105] (p548921DA.dip0.t-ipconnect.de [84.137.33.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 926E071A; Thu, 22 Aug 2013 20:04:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Aug 2013 20:04:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E0BB4C0-CA20-40C3-98CB-82A96F3F89EE@tzi.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] =?windows-1252?q?Character_interop=2C_=93Noncharacters=94?= =?windows-1252?q?=3F?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:04:14 -0000 On Aug 22, 2013, at 19:45, Tim Bray wrote: > So, does anyone think there=92s any likelihood that generic = unicode-processing software is apt to barf or otherwise act in = surprising ways if one of these things turns up? Worth calling out in = -bis? Given the number of JSON implementations, you probably can find an = instance for any unreasonable idea you can come up with. https://github.com/couchdeveloper/JPJson/issues/4 Gr=FC=DFe, Carsten From cabo@tzi.org Thu Aug 22 11:28:36 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC321F9984 for ; Thu, 22 Aug 2013 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.13 X-Spam-Level: X-Spam-Status: No, score=-106.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERREuy3bXOFB for ; Thu, 22 Aug 2013 11:28:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C86A21F99F4 for ; Thu, 22 Aug 2013 11:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7MISKiq002898; Thu, 22 Aug 2013 20:28:20 +0200 (CEST) Received: from [192.168.217.105] (p548921DA.dip0.t-ipconnect.de [84.137.33.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9D60472A; Thu, 22 Aug 2013 20:28:19 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Aug 2013 20:28:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86497454-2B9E-48A7-B546-547C42AAD9CA@tzi.org> References: To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] The General Way Forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:28:36 -0000 On Aug 22, 2013, at 17:51, "Matt Miller (mamille2)" = wrote: > The current list of known issues are: I didn't quite get the conclusion of what seemed to be a brief = discussion of this at the virtual interim, but any use of the Unicode = encodings other than UTF-8 would be a real-world interop problem, too. (The only reason I can find that it might not be a "likely" interop = problem is that it's not happening a lot in the first place.) Gr=FC=DFe, Carsten From cowan@ccil.org Thu Aug 22 12:25:37 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7500C11E815C for ; Thu, 22 Aug 2013 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8CMjlIGkwQk for ; Thu, 22 Aug 2013 12:25:33 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5176E11E8112 for ; Thu, 22 Aug 2013 12:25:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VCaVe-00011G-1a; Thu, 22 Aug 2013 15:25:30 -0400 Date: Thu, 22 Aug 2013 15:25:30 -0400 From: John Cowan To: Tim Bray Message-ID: <20130822192529.GV23853@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:25:37 -0000 Tim Bray scripsit: > I think we have consensus that naked surrogates are an area we’re > going to highlight as potentially leading to interop problems. > > I’m wondering if Unicode “Noncharacters” fall into the same > bucket. [snip] > And 16.7 begins: > > Noncharacters are code points that are permanently reserved in the > Unicode Standard for internal use. They are forbidden for use in open > interchange of Unicode text data. See Section 3.4, Characters and > Encoding, for the formal definition of noncharacters and conformance > requirements related to their use. That part of Unicode has been updated by Corrigendum #9: Clarification About Noncharacters , which is retroactive to Unicode 3.1 and says in part: Noncharacters in the Unicode Standard are intended for internal use and have no standard interpretation when exchanged outside the context of internal use. However, they are not illegal in interchange nor do they cause ill-formed Unicode text. This has always been the intent of the standard, as expressed by the Unicode Technical Committee. This is necessary for the effective use of noncharacters, because anytime a Unicode string crosses an API boundary, it is in effect being "interchanged". Furthermore, for distributed software, it is often very difficult to determine what constitutes an "internal" versus an "external" context for any particular software process. The real intent of noncharacters is that they are permanently prohibited from being assigned standard, interchangeable meanings, rather than that they are prohibited from occurring in Unicode strings which happen to be interchanged. > So, does anyone think there’s any likelihood that generic > unicode-processing software is apt to barf or otherwise act in > surprising ways if one of these things turns up? Worth calling out in > -bis? My reading of the above is that it would have been all right to prohibit noncharacters in JSON, but since that didn't happen, they should not be considered problematic. I know of no APIs that treat them specially. So I would say no to both questions. A fortiori, there seems no reason to expect problems with any other class of Unicode code points. -- John Cowan cowan@ccil.org http://ccil.org/~cowan 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 nico@cryptonector.com Thu Aug 22 12:34:46 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1C11E81CD for ; Thu, 22 Aug 2013 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQEK8ArrVKoV for ; Thu, 22 Aug 2013 12:34:41 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6F11E81C5 for ; Thu, 22 Aug 2013 12:34:41 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 667D459807D for ; Thu, 22 Aug 2013 12:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+AoKpnclLCzy1msjLuER F9D5YBg=; b=rFa+Vhju1gRs4GqKuWCupWMW8qY7pf3ajVUmvYMZ7w2KMXZePbmM 6GlWftDs9zZ0iudPrg/tOi397jLCm6VsuLD7k3Sv8TjypBppSABsqBn4pTYUoAPF uEPZLP1+bkOZEM0VHXdNeaoNAxnS/jJ51lkiz8WicUjeL5KBBf6stOk= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 07E72598065 for ; Thu, 22 Aug 2013 12:34:40 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so2011687wgh.25 for ; Thu, 22 Aug 2013 12:34:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BKBrrt+QcwZexAF4RArCMSoLgcGXUHTe3N6Z6YwKPTY=; b=LxLPY71qHTKa1u1PlXyiMLzP4H3HdDFtE2kS/ZO0+xnYW1DON7Y6sqvvwTqbYJvKX+ uoJd5NOuhIVK23WUYUb7L1PxlNy5P7KHp5zoh/4fAtZkAsmgCU4LQHO+LX3qM69XYKAc sR1PUgELH8KUregCdB3uF28cvVDhXxIW6z49oA4bgrpnVKORVFRvYjNNpID8LJSX7MRO cHUSO6Om/7vgT2tDzwbphqdUm6jp8ctsiCW1zfqTE3XloARQNNROopmdDOsHEkVbVpMr FrDCWTuY0aeivINcXmP+D2Pk2xokwjodTSuQYgO4O0U78lrKp6F2tYfOElJV1YVR8nLl myXw== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr11073693wic.36.1377200079655; Thu, 22 Aug 2013 12:34:39 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Thu, 22 Aug 2013 12:34:39 -0700 (PDT) In-Reply-To: <20130822192529.GV23853@mercury.ccil.org> References: <20130822192529.GV23853@mercury.ccil.org> Date: Thu, 22 Aug 2013 14:34:39 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:34:46 -0000 On Thu, Aug 22, 2013 at 2:25 PM, John Cowan wrote: > My reading of the above is that it would have been all right to prohibit > noncharacters in JSON, but since that didn't happen, they should not be > considered problematic. I know of no APIs that treat them specially. > So I would say no to both questions. > > A fortiori, there seems no reason to expect problems with any other > class of Unicode code points. +1. IMO naked surrogates are the only Unicode problem for us to consider. We could and should give advice as to what to do when receiving JSON string values with naked surrogates, perhaps: "parsers SHOULD remove [or replace with...] naked surrogates" and/or "parsers SHOULD signal the presence of naked surrogates", or something along those lines. From cowan@ccil.org Thu Aug 22 19:16:59 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7367611E8186 for ; Thu, 22 Aug 2013 19:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r66bJmR6ob5S for ; Thu, 22 Aug 2013 19:16:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2269F11E810B for ; Thu, 22 Aug 2013 19:16:53 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VCgeF-00009O-Iz; Thu, 22 Aug 2013 21:58:47 -0400 Date: Thu, 22 Aug 2013 21:58:47 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130823015847.GZ23853@mercury.ccil.org> References: <4E0BB4C0-CA20-40C3-98CB-82A96F3F89EE@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0BB4C0-CA20-40C3-98CB-82A96F3F89EE@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 02:16:59 -0000 Carsten Bormann scripsit: > Given the number of JSON implementations, you probably can find an > instance for any unreasonable idea you can come up with. > > https://github.com/couchdeveloper/JPJson/issues/4 I've just added a comment to that page pointing to Corrigendum #9. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone cowan@ccil.org will die someday. http://www.ccil.org/~cowan --From a Nigerian-type scam spam From cowan@ccil.org Thu Aug 22 22:16:21 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9042A11E81D6 for ; Thu, 22 Aug 2013 22:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbhZvQOrpnQr for ; Thu, 22 Aug 2013 22:16:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4124911E81D0 for ; Thu, 22 Aug 2013 22:16:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VCjjI-0003yn-4j; Fri, 23 Aug 2013 01:16:12 -0400 Date: Fri, 23 Aug 2013 01:16:12 -0400 From: John Cowan To: Nico Williams Message-ID: <20130823051612.GB23853@mercury.ccil.org> References: <20130822192529.GV23853@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 05:16:21 -0000 Nico Williams scripsit: > We could and should give advice as to what to do when receiving JSON > string values with naked surrogates, perhaps: "parsers SHOULD remove > [or replace with...] naked surrogates" and/or "parsers SHOULD signal > the presence of naked surrogates", or something along those lines. I am absolutely opposed to that. A JSON parser in an environment where strings are naturally 16-bit code units (JVM, CLR, JavaScript) can and most likely will treat unpaired surrogates as nothing special. (I'm assuming here that "naked" means "unpaired" rather than "unescaped"; unescaped unpaired surrogates are invalid encoding anyway, and below the level of JSON.) -- Why are well-meaning Westerners so concerned that John Cowan the opening of a Colonel Sanders in Beijing means cowan@ccil.org the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey. --Marshall Sahlins From nico@cryptonector.com Thu Aug 22 23:21:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A746C11E82C5 for ; Thu, 22 Aug 2013 23:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDIQJbXISSWB for ; Thu, 22 Aug 2013 23:21:48 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id F423511E82C3 for ; Thu, 22 Aug 2013 23:21:47 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 6244836006B for ; Thu, 22 Aug 2013 23:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BiqCviP55ZYf0KJK9MXm JNnVH58=; b=hTWUm+hFTEO8LxFC1Dn25d1Esd2NXH+tZf81g6Euu7kasB2ixCJd KKHyKiKiyRUitwpD1qLO3THJQxMOcrG2vmq659mqKvN875BnmuTC0C+2qnqVJGJH 7SXZpX5R4aMDkQuLdj7OYCGCLd89bpqnTWRdM8xLSFrg3II4ynetf/8= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 06BD236006A for ; Thu, 22 Aug 2013 23:21:46 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t60so159019wes.17 for ; Thu, 22 Aug 2013 23:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JE+sOcpCUeJ4bPFRfASmRU9iWQlioIWxLANz50O8+6o=; b=eTfRFAyeVbgpy2fhKrRaEKsV8KW3cd545kVOX5rSbahIn0af67kiXzyrax/ePh2A0O BXDupQ7ZBUGEZxnqRhSxx2QelJYreyjqJW9DiSYaZN46yGJEdOXAdCoWOYYf3repQZF3 YkRkOml/naBVI8Yl7fMuCkb+0E7aW521mknA2iJEGlSSrntiPzCHk7XxFTgxF4N6I7Zk 1VSfanVhEknjgJ2ItyoWa9vnR7ahSDS/v+8ZP4Km8KNMeN3uhSJy+N9kT8nrc50qtZGR f22H1QjPI2zwuz2cwMYmQS4nd+wBO5Gbx02Ce+ZgtPQh8yT/GskggWrQC8kkDhVP2E56 iY4g== MIME-Version: 1.0 X-Received: by 10.180.77.49 with SMTP id p17mr861124wiw.36.1377238905210; Thu, 22 Aug 2013 23:21:45 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Thu, 22 Aug 2013 23:21:45 -0700 (PDT) In-Reply-To: <20130823051612.GB23853@mercury.ccil.org> References: <20130822192529.GV23853@mercury.ccil.org> <20130823051612.GB23853@mercury.ccil.org> Date: Fri, 23 Aug 2013 01:21:45 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] =?utf-8?q?Character_interop=2C_=E2=80=9CNoncharacters?= =?utf-8?b?4oCdPw==?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 06:21:53 -0000 On Fri, Aug 23, 2013 at 12:16 AM, John Cowan wrote: > Nico Williams scripsit: >> We could and should give advice as to what to do when receiving JSON >> string values with naked surrogates, perhaps: "parsers SHOULD remove >> [or replace with...] naked surrogates" and/or "parsers SHOULD signal >> the presence of naked surrogates", or something along those lines. > > I am absolutely opposed to that. A JSON parser in an environment > where strings are naturally 16-bit code units (JVM, CLR, JavaScript) > can and most likely will treat unpaired surrogates as nothing > special. (I'm assuming here that "naked" means "unpaired" > rather than "unescaped"; unescaped unpaired surrogates are > invalid encoding anyway, and below the level of JSON.) You're right, and that was a brainfart on my part. I'd forgotten that my own preference had been to pass unpaired surrogates in escaped form. Please excuse the noise. From masinter@adobe.com Fri Aug 23 12:34:54 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4847311E80E4 for ; Fri, 23 Aug 2013 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8fHuyrQjxO6 for ; Fri, 23 Aug 2013 12:34:49 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id BE57C11E81AA for ; Fri, 23 Aug 2013 12:34:48 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUhe5Tw+ciZR7WsyWMgdPyQFtZKHdfsO6@postini.com; Fri, 23 Aug 2013 12:34:48 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7NJV6iH004051; Fri, 23 Aug 2013 12:31:06 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7NJYbw7001565; Fri, 23 Aug 2013 12:34:38 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 23 Aug 2013 12:34:37 -0700 From: Larry Masinter To: Carsten Bormann , Nico Williams Date: Fri, 23 Aug 2013 12:34:33 -0700 Thread-Topic: [Json] JSON data model Thread-Index: Ac6ex3m6oKw89B80RBe/fpYmeDj4JwBbOVog Message-ID: References: <88D9AA6E-8956-45B7-8876-7EDC2A21A9E0@tzi.org> <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> In-Reply-To: <5E153065-4A27-4ACD-98A4-EE6B7319792F@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] JSON data model X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 19:34:54 -0000 SSB0aGluayBqdXN0IHRoYXQgaXQgaXMgdXNlZnVsIHRvIGhhdmUgYW4gYWJzdHJhY3QgZGF0YSBt b2RlbCB3aGljaCBjYW4gYmUgdXNlZCB0byBleHBsYWluIGludGVyb3BlcmFiaWxpdHkgaXNzdWVz LiBJIGRvbid0IHRoaW5rIGl0IG5lZWRzIHRvIGJlIG5vcm1hdGl2ZS4NCj09PT09PT09PT09PT09 PT09DQoNCkludGVyb3BlcmFiaWxpdHkgaXNzdWVzDQoNCkl0IGlzIHVzZWZ1bCB0byB0aGluayBv ZiBKU09OIGF0IGZvdXIgbGV2ZWxzLCB3aXRoIHdlbGwta25vd24gdHJhbnNmb3JtYXRpb25zIGJl dHdlZW4gdGhlIGxldmVsczoNCg0Kc3RyZWFtIG9mIGJ5dGVzIDwtLT4gc3RyZWFtIG9mIFVuaWNv ZGUgY29kZSBwb2ludHMgPC0+IGRhdGEgbW9kZWwgPC0+IHByb2dyYW1taW5nIGxhbmd1YWdlIGRh dGENCg0KDQpXaGlsZSBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBldmVyIGluc3RhbnRpYXRlIHRo ZSAiIGRhdGEgbW9kZWwiLCBtb3N0IG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBhcmUg ZHVlIHRvIHdlYWtuZXNzZXMgKGluY29tcGxldGUgbWFwcGluZykgb2YgdGhlIG1hcHBpbmcgYmV0 d2VlbiBkYXRhIG1vZGVsIDwtPiBwcm9ncmFtbWluZyBsYW5ndWFnZSBkYXRhOg0KDQpFeGFtcGxl IDE6IHNvbWUgbnVtYmVycyBpbiB0aGUgZGF0YSBtb2RlbCBjYW4ndCBiZSByZXByZXNlbnRlZCBp biB0aGUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgKGJlY2F1c2Ugb2YgcHJlY2lzaW9uIG9yIHJhbmdl KSwgYW5kIHNvbWUgbnVtYmVycyBpbiB0aGUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgZGF0YSBjYW4n dCBiZSByZXByZXNlbnRlZCBpbiB0aGUgZGF0YSBtb2RlbCAoZS5nLiwgTmFOLCBJbmZpbml0eSku DQoNCkV4YW1wbGUgMjogVGhlIEpTT04gTUlNRSB0eXBlIChzdHJlYW0gb2YgYnl0ZXMpIGFuZCB0 aGUgInN0cmVhbSBvZiBVbmljb2RlIGNvZGUgcG9pbnRzIiBkbyBub3QgZGlzYWxsb3cgZHVwbGlj YXRlIGtleXM7IHNvbWUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UgaW1wbGVtZW50YXRpb25zIGFsc28g c3VwcG9ydCBkdXBsaWNhdGUga2V5cyAoZS5nLiwgYSBMaXNwIGEtbGlzdCByZXByZXNlbnRhdGlv bikuIEJ1dCB0aGUgZGF0YSBtb2RlbCBkb2VzIG5vdCBzdXBwb3J0IGR1cGxpY2F0ZSBrZXlzLCBh bmQgZHVwbGljYXRlIGtleXMgd2lsbCBoYXZlIHBvb3IgaW50ZXJvcGVyYWJpbGl0eS4gDQoNCkV4 YW1wbGUgMzogQWxsIGZvdXIgbGV2ZWxzIGFsbG93IHVubWF0Y2hlZCBzdXJyb2dhdGUgcGFpcnMg b2YgVW5pY29kZSBjb2RlIHBvaW50cy4NCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGpzb24tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpzb24tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IENhcnN0ZW4gQm9ybWFubg0KPiBTZW50OiBUaHVy c2RheSwgQXVndXN0IDIyLCAyMDEzIDE6MzggQU0NCj4gVG86IE5pY28gV2lsbGlhbXMNCj4gQ2M6 IGpzb25AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtKc29uXSBKU09OIGRhdGEgbW9kZWwNCj4g DQo+ID4gaXQncyBqdXN0IGENCj4gPiBkYXRhIG1vZGVsLCByaWdodD8NCj4gDQo+IE5vLCBJJ20g bWFraW5nIHRoZSBzdHJvbmcgY2xhaW0gdGhhdCB0aGlzIGlzICp0aGUqIEpTT04gZGF0YSBtb2Rl bC4NCj4gSSdtIHdyaXRpbmcgdGhpcyB1cCBiZWNhdXNlIEknZCBsaWtlIHRvIG1lZXQgYW55IHBl b3BsZSB3aG8gbWFrZSBhIHNlcmlvdXMNCj4gY2xhaW0gdGhhdCB0aGlzIGlzIG5vdCBzby4NCj4g DQo+IChPZiBjb3Vyc2UsIHRoZXJlIGlzIGFuIHVubGltaXRlZCBudW1iZXIgb2YgaXNvbW9ycGhp YyBkYXRhIG1vZGVscyB3aGVyZQ0KPiB0aGluZ3MgYXJlIGNhbGxlZCBpbiBkaWZmZXJlbnQgd2F5 cyBvciBncm91cGVkIGluIGRpZmZlcmVudCB3YXlzLCB3aGF0ZXZlci4NCj4gQ29uc2lkZXIgdGhp cyBjbGFpbSB0byBiZSBhYm91dCB0aGUgY2xhc3Mgb2YgaXNvbW9ycGhpYyBkYXRhIG1vZGVscy4p DQo+IA0KPiBXaGF0IGlzIGFsbG93ZWQgdG8gYmUgaW50ZXJjaGFuZ2VkIChieSBhbiBpbWFnaW5h cnkgcHJvdG9jb2wgcG9saWNlPyksIGFuZA0KPiB3aGV0aGVyIHRoZXJlIGlzIGEgdW5pcXVlIG1h cHBpbmcgaW50byB0aGlzIGRhdGEgbW9kZWwgKG9yIGFueSBkZWZpbmVkDQo+IG1hcHBpbmcgYXQg YWxsKSBmb3IgZXZlcnl0aGluZyB0aGF0IGlzIGFsbG93ZWQgdG8gYmUgaW50ZXJjaGFuZ2VkLCBp cyBhIHNlY29uZA0KPiBxdWVzdGlvbiB0aGF0IEkgaGF2ZSBub3QgYWRkcmVzc2VkLiAgSWRlYWxs eSwgYSBkYXRhIGZvcm1hdCBzaG91bGQgaGF2ZSB0aGUNCj4gcHJvcGVydHkgdGhhdCBhbGwgcmVw cmVzZW50YXRpb25zIGhhdmUgc3VjaCBhIHVuaXF1ZSBtYXBwaW5nLiAgSSB0aGluayB3ZSBoYXZl DQo+IGFscmVhZHkgYWdyZWVkIHRoYXQgSlNPTiwgYXMgZGVwbG95ZWQsIGlzIG5vdCBpZGVhbC4N Cj4gDQo+IEEgdGhpcmQgcXVlc3Rpb24gaXMgd2hldGhlciB0aGUgZGF0YSBtb2RlbCBpcyBmYWl0 aGZ1bGx5IGltcGxlbWVudGVkIGJ5IGV2ZXJ5DQo+IGltcGxlbWVudGF0aW9uLiAgVGhlIGRpc2N1 c3Npb24gYWJvdXQgbnVtYmVycyBzaG91bGQgaGF2ZSBtYWRlIGNsZWFyIHRoYXQNCj4gYWxtb3N0 IGFsbCBpbXBsZW1lbnRhdGlvbnMgbWFwIEpTT04gbnVtYmVycyBpbnRvIHdoYXRldmVyIGxvY2Fs DQo+IGFwcHJveGltYXRpb24gaXMgY29udmVuaWVudCwgYW5kIHJhbmdlIGxpbWl0cyAoYnV0IG5v dCBsb3NzIG9mIHByZWNpc2lvbikgYXJlDQo+IGFscmVhZHkgZXhwbGljaXRseSBjYWxsZWQgb3V0 IGluIHNlY3Rpb24gNC4gIEFsbCBpbXBsZW1lbnRhdGlvbnMgYWxzbyBoYXZlIHNpemUNCj4gbGlt aXRzIGFuZCBvdGhlciBxdWFudGl0aWVzIGNyZWF0aW5nIGEgc3Vic2V0IG9mIHRoZSBkYXRhIG1v ZGVsIHRoYXQgY2FuIGJlDQo+IHJlcHJlc2VudGVkLiAgTW9yZSBpbnRlcmVzdGluZ2x5LCBhIG51 bWJlciBvZiBwcm9jZXNzZXMgY2FuIGJlIGltcGxlbWVudGVkDQo+IG9uIEpTT04gdGV4dHMgdGhh dCBkbyBub3QgbmVlZCB0byBtYWtlIHVzZSBvZiB0aGUgZGF0YSBtb2RlbCAocHJldHR5LXByaW50 aW5nDQo+IGlzIHRoZSB0cml2aWFsIGV4YW1wbGUsIGFsdGhvdWdoIHRoYXQgYWxzbyBjYW4gaW52 b2x2ZSBzb21lIGNsZWFudXAgdGhhdCBkb2VzDQo+IHJlcXVpcmUgbWFpbnRhaW5pbmcgdGhlIGRh dGEgbW9kZWw7IGFuZCBzb21lIGltcGxlbWVudGF0aW9ucyBjb252ZXJ0IEpTT04NCj4gdGV4dHMg ZnJvbSBhbiBpbnRlcm5hbCBVVEYtMTYgcmVwcmVzZW50YXRpb24gdG8gVVRGLTggYmVmb3JlIGlu dGVyY2hhbmdlKSBvcg0KPiB0aGF0IGFkYXB0IHRoZSBkYXRhIG1vZGVsIGluIHNvbWUgd2F5IChz dHJlYW1pbmcgcHJvY2Vzc29ycyBkbyBub3QgcmVpZnkNCj4gZXZlbiBhbiBhcHByb3hpbWF0aW9u IG9mIHRoZSBkYXRhIG1vZGVsKS4NCj4gDQo+IEFuZCBzbyBvbiwgYW5kIHNvIG9uLiAgVGhlIGRh dGEgbW9kZWwgaXNuJ3QgZXZlcnl0aGluZy4gIEJ1dCBpZiBJIHVuZGVyc3RhbmQNCj4gTGFycnkg Y29ycmVjdGx5LCBJIGFncmVlIHdpdGggaGltIHRoYXQgaXQgaXMgd29ydGh3aGlsZSB0byBpZGVu dGlmeSBpdCBhbmQgdG8gZGVmaW5lDQo+IHRoaW5ncyBpbiByZWxhdGlvbiB0byBpdC4NCj4gDQo+ IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGpzb24gbWFpbGluZyBsaXN0DQo+IGpzb25AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qc29uDQo= From cowan@ccil.org Sat Aug 24 19:17:27 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2631D11E81D5 for ; Sat, 24 Aug 2013 19:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+VLo+gMElYx for ; Sat, 24 Aug 2013 19:17:22 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CD2A611E818A for ; Sat, 24 Aug 2013 19:17:22 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VDPtG-0006Qg-7W; Sat, 24 Aug 2013 22:17:18 -0400 Date: Sat, 24 Aug 2013 22:17:18 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130825021718.GF23853@mercury.ccil.org> References: <86497454-2B9E-48A7-B546-547C42AAD9CA@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86497454-2B9E-48A7-B546-547C42AAD9CA@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" , "Matt Miller \(mamille2\)" Subject: Re: [Json] The General Way Forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 02:17:27 -0000 Carsten Bormann scripsit: > I didn't quite get the conclusion of what seemed to be a brief > discussion of this at the virtual interim, but any use of the Unicode > encodings other than UTF-8 would be a real-world interop problem, too. >From what I gather, we are forbidden to say anything about the encoding. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. cowan@ccil.org --Susan McCarthy (adapted) From johnl@iecc.com Sat Aug 24 19:32:25 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CF611E81D7 for ; Sat, 24 Aug 2013 19:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es46ZQlaadSp for ; Sat, 24 Aug 2013 19:32:20 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 644F911E81D0 for ; Sat, 24 Aug 2013 19:32:20 -0700 (PDT) Received: (qmail 67289 invoked from network); 25 Aug 2013 02:32:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 02:32:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52196cb2.xn--hew.k1308; i=johnl@user.iecc.com; bh=chJyoUWmQrh11M4hkXWZTJPdDTj9Jax4IqEcIZQsemE=; b=JoVcHriZ2lIuFouj+JbYIhg8q7nxc4ITbI7hgwXcunUBShuCOmgp4saO1t9dFR3lZ4zvBnmcNLJFKec2QY/8YwBkge8hrrxiAHVwkgECerth2vu62BNJU9TgdQIUGavngvRiEIVx5T51ijx+1ZGW+344M4YDR0U0872ahwqYrHSbN0UixVlihjI/PFSaHT5WKv5bFPiZBkIJwR0cEc1a51oVvOwyy/KgeMkBtdDS0hTrge68TYCQJiSOAbrQj5yu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52196cb2.xn--hew.k1308; olt=johnl@user.iecc.com; bh=chJyoUWmQrh11M4hkXWZTJPdDTj9Jax4IqEcIZQsemE=; b=gBVB+0+1AxZxnUxleegJ0GQKQnndmJQZTnsT7ChdWvAgzVTuE4mWXsa/UR8/c6p2VozXLBlEXsD4rKWkD4CMSI67kJNm/9uaYzHLXLM+UEnKBGcpySqVJm243RZ7kryEkKDtjVcPLS+rds6W0kEGtwZpABtx1VYJ0YGUpXPsulobhXjRejpkzVL4mBghM+IeeVzy4tgx64hzRg/Rfcz+ebLQ9Xbzpj+xuFK436MzoaBR3Iyy26md8cwoDNvgsY42 Date: 25 Aug 2013 02:31:56 -0000 Message-ID: <20130825023156.62316.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <20130825021718.GF23853@mercury.ccil.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: cowan@mercury.ccil.org Subject: Re: [Json] The General Way Forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 02:32:25 -0000 >> encodings other than UTF-8 would be a real-world interop problem, too. > >From what I gather, we are forbidden to say anything about the encoding. RFC 4627 says: 3. Encoding JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 It seems to me that it would not be a big leap to say that the encoding SHOULD be UTF-8 and note that in practice many implementations don't recognise other flavors of UTF. R's, John From paul.hoffman@vpnc.org Sun Aug 25 08:06:40 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD121F9D2A for ; Sun, 25 Aug 2013 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHA5k3YSHmcl for ; Sun, 25 Aug 2013 08:06:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2D21F9D11 for ; Sun, 25 Aug 2013 08:06:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7PF6Wel026449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Aug 2013 08:06:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130825023156.62316.qmail@joyce.lan> Date: Sun, 25 Aug 2013 08:06:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6281C6A5-827D-4AE3-A156-1804599A0520@vpnc.org> References: <20130825023156.62316.qmail@joyce.lan> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] The General Way Forward X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 15:06:40 -0000 On Aug 24, 2013, at 7:31 PM, John Levine wrote: >>> encodings other than UTF-8 would be a real-world interop problem, = too. >>=20 >> =46rom what I gather, we are forbidden to say anything about the = encoding. >=20 > RFC 4627 says: >=20 > 3. Encoding >=20 > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. >=20 > Since the first two characters of a JSON text will always be ASCII > characters [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. >=20 > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx xx xx xx UTF-8 >=20 > It seems to me that it would not be a big leap to say that the > encoding SHOULD be UTF-8 and note that in practice many > implementations don't recognise other flavors of UTF. "The default encoding" in the current text sounds like a type of "SHOULD = use this encoding". --Paul Hoffman= From mamille2@cisco.com Mon Aug 26 14:03:18 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824D411E8239 for ; Mon, 26 Aug 2013 14:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.524 X-Spam-Level: X-Spam-Status: No, score=-11.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iteND8cLAMfz for ; Mon, 26 Aug 2013 14:03:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D900511E823A for ; Mon, 26 Aug 2013 14:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30722; q=dns/txt; s=iport; t=1377550993; x=1378760593; h=from:to:subject:date:message-id:reply-to:mime-version; bh=V2YA8Xn0THhhJpcKJe2GPt9axvfDvvx85KrmcmgQZlE=; b=hgfP0U7IjAurHbuGrxUJPDlIqk5EGUJ1YmpxwkjrhiwMqTHhW34NTKYQ gQ6zptb2J57ScNhAP4910/yRS6UK1O1A4H/c7cqX9o/zC3e+Puw5WOiJC dMRjr1GJHcA10VfJMz6UjwaLwkb60WS6pW/UpPu7yB09LqT/lhZ5fd8DP A=; X-Files: json-20130821-minutes.txt, smime.p7s : 22492, 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAOjBG1KtJV2b/2dsb2JhbABagwc1UcAkgSIWdIImAQQaVAQZASomMA4ZBBsBBYdzDJZGhnyaPY86BYEIFoM+fQOQHYEuh1CQNIMegWkIFyI X-IronPort-AV: E=Sophos;i="4.89,962,1367971200"; d="txt'?p7s'?scan'208";a="251837102" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2013 21:03:12 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7QL3CTT007176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Aug 2013 21:03:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.124]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 16:03:11 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: Minutes for JSON WG Virtual Interim (2013-08-21T15:00:00Z) Thread-Index: AQHOop+rtAC1WTxvwUW8mjf5h0a5xQ== Date: Mon, 26 Aug 2013 21:03:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_71749484-2250-4A65-8403-BF1845B0772C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Minutes for JSON WG Virtual Interim (2013-08-21T15:00:00Z) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "json-chairs@tools.ietf.org" 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 Aug 2013 21:03:18 -0000 --Apple-Mail=_71749484-2250-4A65-8403-BF1845B0772C Content-Type: multipart/mixed; boundary="Apple-Mail=_4A7B09A3-B7AF-4001-9DE2-5E1FDDC98002" --Apple-Mail=_4A7B09A3-B7AF-4001-9DE2-5E1FDDC98002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Attached are the minutes from the virtual interim last week. The = minutes have also been posted to the interim proceedings < = http://www.ietf.org/proceedings/interim/2013/08/21/json/proceedings.html = >. Please send any corrections to the chairs, and we'll update accordingly. Thank you, - Paul Hoffman and Matt Miller --Apple-Mail=_4A7B09A3-B7AF-4001-9DE2-5E1FDDC98002 Content-Disposition: attachment; filename=json-20130821-minutes.txt Content-Type: text/plain; x-mac-type=54455854; x-mac-creator=21526368; x-unix-mode=0644; name="json-20130821-minutes.txt" Content-Transfer-Encoding: quoted-printable JSON VIRITUAL INTERIM - 2013-08-21 @ 15:00-18:00 UTC via Webex NOTE: Meeting adjourned at approximately 17:00 UTC SUMMARY =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GENERAL APPROACH -------------------------------------------------------------- There was much discussion about whether to explicitly document the = individual layers -- including an abstract data model; or to document = the known likely interoperability issues, leaving the existing document = mostly intact. While some participants see merit in the layers = approach, the rough consensus appears to be that the effort is not = worthwhile. Instead, there appears to be rough consensus to document = the known likely interoperability issues. For each issue, the document = will note the most interoperable behavior, and describe a couple of = behaviors that can lead to interoperability problems. The normative = language will remain unchanged. JSON TEXT -------------------------------------------------------------- The rough consensus appears to be to start with Tim Bray's proposal, as = documented at < = http://www.ietf.org/mail-archive/web/json/current/msg01383.html >. DUPLICATE NAMES -------------------------------------------------------------- The rough consensus appears to be to start with the duplicate names = summary , as documented at < = http://www.ietf.org/mail-archive/web/json/current/msg01345.html >. For determining the equality of names, there appears to be rough = consensus to compare values as if the values are unescaped, so that "a" = and "\u0061" are equal for purposes of name comparison. John Cowan to = propose some text to the list. ECMA TC39 / IETF JSON WG -------------------------------------------------------------- The Area Directors and Chairs were made aware that Ecma TC39 is working = on a JSON specification. However, the Area Directors and Chairs still = believe the efforts of the JSON Working Group are still worthwhile. = TC39 members were invited to join the Working Group, but very few have = participated. NUMERICAL PRECISION -------------------------------------------------------------- There appears to be rough consensus to start with what is representable = using a 64-bit IEEE-754 double precision value. Joe Hildebrand, Tim = Bray, and John Cowan volunteered to draft proposed text. PROFILES -------------------------------------------------------------- John Cowan asked about including a profile of JSON, similar to Tim = Bray's I-JSON < http://tools.ietf.org/html/draft-bray-i-json-00 >. The = rough consensus appears to be to leave that as a separate draft that the = Working Group can consider once the chartered work is complete and it = re-charters. BEST PRACTICES AND OTHER DOCUMENTS -------------------------------------------------------------- It was suggested that participants start work on a best practices for = JSON, similar to BCP 70. However, that work is not currently in = charter. RAW NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ACTIVE PARTICIPANTS -------------------------------------------------------------- Barry Leiba (BL) Eliot Lear (EL) Jim Schaad (JS) Joe Hildebrand (JH) John Cowan (JC) Larry Massinter (LM) Paul Hoffman (PH) Pete Resnick (PR) Tim Bray (TB) Tony Hansen (TH) DISCUSSION -------------------------------------------------------------- JH -- I think the approach we can do is to call out why something can = challenge interop, and strengthen the SHOULD (NOT) by explaining why = it's a SHOULD (NOT). I agree it would make it clearer to have a better = mental model, but I don't think it's as important as making sure we = explain how to not screw up. JS - Do you mean we say SHOULD, but list why it might be ok? JH - No, I mean SHOULD as in REALLY SHOULD, and explain how not = following the SHOULD can break things. PH - I mostly agree with Joe, but think we shouldn't say SHOULD unless = ... I think it is critical to say where interoperability issues might = be, and not following it might cause these interop issues. But I don't = think we should try to categorize all of the vendors that operate = certain ways. JH - Right, I didn't mean specific vendors, but that we say "here are = the things can we've seen, and here's what you need to do to = interoperate". PH - Any other comments? JS - I think that's a totally reasonable approach, and how I've been = trying to push for this in the JOSE documents. TB - I'm mostly with Joe here. I think we have a lot of shared = concensus on what the interop problems are. If the result of our work = is merely a document that talks about what the problems can be, and call = it done. I don't think we can strengthen the language any further. JH - If we were to create a document that said "You SHOULD do this. But = if you don't do it, here are the interop problems." Will the IESG have = a problem with that? PR - I don't think there will be any issues, and I'm the one that whines = about 2119 language. SHOULD means you need to do this, and you accept = all the things that can go wrong if you don't. BL - Are you not planning to talk about the interop issues? JH - No, we're planning to talk about the issues. PR - The fact is that you SHOULD NOT do duplicate names, and you can = have problems if you do. PH - I'm not sure we can do a document that says do this and it won't = interop. JH - No, I mean that we say, if you don't do this, here are the ways it = might not work. TH - We might want to talk about walled gardens. In the walled garden, = you'd be fine, but outside you'd have problems. PH - Are you suggesting we put that into the document? TH - I think the document should talk about where=20 JC - I want to qualify some more. I think it's right to talk about = things in terms of might break, and not will break. That while there = might not be problems now, but there can be in the future. JH - Taking the duplicate names as an example. JC- It's possible to map them. JH - What I'm saying is there are parsers that generate different = results JC - I'm pointing to surrogates in particular, since the problem is more = severe. TB - We're trying to fix that. JC - I'm just trying to say that there might be systems that can't fix = the issues. PH - Where John's desire might be getting more interesting is the newest = issues. We're trying to solve the problems we know about, but there can = be problems in the future. We're not going to try to solve the problem = for all of the future. JC - I have a problem with just "known", not "known possible". PH,JH - Fine TB - I don't see anyone have a problem with a document that is only = listing the interop problems, and that's great progress. JH - I think one more thing we do need to talk about in the document is = how strings are compared, like what a human would think are equal but = the=20 LM - Like saying this pertains to the abstract model and not the = serialization layer. JH - I agree it would be cleaner to explain it that way, but I think = that is a much bigger edit than we have energy for. I think it can be = good enough to say=20 JC - Well, that you should compare them unescaped, but if you don't you = will have interop problems. JH - Right. LM - In IRI, we have Abstract layer, serialization, normalization, etc. = I think that will help explain things better. PH - So we have Joe's proposal to talk about ad-hoc explications versus = Larry's layer system. JC - I would prefer the layer system in principal, but evading it = [missed] JS - I think we also need to talk about what you need to do to the value = half in addition to the name half in comparisons. PH - Why is it important in JOSE? JS - We have cases where we are caring about what the value of an = attribute is, and comparing it to other data I have. PH - Is the JOSE WG finding that is something generally needed, or just = for JOSE. JS - Right now, I'm the one with the issue and have raised it in the WG. = But I see it as the exact same issue JH - It may some combination of language for object name comparison plus = PRECIS rules for comparison. But I'm not convinced we have a general = requirement here. JC - I think we move past values and onto significance of the meaning of = values. We have whitespace, unless it's inside the string. You can = have as much spaces and it doesn't impact the meaning. So that also = applies to escaping; that the meaning of the escaping is what you are = comparing and not the literal string. PH - These comparisons are being done for some type of hashing, and for = cryptographic comparisons? My personal preference is that we don't talk = about removing escaping in value parts, and have the groups talk about = it in the terms that make sense for them. JS - I don't care about the hashing. I care about say checking that the = algorithm value is the value I'm looking for. JH - That's an application-level thing. JC - So why are we not defining the algorithm? JH - I'm trying to be clever because I might have a special way to = handle it for my platform. JC - An analogy would be LATIN SMALL LETTER A WITH ACUTE versus LATIN = SMALL LETTER A combined with ACCUTE ACCENT. JH - That brings up the specter of normailzation JC - It's only an analogy. If I send you something that would be a = capital A for me, but I can't assume you will see it the same. PH - I think there will be implementations that do weird things, and we = should document what can cause interop problems. JC - My point might be too subtle PH - This topic might be for the best practices, which there is desire = for but yet in charter. JC - If I send you a "\u0061", it means the same as "a" PH - In a key, or any string. JC - Any string. PH - I believe that is true. JH - I believe that is true, but I'm not convinced about the usefulness. = If we were to have that discussion earlier in the document, then we can = point to it in the [missed] JC - I note that it says "any character may be escaped", but it is a = lower-case may. JH - What if we put something right after that they are compared to be = the same. JC - I think we need to be careful about equivalency and equality. JH - I think that needs wordsmithing. PH - So John is going to propose text about string comparison. PH - To summarize -- we have some consensus that we document where there = are interop problems, how you can avoid them, and here are some of the = ways that they can break. TB - I would fine-tune that some to be here are a non-exhaustive list of = ways you can break. PH - That sounds good. LM - I was hoping that someone from TC39 to talk about their JSON = effort. PH - You have asked, and we have invited them (including phone calls), = but they're not here. TB - Are they working on a JSON standard? PR - We have had conversations with TC39 in the last several days. = There is a ECMA document on JSON floating around. When I spoke to the = Chairs (JSON and TC39), and the basic idea is we continue doing the work = that we think needs to get done anyway, and we will deal with the Ecma = output when/if it comes. TC39 has not come out and said we should stop = work, so we're not going to stop. PH - Also, this work is not public. LM - I am aware of that, and I don't think I'm revealing anything = confidential. PH - TC39 has known about this meeting, and they've chosen not to join = us today. The Chairs have done the best that they can do, and the ADs = plus Eliot have done the best they can do. The WG Chairs are not part = of those AD + Eliot discussions. Coming back to this group: there have been proposals on the mailing list = that mostly match what we've talked about in this call. Do people think = we're ready to move forward? 1) What is a JSON text 2) What does one do with dupicate names There is no proposed text on number precision, but it is one area where = interop problems can come up. JH - Do you mean floating point specific, or numbers in general? PH - In general. Tim had some proposals about the JSON text idea, and = Matt posted JC - I think this is superseded by the "you might have interoperability = problems if...". PH - Tim's proposal is talking about it in those terms. My question is = are we moving too quickly? JH - I think we should try and get a draft together. JC - I agree TB - I have seem a number of concrete proposals into the draft and see = where it goes JH - I have one question about the text: I expect that all surrogates to = be paired, and all are encoded, etc... JC - What do you mean by that? Unmatched unencoded surrogate pairs = don't exist (-: JH - My actual question: should we change the ABNF that you're not = allowed to do unpaired escaped. JC - No, we cannot. We must not. PH - Why can't we. TB - Because that would cause things that are JSON now to not be JSON = anymore JH - I was suggesting it go into the actual ABNF. It was awful, but it = was legal. I understand what you're saying about invalidating existing = stuff. But I think we're invalidating it anyway when we change the = text. TB - No, we're going to say that "if you do these things, then you might = have interop problems". LM - The abstract model allows for numbers that are valid numbers, but = are not valid Unicode. There are interop because of bad = implementations, and interop problems because strings are used that = don't map into the prescribed model. JC - I know people use JSON to interchange JavaScript or Java strings, = and saying they can't exchange unpaired surrogates now means they don't = comply. JH - I'm willing to back off on that. You're selling past the close. PH - So take this to the list, and give it a week, then add the text to = the draft in a week? JC - I don't object in principle, but I'm concerned in practice. I = don't think we've talked enough about number precision. PH - We understand, and it can still be hashed out. NUMBERS -------------------------------------------------------------- TB - If you do these things, then you can interoperate; if you don't = then you might have problems. So for numbers, that I think that means = you need to only use numbers that represented in 64-bit IEEE 754. PH - So what you're suggesting is we do numbers as a third point of = interop, and you SHOULD do it this way, and if you don't do it that way = you can have interop problems. JC - Just make sure we're talking about the right format. JC - I think there will be people that find this too broad, not too = narrow. JH - You think there are people that accept 32-bit floating point? JC - I think so. I think there are people that only accept integers. JH - I think we can say it needs to be=20 TB - I work on a number of platforms, and 64-bit float isn't much of a = problem. JC - I think it needs to be at least discussed on list PR - I'm a little concerned about paralleling the interop text here as = in other places. It is about if you do this, then you have a good shot = of interop; but if you do this, then you can go wrong. JC - For instance, I think one person said they can only handle = fixed-point numbers. PR - It seems like it's different. While it's a problem, it's not one = the IEEE format will completely fix. I'm not sure this is the kind of = text we should put in. PH - Two things: 1) precisions beyond 32-bit (or 64-bit) float, and 2) = integers only. If someone only has a 32-bit float, and some of the = things that can be described in a JSON number and what will happen when = the receivers gets those, which is different from only handling = integers. If we hear that there are implementations that only handle = integers, then we need to discuss it in the document. If there aren't, = but can only handle 32-bit float, then I don't think we need to discuss = it. What we are talking about if we stop or not. TB - The thing with surrogates is that the current spec implies you have = to deal with it, but it doesn't say you only deal with integers. JC - It does allow for 0 digits after it. TB - I think it's an agregious violation, but you might be right. Caller-9 -???? JH - And once you move it to base-10, then it gets worse JC - 6427 =C2=A7 4 says that an implementation on the range of numbers, = but does not say anything about the precision of numbers. PH - So we can take this to the list. JC - Omitting one and not the other implies a certain interpretation. LM - Are you saying that having more 0's at the end is different than = limiting them? EL - There is a law of physics in play here. We haven't specified a = limit, but there will be. JH - We can say that applications MAY put a limit of range and = precision, and most use IEEE 754 64-bit. PR - That sounds like the right approach. PH - (throwing in a wrench) As soon as we mention IEEE format, we are = going to have to say, BUT you can't do +/-Infinity and NaN. JC - I'm fine with that. We're saying that a number needs to be = represented in this format, but not that every IEEE is represented. PH - OK, making sure we understand that. PH - I hear a couple of volunteers for numbers. JC - I think the three of us can come to consensus. PH - I don't want the list to think we have a lot of contention, when we = don't really have any. Can Joe/Tim/John come to internal consensus = before going to the list. JC/JH - Yes. OPEN MIC - ECMA RELATIONSHIP -------------------------------------------------------------- PH - You've brought up the Ecma thing ... is there any specific concerns = you want to bring up now? LM - I have heard that some at TC39 are not happy about no formal = liaison. EL - I sit on the IAB, and I have been talking to the TC39 people about = this. There is an impedence mismatch between the IETF and ECMA. The = IAB doesn't see the need for a long-term relationship so we don't want = to formalize it. The IETF is open to everyone, and we think the best = way to get people to talk is to just have people talk. LM - The mailing list is full about things that are foreign. It's very = difficult to just come into the meeting room and start participate at = any point. I think we should call them, and tell them we're having a = meeting and you should come here. JC - We've done that, but they can't because they're under = non-disclosure. EL - I haven't heard that here. We received a document, and we're = reviewing it. There is a point on the charter about participation from = Ecma, but they haven't. OPEN MIC - APPLICATION/FORM-DATA -------------------------------------------------------------- LM - I've been working on application/form-data, and it has a lot of = the same problems with non-ASCII values. And separating things into = layers helps better define what needs to happen where. We could say = that the Abstract model only contains integer values that can be = interpreted as more; application models might have IEEE and so on. If = you want to understand why the design choices are what they are, then I = think the layering helps do that. JC - It would if it was in the data model. I think that if we had the = luxury to start from scratch, it would be useable. But we can't, so I = don't think it's useful now. LM - I don't understand that, since the abstract model is already in the = applications today. JC - I'm not understanding. LM - The spec today says there are string and numbers, and there are = problems with precision and encoding, but it's not a problem in the = abstract model. JC - We went down this road in XML. We couldn't agree on what is in or = out of the data model. LM - Does JSON have the same problems as XML? JC - No, because no one as attempted to write a JSON data model. PH - For the WG, does a data model document go into 4627, or in = something else? LM - I'm not proposing the data model as anything more than a way to = describe why certain choices were made. PH - I suggest that we hold that discussion for the mailing list. There = are a variety of understanding of implementers, and not identical. = Having a data model would be valuable in an implementer's guide, but not = in 4627bis. JC - Or a user's guide PH - When it's about what's next. Do we need an implementer's guide, or = a combination implementer's/user's guide. We propose that you write up = the data model, but not for inclusion in 4627bis. OPEN MIC - PROFILE -------------------------------------------------------------- JC - The idea of a Tim Bray profile of JSON, in the 4627bis. If you = want to maximize interop, obey all of these rules...rather than = scattering them throughout the document. PH - Do they belong in the document at all, and then do they belong in a = single section? TB - No, that would read weird. Put things where you talk about it. PH - So you want scattered? TB - I want do judiciously sprinkle the interop guidance and challenges. PR - There are instances where there are clear interop problems, and = that's different than maximizing interop. I think we have consensus on = the specific problems, and it sounds like you want a more general = guidance. JC - I bring it up because =C2=A74 talks about parsers dropping data. TB - I think what John is trying to assemble is my I-JSON draft into = 4627bis? JC - I'm not necessarily saying we have it in multiple places, but that = we should have all of these points gathered into one place, so we can = reference it as a profile. TB - I think we know what the biggest problems, and we can do localized = surgery. This is also about having an interoperable profile in this = document, but it requires a lot more. JC - I agree at that level it's not in our scope. But now I wonder if = there are interop problems if using something other than UTF-8? PH - 4627 does have an IANA consideration, which is a MIME registration = that is inviolate. It only talks about UTF-8 ,-16, and -32. JH - I agree with what Paul and Tim said, and we can't change what = people are using today, but that we should have another document that=20 JC - I'm asking if we say that if we don't limit to UTF-8, that anyone = that does limit is not interopable. JH - I'm aware of one that only understand UTF-16 ... like ECMA-262. I = don't think this is a good path to go down. OPEN MIC - BCP 70 -------------------------------------------------------------- LM - I did ask about BCP 70. It seems like we should have something = like BCP 70 for JSON. PH - There is interest, but we're not ready for that yet. LM - I'd like to solicit volunteers on that, and other parking lot = things. PH - I think you should keep that list, but I don't want to interrupt = the WG process. It's not on the charter now. OPEN MIC - NEXT STEPS -------------------------------------------------------------- JH - I've sent along small edits to Tim and John, so we should have = something out soon. =20 --Apple-Mail=_4A7B09A3-B7AF-4001-9DE2-5E1FDDC98002-- --Apple-Mail=_71749484-2250-4A65-8403-BF1845B0772C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MjYyMTAz MTBaMCMGCSqGSIb3DQEJBDEWBBS3PJ0hBgH7YFq2sDcrlo3jw1m/JDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBACqr R75Syjt+mJtWuX/Y2kucekTI7CzfwnZMFkKbdAE89F3RykVURzmQ+uqpW/AB9qDPdOIz6E74PDZ/ FMeThUbrRm3FHS/5H1PdqtVGycW9rTZ6x2B3Wp80euDsOuLGnfeJJtMoxrktsXVwatxH9FdRT6Up 5DyQTfURFUfXBquaImjil+oz6aBc9hdFcowAkkxPXCP5/Q9GIC7kE2JepNx5n7hQhFJyldGpeEuD n3LWCLO+178D5697PjwCSpFQDrWngwcOd6FAkpJygAAon3Oph6TrxGQTrB94DhCqQ/v84RPV748n 4pa6I1nGo7uS5ua+eDhorNozZpNP46VpbmUAAAAAAAA= --Apple-Mail=_71749484-2250-4A65-8403-BF1845B0772C-- From tony@att.com Mon Aug 26 14:46:07 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB121F9FE3 for ; Mon, 26 Aug 2013 14:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.129 X-Spam-Level: X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4S+D7tg1j4n for ; Mon, 26 Aug 2013 14:46:01 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id F283221F9F2B for ; Mon, 26 Aug 2013 14:45:57 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 29ccb125.0.3028795.00-391.8349912.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 26 Aug 2013 21:45:58 +0000 (UTC) X-MXL-Hash: 521bcc9619146e49-3504439bfc56510167919e01e9bce1ce15b15b4c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QLjrpw032236 for ; Mon, 26 Aug 2013 17:45:53 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QLjgxE032108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Aug 2013 17:45:50 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Mon, 26 Aug 2013 21:45:29 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QLjTLn001550 for ; Mon, 26 Aug 2013 17:45:29 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7QLjNaN001306 for ; Mon, 26 Aug 2013 17:45:24 -0400 Received: from [135.91.110.247] (ds135-91-110-247.dhcps.ugn.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20130826214523gw1004nh8be> (Authid: tony); Mon, 26 Aug 2013 21:45:23 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <521BCC6F.4040503@att.com> Date: Mon, 26 Aug 2013 17:45:19 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "json-chairs@tools.ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=Ru1y2laK c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VAG9_9YYm2gA:10 a=sCfsyOEanakA:10 a=yG_zLKZV9VEA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=bR7FrT0J-vwA:10 a=48vgC7mUAAAA:8 a=DGnRL_wVsoWgQ] X-AnalysisOut: [Im_y3MA:9 a=wPNLvfGTeEIA:10 a=i_XiL1ZfUIAA:10] Cc: "json@ietf.org WG" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Minutes for JSON WG Virtual Interim (2013-08-21T15:00:00Z) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Aug 2013 21:46:07 -0000 On 8/26/2013 5:03 PM, Matt Miller (mamille2) wrote: > Attached are the minutes from the virtual interim last week. The minutes have also been posted to the interim proceedings < http://www.ietf.org/proceedings/interim/2013/08/21/json/proceedings.html >. > > Please send any corrections to the chairs, and we'll update accordingly. > > > Thank you, > > - Paul Hoffman and Matt Miller Under DISCUSSION, you have TH - I think the document should talk about where that should be TH - I think the document should talk about where you can expect interoperability and where things become less interoperable. Down in Numbers, you have a place holder for Caller-9. I think that was me, as right about there I brought up something along the lines of: TH - Floating point is by its very nature non-interoperable when you go between machines or into an on-the-wire representation that doesn't hold the exact bit patterns. The best you can say is that sticking to a format compatible with the IEEE standard would provide for the "best chance of interoperability". The comment about "once you move it to base-10" by JH was adding to my statements. Tony From mamille2@cisco.com Wed Aug 28 10:54:43 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7186811E819D for ; Wed, 28 Aug 2013 10:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.739 X-Spam-Level: X-Spam-Status: No, score=-10.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEBKonY5afko for ; Wed, 28 Aug 2013 10:54:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 372AC11E8196 for ; Wed, 28 Aug 2013 10:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6286; q=dns/txt; s=iport; t=1377712478; x=1378922078; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lp4oOaZDVmwe8u4KhyP4fAR18b5tvBznY3i06UOqW5s=; b=VotSNAwi2/hZ4iNp7czF3LSF5TfRbKC5lwIre7WgvIx69asonC58Yc3G lSgnwwbUr3lCr4+HLdSU6MayXA9LKZnKfSS+h23D4yZi9w39N4x1uVgSf ik6XmZgbhFhw3ODjc67v4AABFfUgxUcjvZUomQEvvPwUm043FNIX3OdRw k=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAJ84HlKtJV2b/2dsb2JhbABbgwc1UYJgvU6BIBZ0giUBAQSBCQIBCCIkAjAlAgQbAQWHcwy5Uo8zOIMcfQOQIIEumASDIIIq X-IronPort-AV: E=Sophos;i="4.89,977,1367971200"; d="p7s'?scan'208";a="252860008" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2013 17:54:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7SHsXxk013135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Aug 2013 17:54:33 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.124]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 12:54:33 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: [Json] Minutes for JSON WG Virtual Interim (2013-08-21T15:00:00Z) Thread-Index: AQHOop+rtAC1WTxvwUW8mjf5h0a5xZmoWbCAgALkLgA= Date: Wed, 28 Aug 2013 17:54:32 +0000 Message-ID: References: <521BCC6F.4040503@att.com> In-Reply-To: <521BCC6F.4040503@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.48] Content-Type: multipart/signed; boundary="Apple-Mail=_5698F246-EA37-4EC2-9737-F811560D88C5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [Json] Minutes for JSON WG Virtual Interim (2013-08-21T15:00:00Z) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:54:43 -0000 --Apple-Mail=_5698F246-EA37-4EC2-9737-F811560D88C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Updated minutes with Tony's corrections have been posted to < = http://www.ietf.org/proceedings/interim/2013/08/21/json/minutes/minutes-in= terim-2013-json-1 >. Thanks! - Paul Hoffman and Matt Miller --Apple-Mail=_5698F246-EA37-4EC2-9737-F811560D88C5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MjgxNzU0 MzNaMCMGCSqGSIb3DQEJBDEWBBTseaI7Be5hcCbT5RP1X9nRgLGASjCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAEXx avv1riKYz6329UN6j+VHkt39CJ4WAHeASu2oOLDB/L11MZW7BOkC9stvHgMDQ7bnkOM/rfIeJ0Uw +nl0Go4iFfQuhR5sGTjfgqb156IuBUzaNY19BJ2UUEkaukMe9VtfCLV5oJUlNsmxYrSHaoLHNeNF w/vaK/7lEwwfx8L2BTmcPjcPUj5UYeqw8x69IXA2e9HRlX1CTmxwss8h4GvITvajN+7q1bt3BZ9E M0VCFcWH03olj7gHO2Ag1DpsSLropafc5aAkS8ukG6EcgGe9A/+bIpOnUyH+CjQlwnJnKJF2U3SK uiq/x+yeZKEgCelJwmJ/SoSC21YiRGjWYQIAAAAAAAA= --Apple-Mail=_5698F246-EA37-4EC2-9737-F811560D88C5-- From cowan@ccil.org Wed Aug 28 12:07:20 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABA21F8BE6 for ; Wed, 28 Aug 2013 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeU4TpjbH0nV for ; Wed, 28 Aug 2013 12:07:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 154F221F91AB for ; Wed, 28 Aug 2013 12:07:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VEl58-0007fi-RU for json@ietf.org; Wed, 28 Aug 2013 15:07:06 -0400 Date: Wed, 28 Aug 2013 15:07:06 -0400 From: John Cowan To: JSON WG Message-ID: <20130828190706.GB8176@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 19:07:20 -0000 Tim Bray, Joe Hildebrand, and I have consenus on the following language to be added to 4627bis about numeric precision, and are presenting it to the WG: 1) Replace the last paragraph of 2.4 with the following: The intended range and precision of a JSON number matches that of an IEEE 754:2008 binary64 (double precision) number, to the limit of what can be represented in the JSON syntax. Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted. Attempting to represent numbers that cannot be exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400 or 3.141592653589793238462643383279, may cause interoperability problems. 2) In section 4, change the sentence "An implementation may set limits on the range of numbers" to "An implementation may set limits on the range and precision of numbers". This assumes that "may cause interoperability problems" is the language that the WG will adopt for the other issues. Another possibility is "will potentially cause interoperability problems". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org The native charset of SMS messages supports English, French, mainland Scandinavian languages, German, Italian, Spanish with no accents, and GREEK SHOUTING. Everything else has to be Unicode, which means you get only 70 16-bit characters in a text instead of 160 7-bit characters. From cabo@tzi.org Wed Aug 28 12:25:10 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D47E21E808D for ; Wed, 28 Aug 2013 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrLiwxJ2FSyb for ; Wed, 28 Aug 2013 12:25:04 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5F421F8BFD for ; Wed, 28 Aug 2013 12:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7SJOhiw000256; Wed, 28 Aug 2013 21:24:43 +0200 (CEST) Received: from [192.168.217.105] (p5489329B.dip0.t-ipconnect.de [84.137.50.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 75B7C3D7; Wed, 28 Aug 2013 21:24:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130828190706.GB8176@mercury.ccil.org> Date: Wed, 28 Aug 2013 21:24:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130828190706.GB8176@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 19:25:10 -0000 On Aug 28, 2013, at 21:07, John Cowan wrote: > The intended range and precision of a JSON number matches that of an > IEEE 754:2008 binary64 (double precision) number,=20 Intended by whom? The technical content of that half-sentence precisely describes one = specific community of JSON users and ignores all others. Since that community is large, sticking to the range and precision of = IEEE 754 doubles does maximize interoperability, and that would be = indeed my recommendation for applications that need to work in the = widest possible space. The number system of JavaScript is, however, completely irrelevant to = other legitimate uses of JSON as a data interchange format. If fixating = JSON on that number system was "intended", a lot of people have not been = telling the truth for a decade. I don't think you want to insult them = by implying that. Gr=FC=DFe, Carsten PS.: All finite IEEE 754 doubles can be notated in JSON syntax. PPS.: Add 1.1 as an example for what "cannot be exactly encoded as an = IEEE 754:2008 binary64 number". I don't believe that interchanging this = number causes great interoperability problems in practice, however. From pfpschneider@gmail.com Wed Aug 28 12:53:57 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1705D21E8098 for ; Wed, 28 Aug 2013 12:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkm49T22EjV6 for ; Wed, 28 Aug 2013 12:53:56 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E47CE21E8090 for ; Wed, 28 Aug 2013 12:53:53 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so7175613obp.22 for ; Wed, 28 Aug 2013 12:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CnjlmgQZ619rbpp9OpiAmft+I6tPosOaclWY+brLbAI=; b=mT9Zjy98mB7K0UvWJJHunw/I8OOBFDQNYAb/8J8lKzAPcGPmbdkn6Seu1ju5S8rO8d Pa5Nch8Z1HCtrywAbZwb+JNi3bcurp5vPg8uDPb5n9XbzZHcUPfNSJrBSBTV2HEftfOC ruMUroa0MSQWg4Y7UesNCi/NT/DB1x5160ZHoJZ1dP4XrP4/Xa6lMmYAm6y1wwfjRv0N sc2OjFKDQiAXBOJ4hDn2VQ5S3tyI96mI3oPRwa7dDPoFsEWf+aZGG75rVoB36aGSc0Mp NEJyKaNHFXpgdFYvHDivZmV3o7Nh6RlD8PMESvEw9q3KgbBWVIXlsJN4trGtpsIUgszn Wu7Q== X-Received: by 10.182.242.112 with SMTP id wp16mr8013898obc.85.1377719633467; Wed, 28 Aug 2013 12:53:53 -0700 (PDT) Received: from [192.168.1.100] (out-on-163.wireless.telus.com. [207.219.69.163]) by mx.google.com with ESMTPSA id xr8sm27648084obc.12.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:53:50 -0700 (PDT) Message-ID: <521E554D.5000007@gmail.com> Date: Wed, 28 Aug 2013 12:53:49 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Carsten Bormann References: <20130828190706.GB8176@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Cowan , JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 19:53:57 -0000 On 08/28/2013 12:24 PM, Carsten Bormann wrote: [...] PPS.: Add 1.1 as an example for what "cannot be exactly encoded as an IEEE 754:2008 binary64 number". I don't believe that interchanging this number causes great interoperability problems in practice, however. I would be very cautious about making such statements. peter From cowan@ccil.org Wed Aug 28 13:20:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20EA21F9CC8 for ; Wed, 28 Aug 2013 13:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17H3FF7uYJJ6 for ; Wed, 28 Aug 2013 13:20:07 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F277A21F9C72 for ; Wed, 28 Aug 2013 13:20:06 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VEmDj-00071Q-Ps; Wed, 28 Aug 2013 16:20:03 -0400 Date: Wed, 28 Aug 2013 16:20:03 -0400 From: John Cowan To: "Peter F. Patel-Schneider" Message-ID: <20130828202003.GC8176@mercury.ccil.org> References: <20130828190706.GB8176@mercury.ccil.org> <521E554D.5000007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521E554D.5000007@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:20:11 -0000 Peter F. Patel-Schneider scripsit: > PPS.: Add 1.1 as an example for what "cannot be exactly encoded as an > IEEE 754:2008 binary64 number". I don't believe that interchanging > this number causes great interoperability problems in practice, however. There is a binary64 number which is the closest correspondent to 1.1, however, namely 0x3f8ccccd. -- John Cowan http://ccil.org/~cowan cowan@ccil.org The work of Henry James has always seemed divisible by a simple dynastic arrangement into three reigns: James I, James II, and the Old Pretender. --Philip Guedalla From tony@att.com Wed Aug 28 13:20:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39E21F9DCE for ; Wed, 28 Aug 2013 13:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.095 X-Spam-Level: X-Spam-Status: No, score=-106.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzh9jsvKB5rM for ; Wed, 28 Aug 2013 13:20:25 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA821F9DCB for ; Wed, 28 Aug 2013 13:20:25 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 88b5e125.0.2864222.00-472.7906049.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 28 Aug 2013 20:20:25 +0000 (UTC) X-MXL-Hash: 521e5b8925676afa-4ba712c85276e7c3c6532bfeae9ef4c96cfdb901 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7SKKOsa022717 for ; Wed, 28 Aug 2013 16:20:24 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7SKKHZx022613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Aug 2013 16:20:21 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Wed, 28 Aug 2013 20:20:05 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7SKK5sc020086 for ; Wed, 28 Aug 2013 16:20:05 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7SKJwJS019656 for ; Wed, 28 Aug 2013 16:20:01 -0400 Received: from [135.91.110.247] (ds135-91-110-247.dhcps.ugn.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20130828201958gw1004nh9he> (Authid: tony); Wed, 28 Aug 2013 20:19:58 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <521E5B6E.8040209@att.com> Date: Wed, 28 Aug 2013 16:19:58 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: JSON WG References: <20130828190706.GB8176@mercury.ccil.org> In-Reply-To: <20130828190706.GB8176@mercury.ccil.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=EZl/toaC c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=VAG9_9YYm2gA:10 a=sCfsyOEanakA:10 a=XMFjyUc69pwA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=gYBa_z_pxDQA:10 a=AcuEf_9kwoxnXQxJorsA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=ID0rsCBZtt4EBVAf:21 a=s1UjduOprnpoyO-o:21] Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:20:32 -0000 On 8/28/2013 3:07 PM, John Cowan wrote: > Tim Bray, Joe Hildebrand, and I have consenus on the following language > to be added to 4627bis about numeric precision, and are presenting it > to the WG: > > 1) Replace the last paragraph of 2.4 with the following: > > The intended range and precision of a JSON number matches that of an > IEEE 754:2008 binary64 (double precision) number, to the limit of what > can be represented in the JSON syntax. Numeric values that cannot > be represented as sequences of digits (such as Infinity and NaN) > are not permitted. Attempting to represent numbers that cannot be > exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400 or > 3.141592653589793238462643383279, may cause interoperability problems. Hmmm, I like the last sentence. But I'm thinking that the first sentence goes too far in changes to the original spec. An alternative phrasing could be: Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted. To maximize interoperability, numeric values should be limited to those that may be exactly encoded as an IEEE 754:2008 binary64 (double precision) binary64 number. For example, numbers such as 1E400 or 3.141592653589793238462643383279 may cause interoperability problems. > 2) In section 4, change the sentence "An implementation may set limits > on the range of numbers" to "An implementation may set limits on the > range and precision of numbers". > > This assumes that "may cause interoperability problems" is the language > that the WG will adopt for the other issues. Another possibility is > "will potentially cause interoperability problems". I consider the lack of "and precision" to be an oversight in 4627. +1 Tony Hansen From cowan@ccil.org Wed Aug 28 13:32:38 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBBF11E81B8 for ; Wed, 28 Aug 2013 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0zOFgebV6Tb for ; Wed, 28 Aug 2013 13:32:34 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 121FF11E81B2 for ; Wed, 28 Aug 2013 13:32:34 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VEmPo-0008D1-Cn; Wed, 28 Aug 2013 16:32:32 -0400 Date: Wed, 28 Aug 2013 16:32:32 -0400 From: John Cowan To: Tony Hansen Message-ID: <20130828203232.GD8176@mercury.ccil.org> References: <20130828190706.GB8176@mercury.ccil.org> <521E5B6E.8040209@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521E5B6E.8040209@att.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:32:38 -0000 Tony Hansen scripsit: > Numeric values that cannot be represented as sequences of digits (such > as Infinity and NaN) are not permitted. To maximize interoperability, > numeric values should be limited to those that may be exactly encoded as > an IEEE 754:2008 binary64 (double precision) binary64 number. For > example, numbers such as 1E400 or 3.141592653589793238462643383279 may > cause interoperability problems. I'm good with that (it's basically what I proposed in the first place to the sub-WG), except I wouldn't use "should" for fear of confusion with "SHOULD". -- Do I contradict myself? John Cowan Very well then, I contradict myself. cowan@ccil.org I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass From cabo@tzi.org Wed Aug 28 13:33:53 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3881B11E81B2 for ; Wed, 28 Aug 2013 13:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H+rGZyBmXzq for ; Wed, 28 Aug 2013 13:33:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 223D511E81B8 for ; Wed, 28 Aug 2013 13:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7SKXbil010154; Wed, 28 Aug 2013 22:33:37 +0200 (CEST) Received: from [192.168.217.105] (p5489329B.dip0.t-ipconnect.de [84.137.50.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E3D693F1; Wed, 28 Aug 2013 22:33:36 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <521E5B6E.8040209@att.com> Date: Wed, 28 Aug 2013 22:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D90BEE9-865F-4836-B255-B95E36328E83@tzi.org> References: <20130828190706.GB8176@mercury.ccil.org> <521E5B6E.8040209@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1508) Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:33:53 -0000 On Aug 28, 2013, at 22:19, Tony Hansen wrote: > Numeric values that cannot be represented as sequences of digits (such = as (I don't want to be too nitpicky today, but that was one of the things = that needed to be corrected in 4627: 1.1 cannot be represented as = sequences of digits either... So the proposal was right to say "cannot = be represented in JSON syntax" (which includes [+-e.]), this is just a = bit opaque. Maybe just say:) > Infinity and NaN) are not permitted. (I'm sure IEEE 754 has a term for the non-finites, I'm too lazy to look = it up.) > To maximize interoperability, > numeric values should be limited to those that may be exactly encoded = as > an IEEE 754:2008 binary64 (double precision) binary64 number. For > example, numbers such as 1E400 or 3.141592653589793238462643383279 may > cause interoperability problems. Yes! >> 2) In section 4, change the sentence "An implementation may set = limits >> on the range of numbers" to "An implementation may set limits on the >> range and precision of numbers". >>=20 >> This assumes that "may cause interoperability problems" is the = language >> that the WG will adopt for the other issues. Another possibility is >> "will potentially cause interoperability problems". >=20 > I consider the lack of "and precision" to be an oversight in 4627. +1 Exactly. Gr=FC=DFe, Carsten From cromis@gmail.com Wed Aug 28 13:39:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D7711E81CA for ; Wed, 28 Aug 2013 13:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2GCBBuvMrJu for ; Wed, 28 Aug 2013 13:39:01 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8687D11E81C7 for ; Wed, 28 Aug 2013 13:39:01 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so3756300qee.40 for ; Wed, 28 Aug 2013 13:39: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:from:date:message-id :subject:to:cc:content-type; bh=q70/5JJfDY4/E77BUL73ZcDRJyDvRueL9XRyffRbdfI=; b=RdQDE+ULvlYj0AyTQ7AuLAltuV7Y9AKPK0KYZwBDOQB1H0fbZzVJvWH3XrBzE84fJb 3gwnYvG7cXVrGWry8FYCFI1dNzOQfFKcUzluj8SgoA7B7SLOf86kd0cDnSbhMKVvaYP+ p4/mgJDMPte0NBq964k42adQMwA7iHVfCGp8BQX0ZJ3M8fyAzJ7mHW7PoauVuhgQEEuj oOis9lVALW3MVLL2CJA+/tM4c5UcS3CuPtsGcte/vGfDKiLDPk3E+yEcHJNhA47p11xL XipSviNqTvg85gmFp+FwBcLXkGIpndT0TMAQ92QSACmBeb2Pn86LhIykuZgQN0yC2jB+ m+kw== X-Received: by 10.224.23.73 with SMTP id q9mr602185qab.45.1377722341041; Wed, 28 Aug 2013 13:39:01 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.13.102 with HTTP; Wed, 28 Aug 2013 13:38:40 -0700 (PDT) In-Reply-To: <20130828190706.GB8176@mercury.ccil.org> References: <20130828190706.GB8176@mercury.ccil.org> From: Jacob Davies Date: Wed, 28 Aug 2013 13:38:40 -0700 X-Google-Sender-Auth: dAcGQ-uDccsuFg-0TLYFVPCziY4 Message-ID: To: John Cowan Content-Type: text/plain; charset=ISO-8859-1 Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:39:02 -0000 On Wed, Aug 28, 2013 at 12:07 PM, John Cowan wrote: > 3.141592653589793238462643383279, may cause interoperability problems. Perhaps it would be better to use a more boring number than this one, to eliminate the possibility of reading this to actually mean pi rather than just "any old number with a lot of digits after the decimal point". From sayrer@gmail.com Wed Aug 28 13:51:02 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB311E81A3 for ; Wed, 28 Aug 2013 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMT1N53Xp85D for ; Wed, 28 Aug 2013 13:51:02 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D16C411E811F for ; Wed, 28 Aug 2013 13:51:01 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id m4so3802727qcy.34 for ; Wed, 28 Aug 2013 13:51:01 -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=1+BpHVQr7H5ANGpSpIFb8cDSqkWs+iVKHC+DpkWURZg=; b=uAb1y7LQbVDjqDqg+GVH2wLmuOvF3frBWZdUehvzcM/uqtoriaU9lrB3d5tOs5qKAq x9rGJ78oYgkTqSQqWgRfMmhKJ2fRY7d0+EpoQp1R/EjJ1uXqlYxajLdfcbeX/FUXADGM 2clOizHzrgNcnBwR9jAZE18TcYmeO9oJm3CU2CALZwct/QQkk1KPesfy+WmFuV6LJgfc lIWZ9OiizGH+j16TaTdt9ljtFL7jfq/Xwwa5cuj+M7FS/wmUQsbeKBaEKlvgS/D/mR/U aXmjWn3OcBMBmswxBUN+5p8pmrzCF8jG4+dESPsQbeU6Yj+3UNN0NabqWRFwEaU83Wiu vkhQ== MIME-Version: 1.0 X-Received: by 10.224.167.198 with SMTP id r6mr757076qay.16.1377723061306; Wed, 28 Aug 2013 13:51:01 -0700 (PDT) Received: by 10.224.60.17 with HTTP; Wed, 28 Aug 2013 13:51:01 -0700 (PDT) In-Reply-To: <20130828190706.GB8176@mercury.ccil.org> References: <20130828190706.GB8176@mercury.ccil.org> Date: Wed, 28 Aug 2013 13:51:01 -0700 Message-ID: From: R S To: John Cowan Content-Type: multipart/alternative; boundary=089e014953f2ab09b104e508259d Cc: JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:51:02 -0000 --089e014953f2ab09b104e508259d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 28, 2013 at 12:07 PM, John Cowan wrote: > > The intended range and precision of a JSON number matches that of an > IEEE 754:2008 binary64 (double precision) number Is this true? Doesn't seem so. - Rob --089e014953f2ab09b104e508259d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 28, 2013 at 12:07 PM, John Cowan <cowan@= mercury.ccil.org> wrote:

=A0 =A0The intended range and precision of a JSON number matches that of an=
=A0 =A0IEEE 754:2008 binary64 (double precision) number
Is this true? Doesn't seem so.

- = Rob

--089e014953f2ab09b104e508259d-- From cabo@tzi.org Wed Aug 28 14:02:32 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85D21F9F2D for ; Wed, 28 Aug 2013 14:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.188 X-Spam-Level: X-Spam-Status: No, score=-106.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-GqYSgdDurq for ; Wed, 28 Aug 2013 14:02:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EC91E21F9EFB for ; Wed, 28 Aug 2013 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r7SL2AOO003716; Wed, 28 Aug 2013 23:02:10 +0200 (CEST) Received: from [192.168.217.105] (p5489329B.dip0.t-ipconnect.de [84.137.50.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AF13A400; Wed, 28 Aug 2013 23:02:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130828203232.GD8176@mercury.ccil.org> Date: Wed, 28 Aug 2013 23:02:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F642EF5-9975-407A-BE62-E3293B2951E8@tzi.org> References: <20130828190706.GB8176@mercury.ccil.org> <521E5B6E.8040209@att.com> <20130828203232.GD8176@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: Tony Hansen , JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:02:33 -0000 On Aug 28, 2013, at 22:32, John Cowan wrote: >> To maximize interoperability, >> numeric values should be limited to those that may be exactly encoded = as >> an IEEE 754:2008 binary64 (double precision) binary64 number. >=20 > I'm good with that (it's basically what I proposed in the first place = to > the sub-WG), except I wouldn't use "should" for fear of confusion > with "SHOULD". One possible wording: # Interoperability can be maximized by limiting numeric values to = those... ("Maximize" isn't strictly true, you probably need to stick to what can = be represented in a signed (two's complement) 32-bit integer for that, = but really "maximizing" is not usually needed.) # Wide interoperability can be achieved by limiting numeric values to = those... All this could be introduced and motivated by a sentence such as: # JSON numbers are typically decoded into a number system chosen by the = receiving implementation, # which may set limits on the range and precision of numbers it can = represent, # Not all JSON numbers will then be representable exactly, or at all, in = that. Gr=FC=DFe, Carsten From tbray@textuality.com Wed Aug 28 14:35:04 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A621F9DBA for ; Wed, 28 Aug 2013 14:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndae7TIfRyS2 for ; Wed, 28 Aug 2013 14:34:59 -0700 (PDT) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 77DDF21F9DB4 for ; Wed, 28 Aug 2013 14:34:59 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so4614918vbf.10 for ; Wed, 28 Aug 2013 14:34:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Pfp0saAyThTkThI31EaK4AKGOw3yVkOYnhQapCZlzpQ=; b=cTqs7zS1pljS2i5uAHeY8lLX5EPIGkt00lQgv2i6lpb7AaY7FfWaevkGtEBndOlIDQ u05slIDAXeDFG9DwZYvCQIXZ47THoL1bPj7yMCWPqbdLSkW+koNrZbyOkgU8k3/9vsVV oAXVszhklEq/jwRn5dR2RMiGftlanxUCY7g9UNnq4Sgp3Cytv+VYwAmxsEGZlJB7ftlc JFYbOPGiMDYiJUubWfNTFBc95ef4/4XwSt36M8SxZhTS2Rj2+PMvfHXWKhWf7RR4X8li TO5CRoz71R2kFH3hXHL9bYw23q/uFIczLVG+x4rUY6N9Gj35f6kXo47ljJgfoRTCJXjp OA4Q== X-Gm-Message-State: ALoCoQle5Uk7qdVF1f0mTr0x2/Pa0sLoxPQxQQvml2hWFfDCjOxPQym7FBzb4X4Ozp7nMMosAcwB MIME-Version: 1.0 X-Received: by 10.220.164.70 with SMTP id d6mr1540vcy.19.1377725696605; Wed, 28 Aug 2013 14:34:56 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Wed, 28 Aug 2013 14:34:56 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <5F642EF5-9975-407A-BE62-E3293B2951E8@tzi.org> References: <20130828190706.GB8176@mercury.ccil.org> <521E5B6E.8040209@att.com> <20130828203232.GD8176@mercury.ccil.org> <5F642EF5-9975-407A-BE62-E3293B2951E8@tzi.org> Date: Wed, 28 Aug 2013 14:34:56 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7b414aa4be8f2004e508c297 Cc: Tony Hansen , John Cowan , JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:35:04 -0000 --047d7b414aa4be8f2004e508c297 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I really like Carsten=E2=80=99s =E2=80=9CWide interoperability=E2=80=9D phr= ase, and now that I think of it, losing the term =E2=80=9Cintended=E2=80=9D is probably a good = idea. I=E2=80=99m neutral on the motivational text; I=E2=80=99m assuming this is something th= at everyone knows. -T On Wed, Aug 28, 2013 at 2:02 PM, Carsten Bormann wrote: > On Aug 28, 2013, at 22:32, John Cowan wrote: > > >> To maximize interoperability, > >> numeric values should be limited to those that may be exactly encoded = as > >> an IEEE 754:2008 binary64 (double precision) binary64 number. > > > > I'm good with that (it's basically what I proposed in the first place t= o > > the sub-WG), except I wouldn't use "should" for fear of confusion > > with "SHOULD". > > One possible wording: > > # Interoperability can be maximized by limiting numeric values to those..= . > > ("Maximize" isn't strictly true, you probably need to stick to what can b= e > represented in a signed (two's complement) 32-bit integer for that, but > really "maximizing" is not usually needed.) > > # Wide interoperability can be achieved by limiting numeric values to > those... > > All this could be introduced and motivated by a sentence such as: > > # JSON numbers are typically decoded into a number system chosen by the > receiving implementation, > # which may set limits on the range and precision of numbers it can > represent, > # Not all JSON numbers will then be representable exactly, or at all, in > that. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b414aa4be8f2004e508c297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I really like Carsten=E2=80=99s =E2=80=9CWide interoperabi= lity=E2=80=9D phrase, and now that I think of it, losing the term =E2=80=9C= intended=E2=80=9D is probably a good idea.=C2=A0 I=E2=80=99m neutral on the= motivational text; I=E2=80=99m assuming this is something that everyone kn= ows. -T


On Wed,= Aug 28, 2013 at 2:02 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Aug 28, 2013, at 22:32, John Cowan <cowan@mercury.ccil.org> wrote:

>> To maximize interoperability,
>> numeric values should be limited to those that may be exactly enco= ded as
>> an IEEE 754:2008 binary64 (double precision) binary64 number.
>
> I'm good with that (it's basically wha= t I proposed in the first place to
> the sub-WG), except I wouldn't use "should" for fear of = confusion
> with "SHOULD".

One possible wording:

# Interoperability can be maximized by limiting numeric values to those...<= br>
("Maximize" isn't strictly true, you probably need to stick t= o what can be represented in a signed (two's complement) 32-bit integer= for that, but really "maximizing" is not usually needed.)

# Wide interoperability can be achieved by limiting numeric values to those= ...

All this could be introduced and motivated by a sentence such as:

# JSON numbers are typically decoded into a number system chosen by the rec= eiving implementation,
# which may set limits on the range and precision of numbers it can represe= nt,
# Not all JSON numbers will then be representable exactly, or at all, in th= at.

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

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

--047d7b414aa4be8f2004e508c297-- From stefan@drees.name Wed Aug 28 22:26:11 2013 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C321F85F5 for ; Wed, 28 Aug 2013 22:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeLd1S+FOXUF for ; Wed, 28 Aug 2013 22:26:05 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDAA21F9EEE for ; Wed, 28 Aug 2013 22:26:04 -0700 (PDT) Received: from newyork.local.box ([93.129.151.122]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LbJCQ-1Vu32e3NUY-00kynT for ; Thu, 29 Aug 2013 07:26:03 +0200 Message-ID: <521EDB69.5030502@drees.name> Date: Thu, 29 Aug 2013 07:26:01 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Carsten Bormann References: <20130828190706.GB8176@mercury.ccil.org> <521E5B6E.8040209@att.com> <20130828203232.GD8176@mercury.ccil.org> <5F642EF5-9975-407A-BE62-E3293B2951E8@tzi.org> In-Reply-To: <5F642EF5-9975-407A-BE62-E3293B2951E8@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:H2MoOHTK8q9okRj8r5tB3CmCSC4dDYSosWQ0AAvRV1p3d0QuFkg FO1ZEbRToHIqI5uyQvnz2QugYk2otA1GcRqGb99mfIKPO7lzjS7oeZ77KzgVhYoSY+vTGTS 3yoz5AhgLW6o/JdFX8twGTgIx2JNk/vDG6qPZ50j/NaLUtupMejqsRkffpYUDwuUarVH6ns e/PMMa5J255iVjGNLZQ0w== Cc: Tony Hansen , John Cowan , JSON WG Subject: Re: [Json] Proposal for numeric precision in JSON bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 05:26:11 -0000 Am 28.08.13 23:02, schrieb Carsten Bormann: > On Aug 28, 2013, at 22:32, John Cowan wrote: > >>> To maximize interoperability, >>> numeric values should be limited to those that may be exactly encoded as >>> an IEEE 754:2008 binary64 (double precision) binary64 number. >> >> I'm good with that (it's basically what I proposed in the first place to >> the sub-WG), except I wouldn't use "should" for fear of confusion >> with "SHOULD". > > One possible wording: > > # Interoperability can be maximized by limiting numeric values to those... > > ("Maximize" isn't strictly true, you probably need to stick to what can be represented in a signed (two's complement) 32-bit integer for that, but really "maximizing" is not usually needed.) > > # Wide interoperability can be achieved by limiting numeric values to those... > > All this could be introduced and motivated by a sentence such as: > > # JSON numbers are typically decoded into a number system chosen by the receiving implementation, > # which may set limits on the range and precision of numbers it can represent, > # Not all JSON numbers will then be representable exactly, or at all, in that. > ... +1 from me for these wordings. Maybe stating (as replacement for the former): Interoperability can be improved by limiting numeric values to those... I understand interoperability as a finite two state claim (to be or not to be) thus forcing a transition from say 90% to 95% interoperability is not too useful in the general case, i.e. if you do not care for these exact 5% extra "fit" ;-). As any non 100% interoperability may be a quest for improval we should be in the classical maximize versus satisfice quest - so improve would represent the latter quite well. What do the others think? ["Stefan"]