From nobody Wed Jul 2 07:12:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5C1A03C7 for ; Tue, 1 Jul 2014 20:04:04 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7d2nl-52Bad for ; Tue, 1 Jul 2014 20:04:02 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BA71A03C0 for ; Tue, 1 Jul 2014 20:04:02 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so11694116pab.31 for ; Tue, 01 Jul 2014 20:04:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=DttazNUYS5g54bDzoj+Ut2buzUwjvTQyM8b5iDc+Uxs=; b=MxQ99w+1DEAC5Ey7PnvaAPBBqdHwSV8V9Dkdl1f6V+ElEyuMGvVABjPFaqhh4bc+dK Sq7HyD18TUCZ8WgNogDfYyl4OPUOA/LapClpwkg1LIPPquLR0poKdBelEko2VDBrgBLW iat9fa/xQ4+yZXBzAwwq9v/4tYZqx9uFzn6wdKCAtIMDp4n7HMDKoWRQCw+lu7WPnUAN d0yiwnzSiVAJgqzTRnkcYBMNJ76GKg2BxobQsRW2xK8HneKrFkcxoW3/pyO4dFltJd2s hFSUHDYa/JRLG/r8EOGJd1z1bLF9GWl2d9mCie5DfoA2ieL6pFQTTGM9Rht5ibVMHI0T e/Fw== X-Gm-Message-State: ALoCoQkHj4n6VhkkqRX1xYushY3s7b12O6HQHtbOXIBcJKSI7nDQBJdGpgQezk+bLcioYAwr6Io1 MIME-Version: 1.0 X-Received: by 10.67.4.138 with SMTP id ce10mr61753582pad.12.1404270241991; Tue, 01 Jul 2014 20:04:01 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.22.134 with HTTP; Tue, 1 Jul 2014 20:04:01 -0700 (PDT) X-Originating-IP: [192.0.216.13] Date: Tue, 1 Jul 2014 20:04:01 -0700 X-Google-Sender-Auth: D8l4BU4B8OrPbA_-8OVTZFW-Eqc Message-ID: From: Mark Baker To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/OGjHM0Br7HcHSGBUNMxFud0F4PQ X-Mailman-Approved-At: Wed, 02 Jul 2014 07:12:28 -0700 Subject: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 03:04:04 -0000 Greetings, There's no mention of which media type I-JSON content should use. A quick check of the archives shows recent discussion about application/xxx+i-json and application/i-json, but I don't know why it isn't yet in the draft. I think it's essential to get this correct, given the compatibility goals of the format. FWIW, I agree that a non +json type is required, and also agree that its short name should be usable as a suffix. So I'd personally go with application/ijson and application/*+ijson as I expect many will find the use of "-" confusing in suffix form. The must-ignore/must-understand section also seems out of place here. "must understand" has historically not referred to a lack of extensibility, but to an inline declaration that some particular extension cannot be safely ignored (see SOAP). Instead it's used here as the opposite of "must ignore". And I also don't particularly care for the characterization of the extensibility of a data format in terms of implementation behaviour; the point is not that implementations "must ignore" unknown extensions, it's that the format is designed so it can be interpreted piecemeal[1], and that seems to already be part of the assumed fabric of JSON (luckily, schema-think hasn't yet taken over JSON-land) so doesn't seem worth mentioning. I'd suggest removing this section. [1] http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210 From nobody Wed Jul 2 07:40:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72CD1A02EF for ; Wed, 2 Jul 2014 07:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-bacP25aZx4 for ; Wed, 2 Jul 2014 07:40:39 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267781A02C1 for ; Wed, 2 Jul 2014 07:40:39 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so9140440wib.4 for ; Wed, 02 Jul 2014 07:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sQMmLdGZSpFitKGxyWsitC4v5wi8TqRP75L+J1ay4f0=; b=LMOisUJ4s5IUfkCgWj7YwPXQsfWvyQFXfbhM1hIp4TTdpMP9z3I79smp+tvujlTpdS dYWcBkqHDCXdSVNnngWlMUPoFibc6eO+R6yss5EjYqdZTRafwDxNjwWI94M98EOgaTsq PCG0MHpuGRQYRJm25wgtAcsnBRC8CrVzvLYKMV4sXak9gSJ0mvlsqJjwTfY8/7xIuzHR VD9K/DVTLHkj7v4DJT7alxgc2Qj2Tci2rAifDXqk1jibliyu6nQf5E2ie1+MgHy/T6KQ w392J4toZgtq1XEbG/GgQuO93SPK+Q8wfJjWna1XhKx0nnghXtWQ9iMNn2e2HtN7pVpC gMsQ== MIME-Version: 1.0 X-Received: by 10.180.101.39 with SMTP id fd7mr4712859wib.65.1404312037714; Wed, 02 Jul 2014 07:40:37 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Wed, 2 Jul 2014 07:40:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jul 2014 10:40:37 -0400 X-Google-Sender-Auth: yURpqhM-5Djpoe_n5_hjlSboSLk Message-ID: From: Phillip Hallam-Baker To: Mark Baker Content-Type: multipart/alternative; boundary=f46d041825d229719304fd36e007 Archived-At: http://mailarchive.ietf.org/arch/msg/json/2Ut5aIECd8_PCgRtDnzZOCRmGA8 Cc: JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 14:40:41 -0000 --f46d041825d229719304fd36e007 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 1, 2014 at 11:04 PM, Mark Baker wrote: > Greetings, > > There's no mention of which media type I-JSON content should use. A > quick check of the archives shows recent discussion about > application/xxx+i-json and application/i-json, but I don't know why it > isn't yet in the draft. I think it's essential to get this correct, > given the compatibility goals of the format. > I disagree. The only use for Content-Type is for content negotiation. There is no situation in which a negotiation that makes a distinction between JSON and I-JSON makes any sense. Content identification that tells me a document is JSON is useless unless I know the schema or purpose of the document. If I write a protocol then I am going to tell people to use I-JSON encoding or there is no value to it. If the sender has an option to choose between JSON and I-JSON then I have to implement both and nothing is saved or simplified. There is one situation in which I might use a content type and that is where a protocol is offered in more than one encoding. For example, SAML in JSON. If I have an application that has no XML except for one Web Service I might well offer that service in JSON or XML. Another case where negotiation is frequently desirable is where a protocol designer has become confused by REST ideology and has the idea that request parameters should be URI encoded and responses returned in JSON. Many of us would much prefer to do everything in one format. So I don't see any reason to revisit the issue of a content-type. JSON and I-JSON are the same thing as far as content negotiation is concerned and the distinction is useless for content identification. Where it would be useful to revise things would be to define a particular way to specify the semantics of a JSON document, or at least the protocol family. For example, I have a protocol that allows a client to retrieve the current phinger (.phb) document corresponding to a phingerprint (hash of the public key info). The content is encoded in JSON. But it is not just any JSON, it is JSON encoding of a phinger which is a personal PKI root file. Since the mechanism being used here is the /.well-known convention (/.well-known/ppe at the moment for testing), it would make sense to re-use the prefix assigned for that as a modifier to the content-type Content-Type: application/json; protocol=ppe --f46d041825d229719304fd36e007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 1, 2014 at 11:04 PM, Mark Baker <distobj@acm.org> wrot= e:
Greetings,

There's no mention of which media type I-JSON content should use. A
quick check of the archives shows recent discussion about
application/xxx+i-json and application/i-json, but I don't know why it<= br> isn't yet in the draft. I think it's essential to get this correct,=
given the compatibility goals of the format.

I disagree.

The only use = for Content-Type is for content negotiation. There is no situation in which= a negotiation that makes a distinction between JSON and I-JSON makes any s= ense.

Content ide= ntification that tells me a document is JSON is useless unless I know the s= chema or purpose of the document.


If I write a protocol then I am going = to tell people to use I-JSON encoding or there is no value to it. If the se= nder has an option to choose between JSON and I-JSON then I have to impleme= nt both and nothing is saved or simplified.=C2=A0

There is on= e situation in which I might use a content type and that is where a protoco= l is offered in more than one encoding. For example, SAML in JSON. If I hav= e an application that has no XML except for one Web Service I might well of= fer that service in JSON or XML. Another case where negotiation is frequent= ly desirable is where a protocol designer has become confused by REST ideol= ogy and has the idea that request parameters should be URI encoded and resp= onses returned in JSON. Many of us would much prefer to do everything in on= e format.


<= div class=3D"gmail_extra">So I don't see any reason to revisit the issu= e of a content-type. JSON and I-JSON are the same thing as far as content n= egotiation is concerned and the distinction is useless for content identifi= cation.

Where it wo= uld be useful to revise things would be to define a particular way to speci= fy the semantics of a JSON document, or at least the protocol family.


<= div class=3D"gmail_extra">For example, I have a protocol that allows a clie= nt to retrieve the current phinger (.phb) document corresponding to a phing= erprint (hash of the public key info). The content is encoded in JSON. But = it is not just any JSON, it is JSON encoding of a phinger which is a person= al PKI root file.

Since the m= echanism being used here is the /.well-known convention (/.well-known/ppe a= t the moment for testing), it would make sense to re-use the prefix assigne= d for that as a modifier to the content-type

Content-Typ= e: application/json; protocol=3Dppe



--f46d041825d229719304fd36e007-- From nobody Wed Jul 2 08:55:21 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40761B27D5 for ; Wed, 2 Jul 2014 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0mziCwSME5b for ; Wed, 2 Jul 2014 08:55:16 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87B81B27CF for ; Wed, 2 Jul 2014 08:55:16 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz11so11367181veb.17 for ; Wed, 02 Jul 2014 08:55:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B/2/Mni03ciLY4RYi7vIl/Vhb6kf6PqlwOTczr5EclU=; b=Rqd0SKcg46UTCrluQ/hPayUwfE9JdZOCIhsmiGQXZerGX+TfA8UWmaaFHLa6RcVOV7 39l0A/DdBbWbTITSYoJdJS+khxn1E/rq/qP5bnI4pIszEq+iQYkc9V0oL56/0KuxBQAf j8Ev96OnZcZ1eYNAv7hor6KbTEPqbpaomlcV5JDMCgZWMxgMEdta+6WGf1XsSMgjTpzz /hFPm/eRyu1u0t08LUZcEGn4AyzxQshTX0WQgRSJGhomLn+qnUqOzgIkc1YAtBWMm4aM n6cLyQuCX7vRPqPNXOawRfMhcmmDce4lY05RQ+N1Q3uyQOrv8BZ/gGtOt++UVAollkCp GrnQ== X-Gm-Message-State: ALoCoQkDU6OSgL/xp8hjdupJyRXfHtU0ya7RbQpUhvSNHSajw1cvfUGM8UDNEoFfrTZ/zllzdyTd X-Received: by 10.52.163.208 with SMTP id yk16mr6397247vdb.36.1404316515746; Wed, 02 Jul 2014 08:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Wed, 2 Jul 2014 08:54:55 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: From: Tim Bray Date: Wed, 2 Jul 2014 08:54:55 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c24dfe12cd1804fd37ebf0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4EkQSUVhOV4M73XmgdnDENZXsTk Cc: Mark Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 15:55:19 -0000 --001a11c24dfe12cd1804fd37ebf0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 2, 2014 at 7:40 AM, Phillip Hallam-Baker wrote: > The only use for Content-Type is for content negotiation. There is no > situation in which a negotiation that makes a distinction between JSON an= d > I-JSON makes any sense. > =E2=80=8BWell, the =E2=80=9Conly use is for content negotiation=E2=80=9D as= sertion is just wrong, Content-type is used to dispatch to various software modules depending on what kind of thing you receive. =E2=80=8B I=E2=80=99ll say that just on Web-architectural grounds, I think distinct d= ata formats should have distinct Internet Media Types, and so it bothers me that we don=E2=80=99t have one for i-json. But the WG couldn=E2=80=99t per= ceive any real value in having one that=E2=80=99s distinct from JSON=E2=80=99s and I didn= =E2=80=99t have a forceful-enough argument to move the consensus on this. > > Content identification that tells me a document is JSON is useless unless > I know the schema or purpose of the document. > > > If I write a protocol then I am going to tell people to use I-JSON > encoding or there is no value to it. If the sender has an option to choos= e > between JSON and I-JSON then I have to implement both and nothing is save= d > or simplified. > > There is one situation in which I might use a content type and that is > where a protocol is offered in more than one encoding. For example, SAML = in > JSON. If I have an application that has no XML except for one Web Service= I > might well offer that service in JSON or XML. Another case where > negotiation is frequently desirable is where a protocol designer has beco= me > confused by REST ideology and has the idea that request parameters should > be URI encoded and responses returned in JSON. Many of us would much pref= er > to do everything in one format. > > > So I don't see any reason to revisit the issue of a content-type. JSON an= d > I-JSON are the same thing as far as content negotiation is concerned and > the distinction is useless for content identification. > > Where it would be useful to revise things would be to define a particular > way to specify the semantics of a JSON document, or at least the protocol > family. > > > For example, I have a protocol that allows a client to retrieve the > current phinger (.phb) document corresponding to a phingerprint (hash of > the public key info). The content is encoded in JSON. But it is not just > any JSON, it is JSON encoding of a phinger which is a personal PKI root > file. > > Since the mechanism being used here is the /.well-known convention > (/.well-known/ppe at the moment for testing), it would make sense to re-u= se > the prefix assigned for that as a modifier to the content-type > > Content-Type: application/json; protocol=3Dppe > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c24dfe12cd1804fd37ebf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Wed, Jul 2, 2014 at 7:40 AM, Phillip Hallam-Baker <ietf@hallambaker.com= > wrote:
The only use for Content-Type is for content negotiation. There is no situa= tion in which a negotiation that makes a distinction between JSON and I-JSO= N makes any sense.

=E2=80=8BWell, = the =E2=80=9Conly use is for content negotiation=E2=80=9D assertion is just= wrong, Content-type is used to dispatch to various software modules depend= ing on what kind of thing you receive. =C2=A0=E2=80=8B

I=E2=80=99ll say that just on = Web-architectural grounds, I think distinct data formats should have distin= ct Internet Media Types, and so it bothers me that we don=E2=80=99t have on= e for i-json. =C2=A0But the WG couldn=E2=80=99t perceive any real value in = having one that=E2=80=99s distinct from JSON=E2=80=99s and I didn=E2=80=99t= have =C2=A0a forceful-enough argument to move the consensus on this.



=C2=A0
<= div class=3D"gmail_quote">

Content ide= ntification that tells me a document is JSON is useless unless I know the s= chema or purpose of the document.


If I write a protocol then I am going = to tell people to use I-JSON encoding or there is no value to it. If the se= nder has an option to choose between JSON and I-JSON then I have to impleme= nt both and nothing is saved or simplified.=C2=A0

There is on= e situation in which I might use a content type and that is where a protoco= l is offered in more than one encoding. For example, SAML in JSON. If I hav= e an application that has no XML except for one Web Service I might well of= fer that service in JSON or XML. Another case where negotiation is frequent= ly desirable is where a protocol designer has become confused by REST ideol= ogy and has the idea that request parameters should be URI encoded and resp= onses returned in JSON. Many of us would much prefer to do everything in on= e format.


<= div class=3D"gmail_extra">So I don't see any reason to revisit the issu= e of a content-type. JSON and I-JSON are the same thing as far as content n= egotiation is concerned and the distinction is useless for content identifi= cation.

Where it wo= uld be useful to revise things would be to define a particular way to speci= fy the semantics of a JSON document, or at least the protocol family.


<= div class=3D"gmail_extra">For example, I have a protocol that allows a clie= nt to retrieve the current phinger (.phb) document corresponding to a phing= erprint (hash of the public key info). The content is encoded in JSON. But = it is not just any JSON, it is JSON encoding of a phinger which is a person= al PKI root file.

Since the m= echanism being used here is the /.well-known convention (/.well-known/ppe a= t the moment for testing), it would make sense to re-use the prefix assigne= d for that as a modifier to the content-type

Content-Typ= e: application/json; protocol=3Dppe




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




--
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--001a11c24dfe12cd1804fd37ebf0-- From nobody Wed Jul 2 09:11:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A3A1A011D for ; Wed, 2 Jul 2014 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-kvxw83sZtY for ; Wed, 2 Jul 2014 09:11:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743611B2820 for ; Wed, 2 Jul 2014 09:11:53 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1X2MnA-0002Bl-UG; Wed, 02 Jul 2014 11:49:52 -0400 Date: Wed, 2 Jul 2014 11:49:52 -0400 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20140702154952.GC21298@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/YjRSRwA9rdgAOUuRy7F8eAyHxjw Cc: Mark Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 16:11:59 -0000 Phillip Hallam-Baker scripsit: > The only use for Content-Type is for content negotiation. This isn't true in general, unless you consider mere announcement to be a subtype of negotiation. ("Let's negotiate: you do what I say, mmmkay?") One and the same entity body could be JSON, plain text, HTML, or some binary format, and only the Content-Type: header can say which. It's perfectly reasonable to imagine an application which can accept any of these. > There is no situation in which a negotiation that makes a distinction > between JSON and I-JSON makes any sense. That's true, but it doesn't mean that there is no point in labeling I-JSON as such. > Content identification that tells me a document is JSON is useless > unless I know the schema or purpose of the document. Not so. For example, it may be your job to deserialize the JSON into some internal format for processing by someone else. > If I write a protocol then I am going to tell people to use I-JSON > encoding or there is no value to it. If the sender has an option to > choose between JSON and I-JSON then I have to implement both and > nothing is saved or simplified. +1 to that. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! --one of the verses not usually taught in U.S. schools From nobody Wed Jul 2 12:43:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254B1A04F1 for ; Wed, 2 Jul 2014 12:43:00 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQuHWif7Ft9x for ; Wed, 2 Jul 2014 12:42:59 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A415A1A03D4 for ; Wed, 2 Jul 2014 12:42:59 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so13126954pab.3 for ; Wed, 02 Jul 2014 12:42:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XdBCan4CtA4bgYjEZZnzOOfWgEYckb4jUdiGw4w6Ak4=; b=Mvd4V4U3n9+1zModrpvJLgnGt5T10EEdN5u6tXomoyN3TgDxfcfLwXDMCqjja0n42W KwdEn3j94K0LWbWAG+J0F5xxsw9q2FIsyO8nRml6BO11RnNCohGBjpAxAwWFWCVNvlcc J6HOFtol9KbVB9ABvjtcMj4jliZfmqJHa66IpC+cYI4ttkCuUzyAY4TgmexWC+wip+G6 Idk8gRv1dJb8YDCQf8XgRhdm9VawdW0o4s+U3YSXoKpKnPi9/Wfx+u9iWkFRamHkeTsD 6ADqpKaaVdyiiAgy8TvKajuG/djmVEI30UPg94BjOqo+yErWmyObmNfdV3lJAA9tuxP1 EoPQ== X-Gm-Message-State: ALoCoQlOmagihiaLilM1Gr81rMTdP5wRH7rbPokh2uPbv0OhPjqSg+6JplKAREazv6+HZ+3Q3ih1 MIME-Version: 1.0 X-Received: by 10.68.160.163 with SMTP id xl3mr73392116pbb.39.1404330179245; Wed, 02 Jul 2014 12:42:59 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.22.134 with HTTP; Wed, 2 Jul 2014 12:42:59 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: Date: Wed, 2 Jul 2014 15:42:59 -0400 X-Google-Sender-Auth: _jN6XQrpWgfdKmR97j74W_pC4Ug Message-ID: From: Mark Baker To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/_ERIgxmIijdsHJQJYHJq6jxDSOI Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jul 2014 19:43:00 -0000 On Wed, Jul 2, 2014 at 11:54 AM, Tim Bray wrote: > I=E2=80=99ll say that just on Web-architectural grounds, I think distinct= data > formats should have distinct Internet Media Types, and so it bothers me t= hat > we don=E2=80=99t have one for i-json. But the WG couldn=E2=80=99t percei= ve any real value > in having one that=E2=80=99s distinct from JSON=E2=80=99s and I didn=E2= =80=99t have a > forceful-enough argument to move the consensus on this. Were there driving use cases behind I-JSON? I could imagine a (atypical) scenario where it's used as a "publishing profile", defining a best practice for publishers (Postel-ian style), with no regard for what happens once it's consumed. You wouldn't need to say anything about media types then. But if you want to be able to exchange I-JSON over the Web or Internet, so that recipients know, e.g., not to add duplicate keys, then that can only practically be indicated with a new media type. From nobody Fri Jul 4 18:30:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7B1A0011 for ; Fri, 4 Jul 2014 18:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXwAOvni5lmo for ; Fri, 4 Jul 2014 18:30:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA3F1A0118 for ; Fri, 4 Jul 2014 18:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2168; q=dns/txt; s=iport; t=1404523836; x=1405733436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xoxOk6Iuldlg0QgAXoId3lvJ21JWuopwMBScQYFJPxU=; b=GNVXnKW8qQmZWii1CHgw01xUnl9a/oxjAonWGlEh4q3qD+N5Uw/wjOoH h7WEMWheM7F/uc0i8+RXVvH016aamCE/a5UOFTvrytz60iblBvRxiqYYv IPT1P8YKB82/xXRQjP8PqI2PTTZ54WIjePJ2OL1MtQNvABb36f42Wlk4t A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFADBUt1OtJA2I/2dsb2JhbABagw5SWoJvu32HPwEZbhZ1hAMBAQEEAQEBIBE6CxACAQgOCgICJgICAiULFRACBAENBYhCDa81mm4TBIEsjXYHgneBTAWadpQMg0OCMA X-IronPort-AV: E=Sophos;i="5.01,605,1400025600"; d="scan'208";a="58432248" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 05 Jul 2014 01:30:34 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s651UYdH013420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jul 2014 01:30:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 20:30:34 -0500 From: "Joe Hildebrand (jhildebr)" To: Mark Baker , Tim Bray Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPli3TeLKmyOx7w0yav7qrcKonZpuQpE0A Date: Sat, 5 Jul 2014 01:30:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.224.80] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/5K8xY_o5ZOSfATEj1HCEOZ-oKy8 Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jul 2014 01:30:44 -0000 VGhlcmUgYXJlIHRpbWVzIHdoZW4sIGluIHRoZSBkb2N1bWVudGF0aW9uIGZvciBhIHNlcnZpY2Ug dGhhdCBpcyBwcm9kdWNpbmcNCkpTT04sIEkgd291bGQgbGlrZSB0byBzYXk6DQoNCiJJZiB5b3Ug cmVjZWl2ZSBhIG1lc3NhZ2UgZnJvbSBtZSB0aGF0IGlzIG5vdCBzdHJpY3RseSBJLUpTT04sIEkg d291bGQNCnByZWZlciB5b3UgdHJlYXQgaXQgYXMgYW4gZXJyb3Igb24gbXkgcGFydCwgYW5kIHRo ZXJlZm9yZSB0cmVhdCBteSBtZXNzYWdlDQphcyBpbnZhbGlkLCBiZWNhdXNlIGlmIHNvbWV0aGlu ZyB3ZW50IHdyb25nIGVub3VnaCB0aGF0IHdoYXQgSSBzZW50IHlvdQ0Kd2Fzbid0IHZhbGlkIEkt SlNPTiBteSBzZXJ2ZXIgcm9vbSBpcyBsaWtlbHkgb24gZmlyZS4iDQoNCg0KT24gNy8yLzE0LCAx OjQyIFBNLCAiTWFyayBCYWtlciIgPGRpc3RvYmpAYWNtLm9yZz4gd3JvdGU6DQoNCj5PbiBXZWQs IEp1bCAyLCAyMDE0IGF0IDExOjU0IEFNLCBUaW0gQnJheSA8dGJyYXlAdGV4dHVhbGl0eS5jb20+ IHdyb3RlOg0KPj4gSeKAmWxsIHNheSB0aGF0IGp1c3Qgb24gV2ViLWFyY2hpdGVjdHVyYWwgZ3Jv dW5kcywgSSB0aGluayBkaXN0aW5jdCBkYXRhDQo+PiBmb3JtYXRzIHNob3VsZCBoYXZlIGRpc3Rp bmN0IEludGVybmV0IE1lZGlhIFR5cGVzLCBhbmQgc28gaXQgYm90aGVycyBtZQ0KPj50aGF0DQo+ PiB3ZSBkb27igJl0IGhhdmUgb25lIGZvciBpLWpzb24uICBCdXQgdGhlIFdHIGNvdWxkbuKAmXQg cGVyY2VpdmUgYW55IHJlYWwNCj4+dmFsdWUNCj4+IGluIGhhdmluZyBvbmUgdGhhdOKAmXMgZGlz dGluY3QgZnJvbSBKU09O4oCZcyBhbmQgSSBkaWRu4oCZdCBoYXZlICBhDQo+PiBmb3JjZWZ1bC1l bm91Z2ggYXJndW1lbnQgdG8gbW92ZSB0aGUgY29uc2Vuc3VzIG9uIHRoaXMuDQo+DQo+V2VyZSB0 aGVyZSBkcml2aW5nIHVzZSBjYXNlcyBiZWhpbmQgSS1KU09OPyBJIGNvdWxkIGltYWdpbmUgYQ0K PihhdHlwaWNhbCkgc2NlbmFyaW8gd2hlcmUgaXQncyB1c2VkIGFzIGEgInB1Ymxpc2hpbmcgcHJv ZmlsZSIsDQo+ZGVmaW5pbmcgYSBiZXN0IHByYWN0aWNlIGZvciBwdWJsaXNoZXJzIChQb3N0ZWwt aWFuIHN0eWxlKSwgd2l0aCBubw0KPnJlZ2FyZCBmb3Igd2hhdCBoYXBwZW5zIG9uY2UgaXQncyBj b25zdW1lZC4gWW91IHdvdWxkbid0IG5lZWQgdG8gc2F5DQo+YW55dGhpbmcgYWJvdXQgbWVkaWEg dHlwZXMgdGhlbi4NCj4NCj5CdXQgaWYgeW91IHdhbnQgdG8gYmUgYWJsZSB0byBleGNoYW5nZSBJ LUpTT04gb3ZlciB0aGUgV2ViIG9yDQo+SW50ZXJuZXQsIHNvIHRoYXQgcmVjaXBpZW50cyBrbm93 LCBlLmcuLCBub3QgdG8gYWRkIGR1cGxpY2F0ZSBrZXlzLA0KPnRoZW4gdGhhdCBjYW4gb25seSBw cmFjdGljYWxseSBiZSBpbmRpY2F0ZWQgd2l0aCBhIG5ldyBtZWRpYSB0eXBlLg0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+anNvbiBtYWlsaW5n IGxpc3QNCj5qc29uQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9qc29uDQo+DQoNCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Fri Jul 4 19:04:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEB91A00FF for ; Fri, 4 Jul 2014 19:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mZIRqggWgo6 for ; Fri, 4 Jul 2014 19:04:31 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954C51A00B9 for ; Fri, 4 Jul 2014 19:04:31 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so2129958vcb.30 for ; Fri, 04 Jul 2014 19:04:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Xm8t0NHRl+VLO7LU4hNAj53athoidc23hoNGb/L9llg=; b=R+oRJiKSUgJM9LuGlskqHTo2siPYxowk1DliKAtWVJARjgq/DCOe6ut2w7CB8cxFGI M8sP8HKxysOUX/sfXDo/wfmxGQBRk58pokWkvXK7sfY+Mp9qwfj4llBfdFDevi12fAyM Buwb0ws5fqhJdFXfRuFu6i8/S+sXrc8gEp56dAhGsuLW6RF1sysfdOb2UwOIen0XNvti jUSUSOSQz9fFYige+FQhncAZZe2KSQ2jg2PA9Aa8JcDaq705l78DURZ3YgSxNyusoujx iYGna4icQAqZJNbaOsNbkjCMZ/Lk7xujg1hlj5wAIdwjj3UUBzrcOoA9s7juzMHqikdY aEqA== X-Gm-Message-State: ALoCoQk1yX7bMT209XIbbKLm5j6mNibn/993Q/9u2JM40jL0LftbZT/6TKOGGoBL2f0E2PcUAlXS X-Received: by 10.58.188.199 with SMTP id gc7mr12549430vec.4.1404525870597; Fri, 04 Jul 2014 19:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Fri, 4 Jul 2014 19:04:10 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: From: Tim Bray Date: Fri, 4 Jul 2014 19:04:10 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b5db99e98626c04fd68a903 Archived-At: http://mailarchive.ietf.org/arch/msg/json/44e7v0z7xOe-HvxTPRHpzOJEcjI Cc: Mark Baker , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jul 2014 02:04:33 -0000 --047d7b5db99e98626c04fd68a903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, would an I-JSON media type help in producing the desired effect? Not obvious to me. In practice, I=E2=80=99m supposing that if I=E2=80=99m writ= ing a consumer for JIP (Joe=E2=80=99s Internet Protocol) I=E2=80=99d toggle my JSON parser= into I-JSON mode because I know that=E2=80=99s what the RFC said. On Fri, Jul 4, 2014 at 6:30 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > There are times when, in the documentation for a service that is producin= g > JSON, I would like to say: > > "If you receive a message from me that is not strictly I-JSON, I would > prefer you treat it as an error on my part, and therefore treat my messag= e > as invalid, because if something went wrong enough that what I sent you > wasn't valid I-JSON my server room is likely on fire." > > > On 7/2/14, 1:42 PM, "Mark Baker" wrote: > > >On Wed, Jul 2, 2014 at 11:54 AM, Tim Bray wrote: > >> I=E2=80=99ll say that just on Web-architectural grounds, I think disti= nct data > >> formats should have distinct Internet Media Types, and so it bothers m= e > >>that > >> we don=E2=80=99t have one for i-json. But the WG couldn=E2=80=99t per= ceive any real > >>value > >> in having one that=E2=80=99s distinct from JSON=E2=80=99s and I didn= =E2=80=99t have a > >> forceful-enough argument to move the consensus on this. > > > >Were there driving use cases behind I-JSON? I could imagine a > >(atypical) scenario where it's used as a "publishing profile", > >defining a best practice for publishers (Postel-ian style), with no > >regard for what happens once it's consumed. You wouldn't need to say > >anything about media types then. > > > >But if you want to be able to exchange I-JSON over the Web or > >Internet, so that recipients know, e.g., not to add duplicate keys, > >then that can only practically be indicated with a new media type. > > > >_______________________________________________ > >json mailing list > >json@ietf.org > >https://www.ietf.org/mailman/listinfo/json > > > > > -- > Joe Hildebrand > > > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --047d7b5db99e98626c04fd68a903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So,= would an I-JSON media type help in producing the desired effect? Not obvio= us to me. =C2=A0In practice, I=E2=80=99m supposing that if I=E2=80=99m writ= ing a consumer for JIP (Joe=E2=80=99s Internet Protocol) I=E2=80=99d toggle= my JSON parser into I-JSON mode because I know that=E2=80=99s what the RFC= said.


On Fri,= Jul 4, 2014 at 6:30 PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
There are times when, in the documentation f= or a service that is producing
JSON, I would like to say:

"If you receive a message from me that is not strictly I-JSON, I would=
prefer you treat it as an error on my part, and therefore treat my message<= br> as invalid, because if something went wrong enough that what I sent you
wasn't valid I-JSON my server room is likely on fire."


On 7/2/14, 1:42 PM, "Mark Baker" <distobj@acm.org> wrote:

>On Wed, Jul 2, 2014 at 11:54 AM, Tim Bray <tbray@textuality.com> wrote:
>> I=E2=80=99ll say that just on Web-architectural grounds, I think d= istinct data
>> formats should have distinct Internet Media Types, and so it bothe= rs me
>>that
>> we don=E2=80=99t have one for i-json. =C2=A0But the WG couldn=E2= =80=99t perceive any real
>>value
>> in having one that=E2=80=99s distinct from JSON=E2=80=99s and I di= dn=E2=80=99t have =C2=A0a
>> forceful-enough argument to move the consensus on this.
>
>Were there driving use cases behind I-JSON? I could imagine a
>(atypical) scenario where it's used as a "publishing profile&q= uot;,
>defining a best practice for publishers (Postel-ian style), with no
>regard for what happens once it's consumed. You wouldn't need t= o say
>anything about media types then.
>
>But if you want to be able to exchange I-JSON over the Web or
>Internet, so that recipients know, e.g., not to add duplicate keys,
>then that can only practically be indicated with a new media type.
>
>___________________= ____________________________
>json mailing list
>json@ietf.org
>https://www.ietf.org/mailman/listinfo/json
>


--
Joe Hildebrand





--
- Tim Bray (If you=E2=80=99d like to send me a priv= ate message, see h= ttps://keybase.io/timbray)
--047d7b5db99e98626c04fd68a903-- From nobody Fri Jul 4 19:31:56 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42DB1A02BD for ; Fri, 4 Jul 2014 19:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.952 X-Spam-Level: X-Spam-Status: No, score=-13.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCXzmsznjeed for ; Fri, 4 Jul 2014 19:31:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752041A02A5 for ; Fri, 4 Jul 2014 19:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3744; q=dns/txt; s=iport; t=1404527511; x=1405737111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fg7iedXfcQYx2EUIdCSq4DiULOoDVEbxu9P5u6W7S30=; b=czLXXgfktRR5bV6TDmmNfxQNb05YU1xsSPhV/qRsuQNMoWi+ccdeCTtx ksqZ//YuCoB6zkXzjIvPbNeSZlxzXCNQA4gE9m9PUo9sJtzuvuhtjOeM8 /RZ2bab1vgzyL2Jh6r4NZ0D1JlxefoZvI5dJ3uktS2CpxeZlbeeLjjtK2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAH1it1OtJV2Z/2dsb2JhbABagw5SWoJvu32HPwEZbhZ1hAMBAQEEAQEBIBE6CxACAQgOCgICJgICAiULFRACBA4FiEINrzuacxMEgSyIOYUKMweCd4FMBZp2lAyDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,605,1400025600"; d="scan'208";a="58449374" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 05 Jul 2014 02:31:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s652VnuJ004690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jul 2014 02:31:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 21:31:49 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPli3TeLKmyOx7w0yav7qrcKonZpuQpE0AgABt+gD//6MigA== Date: Sat, 5 Jul 2014 02:31:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.224.80] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/RPld_yVgJ21ZFpz39rdAGi0EF4w Cc: Mark Baker , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jul 2014 02:31:54 -0000 VGhhdCdzIHdoYXQgSSdkIHdhbnQgeW91IHRvIGRvIGFzIGEgY29uc3VtZXIgb2YgbXkgc2Vydmlj ZS4gIEluIGEgcGVyZmVjdA0Kd29ybGQsIEVDTUFzY3JpcHQgd291bGQgaGF2ZSBhIHRoaXJkIHBh cmFtZXRlciBvbiBKU09OLnBhcnNlIHRoYXQgd2FzDQplaXRoZXIgYSBib29sZWFuIGNvbnRyb2xs aW5nIElKU09OIG1vZGUgKGRlZmF1bHRlZCB0byB0aGUgb2xkIGJlaGF2aW9yKSwNCm9yIHRoZSBz ZWNvbmQgcGFyYW1ldGVyIGNvdWxkIGVpdGhlciBiZSB0aGUgZXhpc3RpbmcgcmV2aXZlciBmdW5j dGlvbiBvcg0KYW4gb2JqZWN0IHdpdGggcmV2aXZlcjpmdW5jdGlvbiwgaWpzb246Ym9vbCwgYW5k IHdoYXRldmVyIGVsc2UgbmVlZHMgdG8gYmUNCmFkZGVkIGxhdGVyLiAgT3RoZXIgbGFuZ3VhZ2Uv bGlicmFyeSBtZWNoYW5pc21zIHdvdWxkIHRoZW4gZm9sbG93IHN1aXQNCmV2ZW50dWFsbHkuDQoN Ck9uIDcvNC8xNCwgODowNCBQTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0eS5jb20+IHdy b3RlOg0KDQo+U28sIHdvdWxkIGFuIEktSlNPTiBtZWRpYSB0eXBlIGhlbHAgaW4gcHJvZHVjaW5n IHRoZSBkZXNpcmVkIGVmZmVjdD8gTm90DQo+b2J2aW91cyB0byBtZS4gIEluIHByYWN0aWNlLCBJ 4oCZbSBzdXBwb3NpbmcgdGhhdCBpZiBJ4oCZbSB3cml0aW5nIGEgY29uc3VtZXINCj5mb3IgSklQ IChKb2XigJlzIEludGVybmV0IFByb3RvY29sKSBJ4oCZZCB0b2dnbGUgbXkgSlNPTiBwYXJzZXIN Cj4gaW50byBJLUpTT04gbW9kZSBiZWNhdXNlIEkga25vdyB0aGF04oCZcyB3aGF0IHRoZSBSRkMg c2FpZC4NCj4NCj4NCj4NCj5PbiBGcmksIEp1bCA0LCAyMDE0IGF0IDY6MzAgUE0sIEpvZSBIaWxk ZWJyYW5kIChqaGlsZGVicikNCj48amhpbGRlYnJAY2lzY28uY29tPiB3cm90ZToNCj4NCj5UaGVy ZSBhcmUgdGltZXMgd2hlbiwgaW4gdGhlIGRvY3VtZW50YXRpb24gZm9yIGEgc2VydmljZSB0aGF0 IGlzIHByb2R1Y2luZw0KPkpTT04sIEkgd291bGQgbGlrZSB0byBzYXk6DQo+DQo+IklmIHlvdSBy ZWNlaXZlIGEgbWVzc2FnZSBmcm9tIG1lIHRoYXQgaXMgbm90IHN0cmljdGx5IEktSlNPTiwgSSB3 b3VsZA0KPnByZWZlciB5b3UgdHJlYXQgaXQgYXMgYW4gZXJyb3Igb24gbXkgcGFydCwgYW5kIHRo ZXJlZm9yZSB0cmVhdCBteSBtZXNzYWdlDQo+YXMgaW52YWxpZCwgYmVjYXVzZSBpZiBzb21ldGhp bmcgd2VudCB3cm9uZyBlbm91Z2ggdGhhdCB3aGF0IEkgc2VudCB5b3UNCj53YXNuJ3QgdmFsaWQg SS1KU09OIG15IHNlcnZlciByb29tIGlzIGxpa2VseSBvbiBmaXJlLiINCj4NCj4NCj5PbiA3LzIv MTQsIDE6NDIgUE0sICJNYXJrIEJha2VyIiA8ZGlzdG9iakBhY20ub3JnPiB3cm90ZToNCj4NCj4+ T24gV2VkLCBKdWwgMiwgMjAxNCBhdCAxMTo1NCBBTSwgVGltIEJyYXkgPHRicmF5QHRleHR1YWxp dHkuY29tPiB3cm90ZToNCj4+PiBJ4oCZbGwgc2F5IHRoYXQganVzdCBvbiBXZWItYXJjaGl0ZWN0 dXJhbCBncm91bmRzLCBJIHRoaW5rIGRpc3RpbmN0IGRhdGENCj4+PiBmb3JtYXRzIHNob3VsZCBo YXZlIGRpc3RpbmN0IEludGVybmV0IE1lZGlhIFR5cGVzLCBhbmQgc28gaXQgYm90aGVycyBtZQ0K Pj4+dGhhdA0KPj4+IHdlIGRvbuKAmXQgaGF2ZSBvbmUgZm9yIGktanNvbi4gIEJ1dCB0aGUgV0cg Y291bGRu4oCZdCBwZXJjZWl2ZSBhbnkgcmVhbA0KPj4+dmFsdWUNCj4+PiBpbiBoYXZpbmcgb25l IHRoYXTigJlzIGRpc3RpbmN0IGZyb20gSlNPTuKAmXMgYW5kIEkgZGlkbuKAmXQgaGF2ZSAgYQ0K Pj4+IGZvcmNlZnVsLWVub3VnaCBhcmd1bWVudCB0byBtb3ZlIHRoZSBjb25zZW5zdXMgb24gdGhp cy4NCj4+DQo+PldlcmUgdGhlcmUgZHJpdmluZyB1c2UgY2FzZXMgYmVoaW5kIEktSlNPTj8gSSBj b3VsZCBpbWFnaW5lIGENCj4+KGF0eXBpY2FsKSBzY2VuYXJpbyB3aGVyZSBpdCdzIHVzZWQgYXMg YSAicHVibGlzaGluZyBwcm9maWxlIiwNCj4+ZGVmaW5pbmcgYSBiZXN0IHByYWN0aWNlIGZvciBw dWJsaXNoZXJzIChQb3N0ZWwtaWFuIHN0eWxlKSwgd2l0aCBubw0KPj5yZWdhcmQgZm9yIHdoYXQg aGFwcGVucyBvbmNlIGl0J3MgY29uc3VtZWQuIFlvdSB3b3VsZG4ndCBuZWVkIHRvIHNheQ0KPj5h bnl0aGluZyBhYm91dCBtZWRpYSB0eXBlcyB0aGVuLg0KPj4NCj4+QnV0IGlmIHlvdSB3YW50IHRv IGJlIGFibGUgdG8gZXhjaGFuZ2UgSS1KU09OIG92ZXIgdGhlIFdlYiBvcg0KPj5JbnRlcm5ldCwg c28gdGhhdCByZWNpcGllbnRzIGtub3csIGUuZy4sIG5vdCB0byBhZGQgZHVwbGljYXRlIGtleXMs DQo+PnRoZW4gdGhhdCBjYW4gb25seSBwcmFjdGljYWxseSBiZSBpbmRpY2F0ZWQgd2l0aCBhIG5l dyBtZWRpYSB0eXBlLg0KPj4NCj4NCj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+anNvbiBtYWlsaW5nIGxpc3QNCj4+anNvbkBpZXRmLm9yZw0K Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCj4+DQo+DQo+DQo+ LS0NCj4NCj4NCj5Kb2UgSGlsZGVicmFuZA0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0K Pi0tIA0KPi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1lIGEgcHJpdmF0ZSBt ZXNzYWdlLCBzZWUNCj5odHRwczovL2tleWJhc2UuaW8vdGltYnJheSA8aHR0cHM6Ly9rZXliYXNl LmlvL3RpbWJyYXk+KQ0KPg0KPg0KPg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Sat Jul 5 00:03:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5051A035D for ; Sat, 5 Jul 2014 00:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yz3Hn3nZyit for ; Sat, 5 Jul 2014 00:03:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523651A035C for ; Sat, 5 Jul 2014 00:03:02 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sat, 5 Jul 2014 07:03:00 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Sat, 5 Jul 2014 07:03:00 +0000 From: Larry Masinter To: "Joe Hildebrand (jhildebr)" , Mark Baker , Tim Bray Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPlf/UPrUNrMCeDkWqzE2zLswAjpuM2y2AgAAUwoCAAD+5gIADhcYAgABZSgA= Date: Sat, 5 Jul 2014 07:02:58 +0000 Message-ID: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(107046002)(46102001)(106116001)(99396002)(95666004)(50986999)(76176999)(21056001)(4396001)(85306003)(20776003)(77982001)(2656002)(33646001)(87936001)(106356001)(76576001)(85852003)(74316001)(76482001)(101416001)(74502001)(74662001)(86362001)(81542001)(93886003)(31966008)(83322001)(80022001)(66066001)(92566001)(54356999)(99286002)(83072002)(81342001)(79102001)(105586002)(64706001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/JT7xnDOqnDXRKsbYKMt9CPZCLUY Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jul 2014 07:03:04 -0000 VGhlcmUgaXMgYW4gYWR2YW50YWdlIHRvIHVzaW5nIGFwcGxpY2F0aW9uL2pzb24gZm9yIEktSlNP Tg0KYmVjYXVzZSBtYW55IGNvbXBvbmVudHMgY2FuL3Nob3VsZCB0cmVhdCBJLUpTT04gYXMNCkpT T04uICBTbyB0aGVyZSBhY3R1YWxseSBzaG91bGQgYmUgYSB1c2UgY2FzZSB3aGljaA0KTkVFRFMg dGhlIGRpc3RpbmN0aW9uLg0KDQpmb3IgYSBzZXJ2aWNlIHRoYXQgaXMgcHJvZHVjaW5nIEpTT04s IEkgd291bGQgbGlrZSB0byBzYXk6DQoiSWYgeW91IHJlY2VpdmUgYSBtZXNzYWdlIGZyb20gbWUg dGhhdCBpcyBub3Qgc3RyaWN0bHkgSS1KU09OLCBJIHdvdWxkDQpwcmVmZXIgeW91IHRyZWF0IGl0 IGFzIGFuIGVycm9yIG9uIG15IHBhcnQsIGFuZCB0aGVyZWZvcmUgdHJlYXQgbXkgbWVzc2FnZQ0K YXMgaW52YWxpZCwgYmVjYXVzZSBpZiBzb21ldGhpbmcgd2VudCB3cm9uZyBlbm91Z2ggdGhhdCB3 aGF0IEkgc2VudCB5b3UNCndhc24ndCB2YWxpZCBJLUpTT04gbXkgc2VydmVyIHJvb20gaXMgbGlr ZWx5IG9uIGZpcmUuIg0KDQpJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgSSBjYW4ndCB0aGluayBv ZiBhIHNpdHVhdGlvbg0Kd2hlcmUgeW91IHdvdWxkbid0IGFsc28gd2FudCB0byB2YWxpZGF0ZSBv dGhlciBjb25zdHJhaW50cw0KYXMgd2VsbC4gDQoNCg0KDQoNCg0K From nobody Sat Jul 5 21:48:40 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B751A01A9 for ; Sat, 5 Jul 2014 21:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.697 X-Spam-Level: X-Spam-Status: No, score=-12.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69QoCeo1kQYS for ; Sat, 5 Jul 2014 21:48:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA9E1A019A for ; Sat, 5 Jul 2014 21:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1404622115; x=1405831715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=POwb2lYth/hVhNFIDnyTQmwsy0NUWiD+waVD9xRBptg=; b=emZwG5kCuNvHjL0EjlNEYQBXoThKbrxzxQ78NKD7C/NgE/0ojmU8ypGe NlcaOFNyYS+keYY4+I7/CRWJqYivawuWpSrjucwef+NxHwJfAfdR7HmTC YL1dWCCncHQSWYKJrIFPAN7Lt9uA2w1ZQ2c/4sxYaWmD+isWJBLVF5yN6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAOjTuFOtJV2a/2dsb2JhbABagw6BLIJvwXmBQwEZcRZ1hAQBAQQjEUUQAgEIGgImAgICMBUQAgQBDQWIQrAWmVUXgSyNQzMHgneBTAEEmnaUDINDgXAkHA X-IronPort-AV: E=Sophos;i="5.01,610,1400025600"; d="scan'208";a="337954278" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jul 2014 04:48:34 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s664mYZE030486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Jul 2014 04:48:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sat, 5 Jul 2014 23:48:33 -0500 From: "Joe Hildebrand (jhildebr)" To: Larry Masinter , Mark Baker , "Tim Bray" Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPli3TeLKmyOx7w0yav7qrcKonZpuQpE0AgADBdgCAAQgygA== Date: Sun, 6 Jul 2014 04:48:33 +0000 Message-ID: References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.226.107] Content-Type: text/plain; charset="utf-8" Content-ID: <1AC291DB0FAA694CAD949D9A4CC90517@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/g2zxsts6Jdt2gFFF6JUhxbwqj_4 Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jul 2014 04:48:37 -0000 T24gNy81LzE0LCAxOjAyIEFNLCAiTGFycnkgTWFzaW50ZXIiIDxtYXNpbnRlckBhZG9iZS5jb20+ IHdyb3RlOg0KDQo+SW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIEkgY2FuJ3QgdGhpbmsgb2YgYSBz aXR1YXRpb24NCj53aGVyZSB5b3Ugd291bGRuJ3QgYWxzbyB3YW50IHRvIHZhbGlkYXRlIG90aGVy IGNvbnN0cmFpbnRzDQo+YXMgd2VsbC4NCg0KSSB0aGluayB0aGUgaW1wbGljYXRpb24gb2YgdXMg cHVibGlzaGluZyBJLUpTT04gYXQgYWxsIGlzIHRoYXQgdGhlcmUgYXJlDQptYW55IHBlb3BsZSB0 aGF0IG1pZ2h0IHdhbnQgdG8gc3RhcnQgd2l0aCB0aGlzIHNldCBvZiBjb25zdHJhaW50cy4gIElm IHdlDQpkb24ndCB0aGluayB0aGF0IGlzIHRoZSBjYXNlLCB3ZSBzaG91bGRuJ3QgcHVibGlzaCB0 aGUgZG9jIGFzIGFuIFJGQy4NCk5vbmUgb2YgdGhlIEktSlNPTiBjb25zdHJhaW50cyBhcmUgZG9t YWluLXNwZWNpZmljLCB1bmxpa2UgbW9zdCBvZiB0aGUNCm90aGVyIGNvbnN0cmFpbnRzIHlvdSB3 aWxsIHdhbnQgdG8gY2hlY2suDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Sat Jul 5 22:13:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1FD1A01CB for ; Sat, 5 Jul 2014 22:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOQn1wqdS5ZP for ; Sat, 5 Jul 2014 22:12:57 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880651A01C6 for ; Sat, 5 Jul 2014 22:12:57 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so2835277veb.40 for ; Sat, 05 Jul 2014 22:12:56 -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=Io/PmL6cDmXGtBoXVr99zYoDUsOUKZmHv8H57nV2wnk=; b=H3CPmXf3zL3rhv13aAqnBNyaWRddiU4YU9TjMSWKwYavhO5WqxQlUiCUQbJKtVtd+t aIf0700BUYkkPiCgBWzj7Z/mMWeZ3369WAlHpXF7WCc5ao5TONhsVVDlzq0dz7dfqOZp cN02dVKHvg37e35hwV+s4Y4dEhGDgtlsIX1zp4FT8v2+L1KaC0Hzal7KBlNCGRCVFNRv ARvQjuqbLEqtiCjLHTyHCGY/vXP7Gb3mfKEUQusMnT5SAB4W7VIRguspB75qRhrOQSdc kBcLhpecEUr4reG82kCGyHJkQu3OFZ5OJERQSnUR158unce6WhHA01WFPup/tl5/KAz3 7nIg== X-Gm-Message-State: ALoCoQkX1vQdfX7juuQVIN0xkyM9HLv5vwOjJo2DJk3Vq4EEY53hw3COhbeUODeR5Z3Rw+H1H+1y MIME-Version: 1.0 X-Received: by 10.52.84.162 with SMTP id a2mr16269330vdz.23.1404623576633; Sat, 05 Jul 2014 22:12:56 -0700 (PDT) Received: by 10.221.49.199 with HTTP; Sat, 5 Jul 2014 22:12:56 -0700 (PDT) X-Originating-IP: [24.84.235.32] Received: by 10.221.49.199 with HTTP; Sat, 5 Jul 2014 22:12:56 -0700 (PDT) In-Reply-To: References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> Date: Sat, 5 Jul 2014 22:12:56 -0700 Message-ID: From: Tim Bray To: Joe Hildebrand Content-Type: multipart/alternative; boundary=001a11368f565426d504fd7f6911 Archived-At: http://mailarchive.ietf.org/arch/msg/json/FHAPzNuHaPQ-JaxPJ5adQIuoU20 Cc: Mark Baker , Phillip Hallam-Baker , Larry Masinter , json@ietf.org Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jul 2014 05:12:58 -0000 --001a11368f565426d504fd7f6911 Content-Type: text/plain; charset=UTF-8 So, question: Is there anyone else who agrees with Mark's original argument that there ought to be a Media type for i-json. I wouldn't be wildly against it, but frankly can't see much of a practical upside. On Jul 5, 2014 9:48 PM, "Joe Hildebrand (jhildebr)" wrote: > On 7/5/14, 1:02 AM, "Larry Masinter" wrote: > > >In this particular case, I can't think of a situation > >where you wouldn't also want to validate other constraints > >as well. > > I think the implication of us publishing I-JSON at all is that there are > many people that might want to start with this set of constraints. If we > don't think that is the case, we shouldn't publish the doc as an RFC. > None of the I-JSON constraints are domain-specific, unlike most of the > other constraints you will want to check. > > -- > Joe Hildebrand > > > > --001a11368f565426d504fd7f6911 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, question: Is there anyone else who agrees with Mark'= s original argument that there ought to be a Media type for i-json. I would= n't be wildly against it, but frankly can't see much of a practical= upside.

On Jul 5, 2014 9:48 PM, "Joe Hildebrand (jh= ildebr)" <jhildebr@cisco.com<= /a>> wrote:
On 7/5/14, 1:02 AM, "Larry Masinter" <masinter@adobe.com> wrote:

>In this particular case, I can't think of a situation
>where you wouldn't also want to validate other constraints
>as well.

I think the implication of us publishing I-JSON at all is that there are many people that might want to start with this set of constraints. =C2=A0If= we
don't think that is the case, we shouldn't publish the doc as an RF= C.
None of the I-JSON constraints are domain-specific, unlike most of the
other constraints you will want to check.

--
Joe Hildebrand



--001a11368f565426d504fd7f6911-- From nobody Sun Jul 6 12:45:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3789C1A0A84 for ; Sun, 6 Jul 2014 12:45:33 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM2anTBtmgIF for ; Sun, 6 Jul 2014 12:45:31 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C306B1A03D8 for ; Sun, 6 Jul 2014 12:45:31 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id bj1so4274264pad.37 for ; Sun, 06 Jul 2014 12:45:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R6ilyaHLA+WA1pR08uMAEAxQmJR5FnyzsmrbrAfSi00=; b=cPQskt7F+mZTGiiv+hGgxJs838jmNetQA/UBY4RxlOgb0Q1yICSy8YtoQyzX8Sikg6 FkHHvD6sOFjjiDyI5xH5AMIHlPcrVXs8Yupd876ggcz2m+Ov+UYO0fJdO9YjoqtzSWie sEWyd7bOuor0c2436Rv9+CEGJIbR+zA/XsVXzJwNBWzxU6TKvynwwy5SISwQOU3ZlL9C CPOcOKGDYP3TLHASWn64Qs1Pk1tDHRCjLvw47GTmS12qJfOhlKwiXjbOZJFQJ5c0wy7j sH1vWscdrWDIuZJ9oL3XwPuTEd9tA13wRFYOc4WPDoM6npOqWjdYcDVJu5tw+lGy8F/w GOsg== X-Gm-Message-State: ALoCoQmMhBM51X3p1pdThebaKYhITh9BNlrXX1LcSVpzen7JSMGOlQv2oVmW3hxZcHYsmkaAZCTv MIME-Version: 1.0 X-Received: by 10.67.30.130 with SMTP id ke2mr24526026pad.44.1404675931296; Sun, 06 Jul 2014 12:45:31 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.91.108 with HTTP; Sun, 6 Jul 2014 12:45:31 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: Date: Sun, 6 Jul 2014 15:45:31 -0400 X-Google-Sender-Auth: BqIBwYDt-hGs303xl7SdQF5CQT0 Message-ID: From: Mark Baker To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ilDIdgx4AtW1__I_OrgVOm2Mk8w Cc: Phillip Hallam-Baker , Tim Bray , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 06 Jul 2014 19:45:33 -0000 On Fri, Jul 4, 2014 at 9:30 PM, Joe Hildebrand (jhildebr) wrote: > There are times when, in the documentation for a service that is producing > JSON, I would like to say: > > "If you receive a message from me that is not strictly I-JSON, I would > prefer you treat it as an error on my part, and therefore treat my message > as invalid, because if something went wrong enough that what I sent you > wasn't valid I-JSON my server room is likely on fire." Other than pre-arranging that with the human behind "you", the only existing way to achieve that goal is to use a new media type. Also, creating an I-JSON specific media type doesn't mean that I-JSON can't be delivered as application/json (or application/*+json). It just makes I-JSON useful in more situations IMO, like this one. From nobody Sun Jul 6 22:35:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8173D1A0AEF for ; Sun, 6 Jul 2014 22:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZDLPNV3p1nq for ; Sun, 6 Jul 2014 22:35:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E548E1A0640 for ; Sun, 6 Jul 2014 22:35:08 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 9432E26C069 for ; Sun, 6 Jul 2014 22:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=U/fApWBeAOcVuEQ0YXTP 3gNhH/Y=; b=Wy0OoTfSS5mp9qPZYUQxu9hOxC/Go/W9rgnyvJF/ZvY6+hBRuS4x LK28kHxGBogebESkfzh9LV+SD0W3kzPkRQBdg+vZ9Jc2Ae4r+PYV8fRNYrqvSQEP 7zA3BUUNuExyiEaRribM9hnTqA5h9i+6c2c91XwpmRFJW0ANUflABR4= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 4584F26C063 for ; Sun, 6 Jul 2014 22:35:08 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so6040568wiw.11 for ; Sun, 06 Jul 2014 22:35:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.84.7 with SMTP id u7mr73296921wiy.1.1404711306910; Sun, 06 Jul 2014 22:35:06 -0700 (PDT) Received: by 10.216.29.201 with HTTP; Sun, 6 Jul 2014 22:35:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Jul 2014 00:35:06 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/06EIvJbKkbSxH-rcveTDbVg305s Cc: Mark Baker , Phillip Hallam-Baker , Tim Bray , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 05:35:09 -0000 On Fri, Jul 4, 2014 at 8:30 PM, Joe Hildebrand (jhildebr) wrote: > There are times when, in the documentation for a service that is producing > JSON, I would like to say: > > "If you receive a message from me that is not strictly I-JSON, I would > prefer you treat it as an error on my part, and therefore treat my message > as invalid, because if something went wrong enough that what I sent you > wasn't valid I-JSON my server room is likely on fire." Shades of "secure bit". This is not appropriate for a protocol, IMO. Nico -- From nobody Sun Jul 6 22:40:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93E51A0AF6 for ; Sun, 6 Jul 2014 22:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9njLiiykS6H for ; Sun, 6 Jul 2014 22:40:30 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id CB2D61A0640 for ; Sun, 6 Jul 2014 22:40:29 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id C515932E02B; Mon, 7 Jul 2014 14:40:28 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1a6e_6deb_0749516a_73ef_4e18_b578_f2bde55d762c; Mon, 07 Jul 2014 14:40:28 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 12110BF4E7; Mon, 7 Jul 2014 14:40:28 +0900 (JST) Message-ID: <53BA32BA.4020205@it.aoyama.ac.jp> Date: Mon, 07 Jul 2014 14:40:10 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Bray , "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Wpax7ta-Smv3ZJkOqJgHTTDK3Us Cc: Mark Baker , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 05:40:32 -0000 On 2014/07/05 11:04, Tim Bray wrote: > So, would an I-JSON media type help in producing the desired effect? No= t > obvious to me. In practice, I=E2=80=99m supposing that if I=E2=80=99m = writing a consumer > for JIP (Joe=E2=80=99s Internet Protocol) I=E2=80=99d toggle my JSON pa= rser into I-JSON > mode because I know that=E2=80=99s what the RFC said. I fully agree here. They way I see it, there would then be a media type=20 for JIP, which e.g. could be application/jip+json. The JIP RFC would say=20 that JIP uses I-JSON, and receivers that had a choice would toggle as=20 explained above. But still the +json suffix would mean that the=20 documents could take advantage of generic JSON processing (whatever that=20 is). Another way to express this is to say that in as far as there is a JSON=20 'ecosystem', it would be a bad idea to try and split that ecosystem into=20 two (JSON and I-JSON) at the top. Regards, Martin. > On Fri, Jul 4, 2014 at 6:30 PM, Joe Hildebrand (jhildebr) < > jhildebr@cisco.com> wrote: > >> There are times when, in the documentation for a service that is produ= cing >> JSON, I would like to say: >> >> "If you receive a message from me that is not strictly I-JSON, I would >> prefer you treat it as an error on my part, and therefore treat my mes= sage >> as invalid, because if something went wrong enough that what I sent yo= u >> wasn't valid I-JSON my server room is likely on fire." >> >> >> On 7/2/14, 1:42 PM, "Mark Baker" wrote: >> >>> On Wed, Jul 2, 2014 at 11:54 AM, Tim Bray wrot= e: >>>> I=E2=80=99ll say that just on Web-architectural grounds, I think dis= tinct data >>>> formats should have distinct Internet Media Types, and so it bothers= me >>>> that >>>> we don=E2=80=99t have one for i-json. But the WG couldn=E2=80=99t p= erceive any real >>>> value >>>> in having one that=E2=80=99s distinct from JSON=E2=80=99s and I didn= =E2=80=99t have a >>>> forceful-enough argument to move the consensus on this. >>> >>> Were there driving use cases behind I-JSON? I could imagine a >>> (atypical) scenario where it's used as a "publishing profile", >>> defining a best practice for publishers (Postel-ian style), with no >>> regard for what happens once it's consumed. You wouldn't need to say >>> anything about media types then. >>> >>> But if you want to be able to exchange I-JSON over the Web or >>> Internet, so that recipients know, e.g., not to add duplicate keys, >>> then that can only practically be indicated with a new media type. >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>> >> >> >> -- >> Joe Hildebrand >> >> >> >> > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Jul 7 07:41:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2AC1A013B for ; Mon, 7 Jul 2014 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_PZWd2-OZbr for ; Mon, 7 Jul 2014 07:40:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C655E1A011C for ; Mon, 7 Jul 2014 07:40:58 -0700 (PDT) Received: from Vostro3500 ([77.119.131.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LyS5K-1WZnfC1V26-015tyD; Mon, 07 Jul 2014 16:40:48 +0200 From: "Markus Lanthaler" To: "'Tim Bray'" , "'Joe Hildebrand'" References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: Date: Mon, 7 Jul 2014 16:40:45 +0200 Message-ID: <043801cf99f1$7165f8b0$5431ea10$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK1vLPhXwGnaN3t5HsVsgHOd3w9pAIkr+2RAleRoPACU9Td8QF5qzZNAYPjlbIBFJLU2AGaPkitmWSEfNA= Content-Language: de X-Provags-ID: V03:K0:MbF/u9s1UnAov01gkC0yjJejYrkqI0wpzDkhPm13+dhvWCORChI UoDIZfrHEAA+9X23La5m5FfYyayXJUOIazZFn8BRpkf6dmoucc2GF/JebNSrCEVTt0BIvZ9 mOL6rbM2/7RQl/qbnbKMkeKFeMCaK0G5b5IcqOEmvNqdbAoQGhIyeBLshCP1A6CgM8DIjnP froUPTpvpNoQP0KsxCqSw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/a3T-vr4XvSrVIL-TaT0l_vHFlnw Cc: json@ietf.org, 'Mark Baker' , 'Phillip Hallam-Baker' , 'Larry Masinter' Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 14:41:00 -0000 On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: > So, question: Is there anyone else who agrees with Mark's original > argument that there ought to be a Media type for i-json. I wouldn't > be wildly against it, but frankly can't see much of a practical = upside. I don't think it makes much sense to define a separate media type for = i-json and even less a media type suffix. It *might*, however, make = sense to mint a profile URI as defined by RFC6906 [1] for i-json and = register it according RFC7284 [2]. Cheers, Markus For your convenience, the links to the two RFCs: [1] http://tools.ietf.org/html/rfc6906 [2] http://tools.ietf.org/html/rfc7284 -- Markus Lanthaler @markuslanthaler From nobody Mon Jul 7 07:50:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A231A01E1 for ; Mon, 7 Jul 2014 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUDiR5CTgKA8 for ; Mon, 7 Jul 2014 07:49:41 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2151A0208 for ; Mon, 7 Jul 2014 07:49:41 -0700 (PDT) Received: from fixed-cust.46.62.202.213.quicknet.ch ([213.202.62.46] helo=dretair11.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1X4AEY-0006rJ-Gn; Mon, 07 Jul 2014 07:49:36 -0700 Message-ID: <53BAB379.3040506@berkeley.edu> Date: Mon, 07 Jul 2014 16:49:29 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Markus Lanthaler , 'Tim Bray' , 'Joe Hildebrand' References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> In-Reply-To: <043801cf99f1$7165f8b0$5431ea10$@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/B38UZv-lYISXPwJ28LaEeQSxzlI Cc: 'Mark Baker' , 'Phillip Hallam-Baker' , 'Larry Masinter' , json@ietf.org Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 14:49:46 -0000 hello markus. On 2014-07-07, 16:40, Markus Lanthaler wrote: > On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: >> So, question: Is there anyone else who agrees with Mark's original >> argument that there ought to be a Media type for i-json. I wouldn't >> be wildly against it, but frankly can't see much of a practical upside. > I don't think it makes much sense to define a separate media type for i-json and even less a media type suffix. It *might*, however, make sense to mint a profile URI as defined by RFC6906 [1] for i-json and register it according RFC7284 [2]. that would have made a lot of sense if JSON had chosen to support profiles in its recently published update, which it unfortunately didn't. i guess the problem now is that there is no agreed-upon way how profiles are signaled in JSON, which makes the profile mechanism only moderately useful. but i still agree that it would be useful to include such a profile URI for I-JSON in the spec, so that JSON-based formats that have an agreed-upon way of signaling profiles can use it. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Mon Jul 7 08:28:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159611A0305 for ; Mon, 7 Jul 2014 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO5yminzh3vv for ; Mon, 7 Jul 2014 08:28:00 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB3B1A0296 for ; Mon, 7 Jul 2014 08:27:59 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so5568581pde.3 for ; Mon, 07 Jul 2014 08:27:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v1h+ZXotjM4BPCkg1VGPc5F7XF5d4Chc6OUzpeTCjJY=; b=QgQFw3e5nv3X7pMAGPyIeA/Vam3FBdV7UX+eI2J5gqjmumZVbk4xKOJiW81uK7CWa3 JV1dAAFAuL1wH30okUhiZvhE6eGivYu7tXrvgLZ+3F9XSJI51EsbGMyhdzC/HBHGJyIL wZz+pkPtJQ3UJHsN6lrsbM+uFtAO0RUWFTf3NGqD1IifCk4NHvvFTmWzYLhXm/4i0tHV col/S/nEu6ZNQaRjszzKefQz9/U/A7QSCi2wYVp2tUxm9ZjZiiuBI/D5HoNYHCoIw6b+ 9MuaxSYuQAihe1N3GRjwvTrJI1tzKae2H15caP/dGt7wVyNKjU4Z6o4SF8t3Bd/HaWBd 8lGQ== X-Gm-Message-State: ALoCoQkW0GMAVW/jXSYWLt4VgEqXyo/Oo5+IrLMD1l1LhLMULjA7w0M3Psnje/RK/hof1GC4VKPA MIME-Version: 1.0 X-Received: by 10.70.35.65 with SMTP id f1mr28927595pdj.85.1404746879630; Mon, 07 Jul 2014 08:27:59 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.91.108 with HTTP; Mon, 7 Jul 2014 08:27:59 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: <043801cf99f1$7165f8b0$5431ea10$@gmx.net> References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> Date: Mon, 7 Jul 2014 11:27:59 -0400 X-Google-Sender-Auth: G2NBHSZwuH9RcII8jfMdz0YMQpw Message-ID: From: Mark Baker To: Markus Lanthaler Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/M1QCSrB0020hSnigXGvDA9al0ts Cc: JSON WG , Phillip Hallam-Baker , Tim Bray , Joe Hildebrand , Larry Masinter Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 15:28:01 -0000 On Mon, Jul 7, 2014 at 10:40 AM, Markus Lanthaler wrote: > On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: >> So, question: Is there anyone else who agrees with Mark's original >> argument that there ought to be a Media type for i-json. I wouldn't >> be wildly against it, but frankly can't see much of a practical upside. > > I don't think it makes much sense to define a separate media type for i-json and even less a media type suffix. Whether a I-JSON media type is required or not depends entirely on the use cases for I-JSON's existence. The only use case I've seen, from Joe, suggests a new media type would have some utility. But then others reject that use case. When I hear "a separate media type isn't needed", to me that means that I-JSON is to be used - and published - as a strict subset of JSON, aka it will not be part of the protocol spoken by Web clients and servers. One implication is that an I-JSON-unaware client/intermediary could consume some I-JSON, and e.g. add content with a duplicate key, then process and/or republish as non-I-JSON JSON. If the group doesn't consider that a problem, then great, you don't need a new media type. If it does, then you do. I hope it's clear that I'm not arguing for or against a media type any more. I'm just trying to tease out of the group the criteria that would permit a principled decision to be made. > It *might*, however, make sense to mint a profile URI as defined by RFC6906 [1] for i-json and register it according RFC7284 [2]. Don't go there. Those kinds of profiles have never worked in their many, many guises. Mark. From nobody Mon Jul 7 08:36:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE71A0183 for ; Mon, 7 Jul 2014 08:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQy1QfGPiLhI for ; Mon, 7 Jul 2014 08:36:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E621A0303 for ; Mon, 7 Jul 2014 08:36:12 -0700 (PDT) Received: from Vostro3500 ([77.119.131.246]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M7m0a-1Wi5ju2wCG-00vPRq; Mon, 07 Jul 2014 17:36:03 +0200 From: "Markus Lanthaler" To: "'Erik Wilde'" , "'Tim Bray'" , "'Joe Hildebrand'" References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> <53BAB379.3040506@berkeley.edu> In-Reply-To: <53BAB379.3040506@berkeley.edu> Date: Mon, 7 Jul 2014 17:36:00 +0200 Message-ID: <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK1vLPhXwGnaN3t5HsVsgHOd3w9pAIkr+2RAleRoPACU9Td8QF5qzZNAYPjlbIBFJLU2AGaPkitAXX2iJsCntggdplD7Qtw Content-Language: de X-Provags-ID: V03:K0:5lyAorjeuBe/8v5FKwVU8inbuN80Dot4+3zgpOM94p7KhMCJss1 tYEva/Xm8qJ68NvA7p/cAcDJ8UHXvIZ3/RMEQXOpqRylPoLItj6NTsVi6rCsDrAJrEBPIIE N1Ey6kaQ7JiwfQyIs3k14T9DLEsXUGX9sFpnGR/dzPiyMDQl17wmAO/ZMpzGewMJddZ/r9c RR/b7+hYS9ZnkCccyUCWQ== Archived-At: http://mailarchive.ietf.org/arch/msg/json/_VwHqOgb-K3wi5SRIKcD8INpNPg Cc: json@ietf.org, 'Mark Baker' , 'Phillip Hallam-Baker' , 'Larry Masinter' Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 15:36:14 -0000 On 7 Jul 2014 at 16:49, Erik Wilde wrote: > hello markus. > > On 2014-07-07, 16:40, Markus Lanthaler wrote: >> On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: >>> So, question: Is there anyone else who agrees with Mark's original >>> argument that there ought to be a Media type for i-json. I wouldn't >>> be wildly against it, but frankly can't see much of a practical upside. >> >> I don't think it makes much sense to define a separate media type for i-json >> and even less a media type suffix. It *might*, however, make sense to mint >> a profile URI as defined by RFC6906 [1] for i-json and register it according >> RFC7284 [2]. > > that would have made a lot of sense if JSON had chosen to support > profiles in its recently published update, which it unfortunately > didn't. You mean adding a "profile" media type parameter, right? I don't really know what the process is but I think now that json-bis was published as an RFC (it was out of scope for that work), the JSON WG could re-register the media type and add such a parameter > i guess the problem now is that there is no agreed-upon way how > profiles are signaled in JSON, which makes the profile mechanism only > moderately useful. The server can signal it to the client using an HTTP Link header using the "profile" link relation. What's currently not possible, is for the client to request i-json instead of json from the server. I don't think that's a big problem in practice though as I don't expect a server to support both i-json and json at the same time anyway. > but i still agree that it would be useful to include > such a profile URI for I-JSON in the spec, so that JSON-based formats > that have an agreed-upon way of signaling profiles can use it. Minting and registering such a URI is extremely cheap and has no negative side effects I can think of. We can figure out later if we need to do more (e.g. adding a profile parameter to application/json). Cheers, Markus -- Markus Lanthaler @markuslanthaler From nobody Mon Jul 7 08:53:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C1F1A02FE for ; Mon, 7 Jul 2014 08:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdYgz7uA747p for ; Mon, 7 Jul 2014 08:53:18 -0700 (PDT) Received: from nm4-vm4.bullet.mail.ir2.yahoo.com (nm4-vm4.bullet.mail.ir2.yahoo.com [212.82.96.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99861A0166 for ; Mon, 7 Jul 2014 08:53:17 -0700 (PDT) Received: from [212.82.98.125] by nm4.bullet.mail.ir2.yahoo.com with NNFMP; 07 Jul 2014 15:53:15 -0000 Received: from [46.228.39.64] by tm18.bullet.mail.ir2.yahoo.com with NNFMP; 07 Jul 2014 15:53:15 -0000 Received: from [127.0.0.1] by smtp101.mail.ir2.yahoo.com with NNFMP; 07 Jul 2014 15:53:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1404748395; bh=5AcKqNcKof09zdiRN3rCQVFkulv6cnqbABvx+blgPak=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=6IJ7N+wnVL9IsA1XkDN0xczorire5xzpRp20GtCeUjPbkK4p/8h95u2vyihYWE9jNfW0ZppMafuz+j6hN6V1aB7bWYSD5Ntq3z3QB705jpBa4KnTepVuZQy14u+cqWyaGqRJPAo2y+PT8S56glElp4PfiSHY5iFI7rdkHMvogBY= X-Yahoo-Newman-Id: 726161.62927.bm@smtp101.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cDkWI68VM1kL7rCt8uETpmIZge9WXZbpESki4DTV2zgnHlF VB55S2bzLq4tGgEpwcZ5qteJbVbsmjzLmfNBIbjpp56nzieDcEh5cW.B8B_F aoNxXlGWEv4V1E.UyrWysbLmE5xmvNdyYiMx2oLBd2xKKfdH0.OQfz.s9Pgs mKTnVrJi5QtpIOliuYMDLbp_BSl8jYqU28Ra4VKg0ouX.rEDkTJRYOCNQTSp _pQRllTYX4MimSIkUOFfBkUpHEFO9wrq69dwvXBCgV61Z03nq74MTgpfEgSO 9aLHZHOUmrWVKfjlvu1Az9Yemc14Icj2greWau7CBEstOXvRqUdY4zgi1Co0 doE.ICRQG68V.CVpv.G0Sp11wlQE0fd_Os9T4wDf05Ygqrvcg.4hihgW3I4B sG9vGrxNtYJXmPRcy.J067e4c3RAnDo9PmQU.KqXVhadBnL_WRUA4X.AJtZA 4eY3CViv4ge89Gd_yKNIf9JfNdGsILK8zuhMiYLv9Gbv7XonGzt55o6H8jq7 rDqV0uIP0trXm_vcqrj6BLEk8zw7kf91HgCYP4PaiEyaYKjb98jqowKRByFS JY7Ep9cw2lIUG0GVhIuRbz1I3.K1TIn1QM0tuOq3UmukWE12ZoxqfhIjtM7d qjujenkqvFgTycwJq4z25_VQoLStojbVcyBd7rtDEGsCoqobZEgd5K4KbRi_ uMh3c08AfrBFkAUGYiaUSETruTXUvJN.x8Im35Ua75vnD.mjw1fPU0GjHhpF 1DKKN6UlnhVxbK9Hr7GD8oA-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- X-Rocket-Received: from mail-wg0-f47.google.com (mamund@74.125.82.47 with plain [188.125.68.56]) by smtp101.mail.ir2.yahoo.com with SMTP; 07 Jul 2014 15:53:15 +0000 UTC Received: by mail-wg0-f47.google.com with SMTP id l18so1961361wgh.30 for ; Mon, 07 Jul 2014 08:53:14 -0700 (PDT) X-Gm-Message-State: ALoCoQmSpH/OA+nPXPfRQ3sSPQJ/gKpxd4YlfiY998nc4JUGURvRC094af/GbAVDMVKro0TIYGFN X-Received: by 10.180.79.38 with SMTP id g6mr37319388wix.61.1404748394846; Mon, 07 Jul 2014 08:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.79.169 with HTTP; Mon, 7 Jul 2014 08:52:54 -0700 (PDT) In-Reply-To: <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> <53BAB379.3040506@berkeley.edu> <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> From: mike amundsen Date: Mon, 7 Jul 2014 11:52:54 -0400 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=f46d044287f612f89804fd9c7954 Archived-At: http://mailarchive.ietf.org/arch/msg/json/-6iBlrKsIBR_wTdbOoJUTYCsR24 Cc: Mark Baker , Erik Wilde , Phillip Hallam-Baker , JSON WG , Tim Bray , Joe Hildebrand , Larry Masinter Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 15:53:19 -0000 --f46d044287f612f89804fd9c7954 Content-Type: text/plain; charset=UTF-8 we should use media type registration to define well-formedness -- "shannon-message" style we should use profile registration establishing app semantics and validity mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Mon, Jul 7, 2014 at 11:36 AM, Markus Lanthaler wrote: > On 7 Jul 2014 at 16:49, Erik Wilde wrote: > > hello markus. > > > > On 2014-07-07, 16:40, Markus Lanthaler wrote: > >> On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: > >>> So, question: Is there anyone else who agrees with Mark's original > >>> argument that there ought to be a Media type for i-json. I wouldn't > >>> be wildly against it, but frankly can't see much of a practical upside. > >> > >> I don't think it makes much sense to define a separate media type for > i-json > >> and even less a media type suffix. It *might*, however, make sense to > mint > >> a profile URI as defined by RFC6906 [1] for i-json and register it > according > >> RFC7284 [2]. > > > > that would have made a lot of sense if JSON had chosen to support > > profiles in its recently published update, which it unfortunately > > didn't. > > You mean adding a "profile" media type parameter, right? I don't really > know > what the process is but I think now that json-bis was published as an RFC > (it was out of scope for that work), the JSON WG could re-register the > media > type and add such a parameter > > > > i guess the problem now is that there is no agreed-upon way how > > profiles are signaled in JSON, which makes the profile mechanism only > > moderately useful. > > The server can signal it to the client using an HTTP Link header using the > "profile" link relation. What's currently not possible, is for the client > to > request i-json instead of json from the server. I don't think that's a big > problem in practice though as I don't expect a server to support both > i-json > and json at the same time anyway. > > > > but i still agree that it would be useful to include > > such a profile URI for I-JSON in the spec, so that JSON-based formats > > that have an agreed-upon way of signaling profiles can use it. > > Minting and registering such a URI is extremely cheap and has no negative > side effects I can think of. We can figure out later if we need to do more > (e.g. adding a profile parameter to application/json). > > > Cheers, > Markus > > > -- > Markus Lanthaler > @markuslanthaler > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --f46d044287f612f89804fd9c7954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
we should use media type registration to define well-forme= dness -- "shannon-message" style
we should use profile regist= ration establishing app semantics and validity




On Mon, Jul 7, 2014 at 11:36 AM, Markus = Lanthaler <markus.lanthaler@gmx.net> wrote:
On 7 Jul 2014 at 16:49, Erik Wilde wrote:
> hello markus.
>
> On 2014-07-07, 16:40, Markus Lanthaler wrote:
>> On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote:
>>> So, question: Is there anyone else who agrees with Mark's = original
>>> argument that there ought to be a Media type for i-json. I wou= ldn't
>>> be wildly against it, but frankly can't see much of a prac= tical upside.
>>
>> I don't think it makes much sense to define a separate media t= ype for
i-json
>> and even less a media type suffix. It *might*, however, make sense= to
mint
>> a profile URI as defined by RFC6906 [1] for i-json and register it=
according
>> RFC7284 [2].
>
> that would have made a lot of sense if JSON had chosen to support
> profiles in its recently published update, which it unfortunately
> didn't.

You mean adding a "profile" media type parameter, right? I = don't really know
what the process is but I think now that json-bis was published as an RFC (it was out of scope for that work), the JSON WG could re-register the medi= a
type and add such a parameter


> i guess the problem now is that there is no agreed-upon way how
> profiles are signaled in JSON, which makes the profile mechanism only<= br> > moderately useful.

The server can signal it to the client using an HTTP Link header usin= g the
"profile" link relation. What's currently not possible, is fo= r the client to
request i-json instead of json from the server. I don't think that'= s a big
problem in practice though as I don't expect a server to support both i= -json
and json at the same time anyway.


> but i still agree that it would be useful to include
> such a profile URI for I-JSON in the spec, so that JSON-based formats<= br> > that have an agreed-upon way of signaling profiles can use it.

Minting and registering such a URI is extremely cheap and has no nega= tive
side effects I can think of. We can figure out later if we need to do more<= br> (e.g. adding a profile parameter to application/json).


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler



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

--f46d044287f612f89804fd9c7954-- From nobody Mon Jul 7 08:59:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0CB1A0305 for ; Mon, 7 Jul 2014 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D9j01S44dOa for ; Mon, 7 Jul 2014 08:59:42 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C9D1A0266 for ; Mon, 7 Jul 2014 08:59:41 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so7174766wiv.4 for ; Mon, 07 Jul 2014 08:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MAfTKvIc5kL62/74SUObpCGUMynDeGWqfd2ICz53gu8=; b=che37ieQQ9a7wgWuLLYhg9jWSZo+qFT+mxI92QGCtlMYTlcEWzSiOSi4pKSr60bzXK UPq7tXeYMrjNVopC8Cc0sUsSs6tqOp1gAv0ERZWQZCGy8Fmv46fysByiMa5bVNYTdW4b XmZH9n0HOk2OB1CqcF7N3ejvMAInH+2W9ESHEutMKBfdV0yIWR45NFV1WrVNZBG+iSLn IjX7/nC34kKZp4WDKf+y47vfg4BBvs7ccHqfoh6ya+QGqkkGdQ/an8mhKv2DyN5Kp9DE JExWTSFH6mB039lomSH+3HGaT89L1WoacFQY+A/WKTZYP4URWczqsPUMVr3tpf/aAG7L v9pQ== MIME-Version: 1.0 X-Received: by 10.180.97.195 with SMTP id ec3mr38174301wib.13.1404748780362; Mon, 07 Jul 2014 08:59:40 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Mon, 7 Jul 2014 08:59:40 -0700 (PDT) In-Reply-To: <53BAB379.3040506@berkeley.edu> References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> <53BAB379.3040506@berkeley.edu> Date: Mon, 7 Jul 2014 11:59:40 -0400 X-Google-Sender-Auth: IZpbft9kLRJGYZWjoANKp8it9vo Message-ID: From: Phillip Hallam-Baker To: Erik Wilde Content-Type: multipart/alternative; boundary=f46d0443066e0d675d04fd9c9000 Archived-At: http://mailarchive.ietf.org/arch/msg/json/aYlbWUodDWndyjaaPf8Zdob27lk Cc: Mark Baker , Larry Masinter , Tim Bray , Joe Hildebrand , JSON WG , Markus Lanthaler Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 15:59:43 -0000 --f46d0443066e0d675d04fd9c9000 Content-Type: text/plain; charset=UTF-8 Exactly I-JSON is a subset of JSON. We have two choices for I-Json content: 1) Use the content type application/json and not tell the application they are getting I-JSON 2) Use the content type application/i-json and risk having parsers that accept JSON but don't do special processing for I-JSON reject it. I can't see any advantage to choice #2, it risks breaking things for a distinction that does not provide leverage. Now the story for JSON-B is completely different as that is a superset. So even though a I-JSON document will be accepted by a JSON-B parser the reverse is not the case as JSON-B has optional binary encodings. And so in that case it is essential that the application know what the content type is. On Mon, Jul 7, 2014 at 10:49 AM, Erik Wilde wrote: > hello markus. > > > On 2014-07-07, 16:40, Markus Lanthaler wrote: > >> On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote: >> >>> So, question: Is there anyone else who agrees with Mark's original >>> argument that there ought to be a Media type for i-json. I wouldn't >>> be wildly against it, but frankly can't see much of a practical upside. >>> >> I don't think it makes much sense to define a separate media type for >> i-json and even less a media type suffix. It *might*, however, make sense >> to mint a profile URI as defined by RFC6906 [1] for i-json and register it >> according RFC7284 [2]. >> > > that would have made a lot of sense if JSON had chosen to support profiles > in its recently published update, which it unfortunately didn't. i guess > the problem now is that there is no agreed-upon way how profiles are > signaled in JSON, which makes the profile mechanism only moderately useful. > but i still agree that it would be useful to include such a profile URI for > I-JSON in the spec, so that JSON-based formats that have an agreed-upon way > of signaling profiles can use it. > > cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > --f46d0443066e0d675d04fd9c9000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly

I-JSON is a subset of JSON.

We have two choices for I-Json content:
1) Use the content type application/json and not tell the appli= cation they are getting I-JSON

2) Use the content type application/i-json and risk hav= ing parsers that accept JSON but don't do special processing for I-JSON= reject it.

I can't see any advantage to choic= e #2, it risks breaking things for a distinction that does not provide leve= rage.


Now the story for JSON-B is completely d= ifferent as that is a superset. So even though a I-JSON document will be ac= cepted by a JSON-B parser the reverse is not the case as JSON-B has optiona= l binary encodings. And so in that case it is essential that the applicatio= n know what the content type is.=C2=A0





=




On Mon, Jul 7, 2014 at 10:49 AM, Erik Wilde <dret@b= erkeley.edu> wrote:
hello markus.


On 2014-07-07, 16:40, Markus Lanthaler wrote:
On Sunday, July 06, 2014 7:13 AM, Tim Bray wrote:
So, question: Is there anyone else who agrees with Mark's original
argument that there ought to be a Media type for i-json. I wouldn't
be wildly against it, but frankly can't see much of a practical upside.=
I don't think it makes much sense to define a separate media type for i= -json and even less a media type suffix. It *might*, however, make sense to= mint a profile URI as defined by RFC6906 [1] for i-json and register it ac= cording RFC7284 [2].

that would have made a lot of sense if JSON had chosen to support profiles = in its recently published update, which it unfortunately didn't. i gues= s the problem now is that there is no agreed-upon way how profiles are sign= aled in JSON, which makes the profile mechanism only moderately useful. but= i still agree that it would be useful to include such a profile URI for I-= JSON in the spec, so that JSON-based formats that have an agreed-upon way o= f signaling profiles can use it.

cheers,

dret.

--
erik wilde | mailto:= dret@berkeley.edu =C2=A0- =C2=A0tel:+1-510-2061079 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley =C2=A0- =C2=A0School= of Information (ISchool) |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://twitter.com/dret |

--f46d0443066e0d675d04fd9c9000-- From nobody Mon Jul 7 13:57:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079EF1B2906 for ; Mon, 7 Jul 2014 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T_gOMjBcLY8 for ; Mon, 7 Jul 2014 13:57:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5398C1B28E9 for ; Mon, 7 Jul 2014 13:57:48 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s67Kvkt2005440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 7 Jul 2014 13:57:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 7 Jul 2014 13:57:45 -0700 To: IETF JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/-F7LuWSfx4O9LFEE4xC4edpdaFQ Subject: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 20:57:49 -0000 Greetings again. There is still disagreement in the WG about what the = text separator should be for draft-ietf-json-text-sequence. The current = draft, draft-ietf-json-text-sequence-04, specifies it as the LF = character, and gives rationale for that decision in Section 2.2. Many = people in the WG have expressed a preference for a different character, = one that would not require any stripping from the normal whitespace that = can exist inside the JSON text. There were many suggestions for such a = different character; the one that seemed most favored was the ASCII = record separator (RS) character, U+001e. In order to simplify the decision, I'd like to ask a few simple = questions: - Do you feel that the protocol will be significantly broken if it uses = LF as the text separator? - Do you feel that the protocol will be significantly broken if it uses = RS as the text separator? - Do you feel that using LF or RF as the text separator is essentially = the same for the protocol? Answers of "yes", "no", and "don't know" are most appreciated. = Explanation of a "yes" and "no" are probably not helpful at this time = because they are likely to cause the thread to go off into discussion of = the explanation, not of the questions. Wearing my chair hat, I'm not sure how I will respond depending on = different patterns in the results. Let's answer the questions and then = see what we think it means. --Paul Hoffman= From nobody Mon Jul 7 16:30:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D01B2988 for ; Mon, 7 Jul 2014 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98aHG0xnU_QS for ; Mon, 7 Jul 2014 16:30:41 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55941B2983 for ; Mon, 7 Jul 2014 16:30:40 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id db12so205137veb.16 for ; Mon, 07 Jul 2014 16:30:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Z54xjlUwqNCg0zW3ebjAnjyTPPRZ+5t/hl3ciFeVkEU=; b=P2Ao2HD/YbTpPtxhBHZtiDVXjzvW7j0Z+hYgiNf94LcjwoRvvQj+EbCPsdrbCvl5YW YgpgekCmdRoo1oYRTUuKDu0N6Nmdgbo0gPdHJ79BKaBPAVKnwxKzuaT+FKONelqMyStV cURpr3Ychd6GKKzbd4WpF8EdqUu33Vm1iMI28BbDh9gKlfybiu2FIp+3wY/i+7Eg3oKa uwB0+ktE/9MnoequsTT9Cq5R1IyhMtu7d7xfNwpAF2pOuz5Fl/mBP4RAbLYbiGHdUkSj 0e/W6Ywzw7FYvI0oHXPPtTAx5SSNjwPkIOIaNXWSwNkWlW9o91fI3yRp+ZzzMAxo9LWd /FzA== X-Gm-Message-State: ALoCoQlLATvZh3a8ltwt/MmqeiJfr+utysV6VVatCbqN3y6YkGZDqg6YTK0lgy0SVq3hynwSnV2Q X-Received: by 10.52.249.9 with SMTP id yq9mr13280040vdc.6.1404775839994; Mon, 07 Jul 2014 16:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Mon, 7 Jul 2014 16:30:19 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: References: From: Tim Bray Date: Mon, 7 Jul 2014 16:30:19 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0153688ceeaab404fda2dc92 Archived-At: http://mailarchive.ietf.org/arch/msg/json/LFyCT6yIoL-Wcwy-5dZNNtNSuNo Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 23:30:42 -0000 --089e0153688ceeaab404fda2dc92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 7, 2014 at 1:57 PM, Paul Hoffman wrote: > > - Do you feel that the protocol will be significantly broken if it uses L= F > as the text separator? > =E2=80=8BYes=E2=80=8B =E2=80=8B > =E2=80=8B=E2=80=8B > - Do you feel that the protocol will be significantly broken if it uses R= S > as the text separator? > =E2=80=8BNo =E2=80=8B > =E2=80=8B > - Do you feel that using LF or RF as the text separator is essentially th= e > same for the protocol? > =E2=80=8BNo=E2=80=8B, assuming you mean LF or RS. =E2=80=8B=E2=80=8B > > Answers of "yes", "no", and "don't know" are most appreciated. Explanatio= n > of a "yes" and "no" are probably not helpful at this time because they ar= e > likely to cause the thread to go off into discussion of the explanation, > not of the questions. > > Wearing my chair hat, I'm not sure how I will respond depending on > different patterns in the results. Let's answer the questions and then se= e > what we think it means. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e0153688ceeaab404fda2dc92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Mon, Jul 7, 2014 at 1:57 PM, Paul Hoffman <paul.hoffman@vpnc.org&g= t; wrote:

- Do you feel that the protocol will be significantly broken if it uses LF = as the text separator?

=E2=80=8BYes=E2=80=8B
=E2=80=8B
=E2= =80=8B=E2=80=8B
- Do you feel that the protocol will be significantly = broken if it uses RS as the text separator?

=
=E2=80=8BNo
=E2= =80=8B
=E2= =80=8B
- Do you feel that using LF or RF as the text separator is esse= ntially the same for the protocol?

=E2=80=8BNo=E2=80=8B, assuming you mean LF or RS.

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

Answers of "yes", "no", and "don't know" = are most appreciated. Explanation of a "yes" and "no" a= re probably not helpful at this time because they are likely to cause the t= hread to go off into discussion of the explanation, not of the questions.
Wearing my chair hat, I'm not sure how I will respond depending on diff= erent patterns in the results. Let's answer the questions and then see = what we think it means.

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



--
- Tim Bray (If you=E2=80=99d like to send me a priv= ate message, see h= ttps://keybase.io/timbray)
--089e0153688ceeaab404fda2dc92-- From nobody Mon Jul 7 16:43:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61131B298E for ; Mon, 7 Jul 2014 16:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpQ9A-pU4oFY for ; Mon, 7 Jul 2014 16:43:13 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4B1B298C for ; Mon, 7 Jul 2014 16:43:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,621,1399989600"; d="scan'208";a="212202611" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 08 Jul 2014 09:36:09 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="233625231" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 08 Jul 2014 09:43:12 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 8 Jul 2014 09:43:11 +1000 From: "Manger, James" To: Paul Hoffman , IETF JSON WG Date: Tue, 8 Jul 2014 09:43:10 +1000 Thread-Topic: [Json] The text in draft-ietf-json-text-sequence Thread-Index: Ac+aJiAFSw9SX2AIQl6FhPN9pEw23wAFt/3g Message-ID: <255B9BB34FB7D647A506DC292726F6E11549A8F764@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/eP6wcNX2BNXtZNXSdYbbT6opXnE Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 07 Jul 2014 23:43:14 -0000 LSBEbyB5b3UgZmVlbCB0aGF0IHRoZSBwcm90b2NvbCB3aWxsIGJlIHNpZ25pZmljYW50bHkgYnJv a2VuIGlmIGl0IHVzZXMgTEYgYXMgdGhlIHRleHQgc2VwYXJhdG9yPw0KDQpObw0KDQotIERvIHlv dSBmZWVsIHRoYXQgdGhlIHByb3RvY29sIHdpbGwgYmUgc2lnbmlmaWNhbnRseSBicm9rZW4gaWYg aXQgdXNlcyBSUyBhcyB0aGUgdGV4dCBzZXBhcmF0b3I/DQoNClllcw0KDQotIERvIHlvdSBmZWVs IHRoYXQgdXNpbmcgTEYgb3IgUkYgYXMgdGhlIHRleHQgc2VwYXJhdG9yIGlzIGVzc2VudGlhbGx5 IHRoZSBzYW1lIGZvciB0aGUgcHJvdG9jb2w/DQoNCk5vDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Mon Jul 7 18:09:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB31B29B4 for ; Mon, 7 Jul 2014 18:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUJuCfyvuFli for ; Mon, 7 Jul 2014 18:09:54 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id DF45B1B29A9 for ; Mon, 7 Jul 2014 18:09:51 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 3877D32E52E; Tue, 8 Jul 2014 10:09:50 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4814_62fc_26457cb3_61ab_465b_97f1_dd775a16d1b6; Tue, 08 Jul 2014 10:09:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B9970BF53E; Tue, 8 Jul 2014 10:09:49 +0900 (JST) Message-ID: <53BB44CB.5040503@it.aoyama.ac.jp> Date: Tue, 08 Jul 2014 10:09:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman , IETF JSON WG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/edrKmrAupjruaqiiUpikIxld0U0 Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 01:09:56 -0000 On 2014/07/08 05:57, Paul Hoffman wrote: > Greetings again. There is still disagreement in the WG about what the text separator should be for draft-ietf-json-text-sequence. The current draft, draft-ietf-json-text-sequence-04, specifies it as the LF character, and gives rationale for that decision in Section 2.2. Many people in the WG have expressed a preference for a different character, one that would not require any stripping from the normal whitespace that can exist inside the JSON text. There were many suggestions for such a different characte r; > the one that seemed most favored was the ASCII record separator (RS) character, U+001e. > > In order to simplify the decision, I'd like to ask a few simple questions: > > - Do you feel that the protocol will be significantly broken if it uses LF as the text separator? Yes. > - Do you feel that the protocol will be significantly broken if it uses RS as the text separator? Yes. > - Do you feel that using LF or RF as the text separator is essentially the same for the protocol? Yes. > Answers of "yes", "no", and "don't know" are most appreciated. Explanation of a "yes" and "no" are probably not helpful at this time because they are likely to cause the thread to go off into discussion of the explanation, not of the questions. [The above are just a reflection of the fact that I think that this format (it's not really a protocol) is unnecessary and therefore broken from the start, and therefore it's broken with whatever separator there is (except with ',', i.e. simply as a JSON array). The problem of diverging opinions is best solved by abandoning this spec.] Regards, Martin. > Wearing my chair hat, I'm not sure how I will respond depending on different patterns in the results. Let's answer the questions and then see what we think it means. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Jul 7 18:15:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3581B29A9 for ; Mon, 7 Jul 2014 18:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60nDB3jFxJN9 for ; Mon, 7 Jul 2014 18:15:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1841B28BF for ; Mon, 7 Jul 2014 18:15:05 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1X4Jzs-0004ww-2u; Mon, 07 Jul 2014 21:15:04 -0400 Date: Mon, 7 Jul 2014 21:15:04 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20140708011503.GD1447@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/84KMSnpGQngQQYPPo12XdoiHzh4 Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 01:15:08 -0000 Paul Hoffman scripsit: > - Do you feel that the protocol will be significantly broken if it > uses LF as the text separator? No. > - Do you feel that the protocol will be significantly broken if it > uses RS as the text separator? No. > - Do you feel that using LF or RF as the text separator is essentially > the same for the protocol? Yes. (However, it would be bad to allow both.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org First known example of political correctness: After Nurhachi had united all the other Jurchen tribes under the leadership of the Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should be banned, and from then on, they were all to be called Manchus. --S. Robert Ramsey, The Languages of China From nobody Tue Jul 8 04:48:18 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1761B280E for ; Tue, 8 Jul 2014 04:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg2eBLcUhnur for ; Tue, 8 Jul 2014 04:48:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113731B2A68 for ; Tue, 8 Jul 2014 04:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=666; q=dns/txt; s=iport; t=1404820097; x=1406029697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7OYohNkxMZ1XsENFXPzJ+kTuEFA3gZXzm8ayJmGvMJ8=; b=VeIqW3IYS0H/vlr8kYxadHuz0icvypi0Br/HFZKq9MhltWANgJ6q3nfH lxM7BSMkQCcvEHNJi4IAlEk5WfOLOJNdPHWIgcep5f33AfzO9JmilHLI9 /2o9bniniWTY4eCLWlIkiebW2EFVq98UxAqsXtCf/SYIehF+IYyUeZ8NM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMTZu1OtJA2N/2dsb2JhbABZgw6BLIJvw0gBGX0WdYQEAQEEIxFFEAIBCA4MAiYCAgIwFRACBAENBYhCr3OZOheBLI1DMweCd4FMAQSadpQMg0OCMA X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="335357143" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jul 2014 11:48:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s68BmFIK007391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 11:48:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 06:48:15 -0500 From: "Joe Hildebrand (jhildebr)" To: Mark Baker , Markus Lanthaler Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPli3TeLKmyOx7w0yav7qrcKonZgIkr+2RAleRoPACU9Td8QF5qzZNAYPjlbIBFJLU2AGaPkitmWSEfNCBzK9YgIABdnQA Date: Tue, 8 Jul 2014 11:48:14 +0000 Message-ID: References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.147.19.77] Content-Type: text/plain; charset="utf-8" Content-ID: <438263A5BCDCA34CBCE3D883CA5FC28C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/5vQi9bZwuZ69LbL-RVFLgrEhtms Cc: JSON WG , Phillip Hallam-Baker , Tim Bray , Larry Masinter Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 11:48:17 -0000 T24gNy83LzE0LCA1OjI3IFBNLCAiTWFyayBCYWtlciIgPGRpc3RvYmpAYWNtLm9yZz4gd3JvdGU6 DQoNCj5XaGV0aGVyIGEgSS1KU09OIG1lZGlhIHR5cGUgaXMgcmVxdWlyZWQgb3Igbm90IGRlcGVu ZHMgZW50aXJlbHkgb24gdGhlDQo+dXNlIGNhc2VzIGZvciBJLUpTT04ncyBleGlzdGVuY2UuIFRo ZSBvbmx5IHVzZSBjYXNlIEkndmUgc2VlbiwgZnJvbQ0KPkpvZSwgc3VnZ2VzdHMgYSBuZXcgbWVk aWEgdHlwZSB3b3VsZCBoYXZlIHNvbWUgdXRpbGl0eS4gQnV0IHRoZW4NCj5vdGhlcnMgcmVqZWN0 IHRoYXQgdXNlIGNhc2UuDQoNClRvIGJlIGNsZWFyLCBJIHdhc24ndCBzdWdnZXN0aW5nIGEgbWVk aWEgdHlwZSwgYnV0IGFuIGV4cGxpY2l0IGZsYWcgaW4gdGhlDQpwYXJzaW5nIGxpYnJhcnkgdGhh dCBpcyBzZXQgYnkgdGhlIHByb2dyYW1tZXIgYmVjYXVzZSBvZiBwcmlvciBrbm93bGVkZ2UuDQoN Ci0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Jul 8 04:51:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7491B2853 for ; Tue, 8 Jul 2014 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0NBjlCiGOwK for ; Tue, 8 Jul 2014 04:50:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2EB1B2810 for ; Tue, 8 Jul 2014 04:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1560; q=dns/txt; s=iport; t=1404820256; x=1406029856; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=T9aPEm7Du5eD0MHWRcvYh4MJe47uXFZS4eB40TlBq6o=; b=V3/K9U5dEilM3+ea5tBbjTCjyja/uDM9A4seINZGb+AI0moth9MW8Dgz MkazSNM9ZCoKgpMY13bjxEsPZ2Nz/kxjXmbVqitlaE2QpkV6lHLnUlzGa khDmuxsn8hAcGnmykO4Zr5bMn9NHnfA4wwEA/lvZyymC4GYLztDIJPQTJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAAbau1OtJV2P/2dsb2JhbABZgw6BLIJvw0gBGX0WdYQEAQEEIxFVAgEIGgImAgICMBUQAgQBEohCr3OZOheBLI1DOoJ3gUwBBJZchBqUDINDgjA X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="59091422" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 08 Jul 2014 11:50:55 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68BotOf011439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 11:50:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 06:50:55 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , IETF JSON WG Thread-Topic: [Json] The text in draft-ietf-json-text-sequence Thread-Index: AQHPmiYfnAd3ORqBrkmbNTIJ/4t2Z5uWhsqA Date: Tue, 8 Jul 2014 11:50:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.147.19.77] Content-Type: text/plain; charset="utf-8" Content-ID: <2E691393B9AACA42926C52562F8A2166@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/t0Y0c1FTioge4QLcQ44I1k1jYuY Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 11:51:01 -0000 T24gNy83LzE0LCAxMDo1NyBQTSwgIlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkB2cG5jLm9y Zz4gd3JvdGU6DQoNCj5HcmVldGluZ3MgYWdhaW4uIFRoZXJlIGlzIHN0aWxsIGRpc2FncmVlbWVu dCBpbiB0aGUgV0cgYWJvdXQgd2hhdCB0aGUNCj50ZXh0IHNlcGFyYXRvciBzaG91bGQgYmUgZm9y IGRyYWZ0LWlldGYtanNvbi10ZXh0LXNlcXVlbmNlLiBUaGUgY3VycmVudA0KPmRyYWZ0LCBkcmFm dC1pZXRmLWpzb24tdGV4dC1zZXF1ZW5jZS0wNCwgc3BlY2lmaWVzIGl0IGFzIHRoZSBMRg0KPmNo YXJhY3RlciwgYW5kIGdpdmVzIHJhdGlvbmFsZSBmb3IgdGhhdCBkZWNpc2lvbiBpbiBTZWN0aW9u IDIuMi4gTWFueQ0KPnBlb3BsZSBpbiB0aGUgV0cgaGF2ZSBleHByZXNzZWQgYSBwcmVmZXJlbmNl IGZvciBhIGRpZmZlcmVudCBjaGFyYWN0ZXIsDQo+b25lIHRoYXQgd291bGQgbm90IHJlcXVpcmUg YW55IHN0cmlwcGluZyBmcm9tIHRoZSBub3JtYWwgd2hpdGVzcGFjZSB0aGF0DQo+Y2FuIGV4aXN0 IGluc2lkZSB0aGUgSlNPTiB0ZXh0LiBUaGVyZSB3ZXJlIG1hbnkgc3VnZ2VzdGlvbnMgZm9yIHN1 Y2ggYQ0KPmRpZmZlcmVudCBjaGFyYWN0ZXI7IHRoZSBvbmUgdGhhdCBzZWVtZWQgbW9zdCBmYXZv cmVkIHdhcyB0aGUgQVNDSUkNCj5yZWNvcmQgc2VwYXJhdG9yIChSUykgY2hhcmFjdGVyLCBVKzAw MWUuDQo+DQo+SW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGRlY2lzaW9uLCBJJ2QgbGlrZSB0byBh c2sgYSBmZXcgc2ltcGxlIHF1ZXN0aW9uczoNCj4NCj4tIERvIHlvdSBmZWVsIHRoYXQgdGhlIHBy b3RvY29sIHdpbGwgYmUgc2lnbmlmaWNhbnRseSBicm9rZW4gaWYgaXQgdXNlcw0KPkxGIGFzIHRo ZSB0ZXh0IHNlcGFyYXRvcj8NCg0KU29tZXdoYXQuDQoNCj4tIERvIHlvdSBmZWVsIHRoYXQgdGhl IHByb3RvY29sIHdpbGwgYmUgc2lnbmlmaWNhbnRseSBicm9rZW4gaWYgaXQgdXNlcw0KPlJTIGFz IHRoZSB0ZXh0IHNlcGFyYXRvcj8NCg0KTm8uDQoNCj4tIERvIHlvdSBmZWVsIHRoYXQgdXNpbmcg TEYgb3IgUkYgYXMgdGhlIHRleHQgc2VwYXJhdG9yIGlzIGVzc2VudGlhbGx5DQo+dGhlIHNhbWUg Zm9yIHRoZSBwcm90b2NvbD8NCg0KTm8uDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Tue Jul 8 04:55:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E601B2A58 for ; Tue, 8 Jul 2014 04:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYXbgord2xvJ for ; Tue, 8 Jul 2014 04:55:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EBF1B278B for ; Tue, 8 Jul 2014 04:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s68BtO6l023991; Tue, 8 Jul 2014 13:55:24 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD5235E7; Tue, 8 Jul 2014 13:55:23 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Tue, 8 Jul 2014 13:55:23 +0200 X-Mao-Original-Outgoing-Id: 426513322.976739-dc799b406f170e0e01eba031919a7eee Content-Transfer-Encoding: quoted-printable Message-Id: <08517507-216D-4C43-8DE8-AC82CC8A8DEE@tzi.org> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/clmZDutvHFKTwEoDstW-LIrB88s Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 11:55:35 -0000 On 07 Jul 2014, at 22:57, Paul Hoffman wrote: > - Do you feel that the protocol will be significantly broken if it = uses LF as the text separator? Yes. [if =93not very useful=94 counts as =93broken"] > - Do you feel that the protocol will be significantly broken if it = uses RS as the text separator? No. > - Do you feel that using LF or RF as the text separator is essentially = the same for the protocol? No. Gr=FC=DFe, Carsten From nobody Tue Jul 8 05:36:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6441B2827 for ; Tue, 8 Jul 2014 05:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX0moSKF8x5H for ; Tue, 8 Jul 2014 05:36:41 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806401B2823 for ; Tue, 8 Jul 2014 05:36:41 -0700 (PDT) Received: from 77-56-165-193.dclient.hispeed.ch ([77.56.165.193] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1X4UdN-0005RQ-9x; Tue, 08 Jul 2014 05:36:34 -0700 Message-ID: <53BBE5CC.50403@berkeley.edu> Date: Tue, 08 Jul 2014 14:36:28 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Markus Lanthaler , 'Tim Bray' , 'Joe Hildebrand' References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> <53BAB379.3040506@berkeley.edu> <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> In-Reply-To: <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/YS7xRYU-YlXwedsUCEvCX8s6HxU Cc: json@ietf.org, 'Mark Baker' , 'Phillip Hallam-Baker' , 'Larry Masinter' Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 12:36:43 -0000 hello markus. On 2014-07-07, 17:36 , Markus Lanthaler wrote: > On 7 Jul 2014 at 16:49, Erik Wilde wrote: >> On 2014-07-07, 16:40, Markus Lanthaler wrote: >>> I don't think it makes much sense to define a separate media type for > i-json >>> and even less a media type suffix. It *might*, however, make sense to > mint >>> a profile URI as defined by RFC6906 [1] for i-json and register it > according >>> RFC7284 [2]. >> that would have made a lot of sense if JSON had chosen to support >> profiles in its recently published update, which it unfortunately >> didn't. > You mean adding a "profile" media type parameter, right? I don't really know > what the process is but I think now that json-bis was published as an RFC > (it was out of scope for that work), the JSON WG could re-register the media > type and add such a parameter i don't think it was explicitly out of scope, and it was briefly mentioned on this list. i think it just wasn't considered to be important enough. technically speaking, i think you need to re-register the media type with an added profile parameter. http://tools.ietf.org/html/draft-wilde-atom-profile is a draft where i am trying to do this for atom. the idea was that this draft could be used as a template for any media that would like to start supporting profile as a media type parameter (the source is available at http://tools.ietf.org/html/draft-wilde-atom-profile). >> i guess the problem now is that there is no agreed-upon way how >> profiles are signaled in JSON, which makes the profile mechanism only >> moderately useful. > The server can signal it to the client using an HTTP Link header using the > "profile" link relation. What's currently not possible, is for the client to > request i-json instead of json from the server. I don't think that's a big > problem in practice though as I don't expect a server to support both i-json > and json at the same time anyway. you're right, signaling them as RFC5988-style links is always a possibility. >> but i still agree that it would be useful to include >> such a profile URI for I-JSON in the spec, so that JSON-based formats >> that have an agreed-upon way of signaling profiles can use it. > Minting and registering such a URI is extremely cheap and has no negative > side effects I can think of. We can figure out later if we need to do more > (e.g. adding a profile parameter to application/json). yes, and that's the standards argument for using profiles: they are a lightweight way for being more specific about a representation, and they can be ignored (treat the representation as just using the media type), or can be interpreted (assume that the representation follows additional constraints). http://tools.ietf.org/html/rfc6906#section-3.1 cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue Jul 8 10:06:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9921B2B7E for ; Tue, 8 Jul 2014 10:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41spMwlV9s0G for ; Tue, 8 Jul 2014 10:05:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2283B1B2B4A for ; Tue, 8 Jul 2014 10:05:54 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 17:05:53 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 17:05:53 +0000 From: Larry Masinter To: Erik Wilde , Markus Lanthaler , 'Tim Bray' , "'Joe Hildebrand'" Thread-Topic: [Json] Media types, extensibility in draft-ietf-json-i-json-02 Thread-Index: AQHPlf/UPrUNrMCeDkWqzE2zLswAjpuM2y2AgAAUwoCAAD+5gIADhcYAgABZSgCAAXBcgIAABtAAgAIw+oCAAAJxgIAADP8AgAFgLACAAEXXoA== Date: Tue, 8 Jul 2014 17:05:52 +0000 Message-ID: <70b06f398fdb45a1838e77011d6774ff@BL2PR02MB307.namprd02.prod.outlook.com> References: <3b407fff0cc14d5ba291cea58bacac4f@BL2PR02MB307.namprd02.prod.outlook.com> <043801cf99f1$7165f8b0$5431ea10$@gmx.net> <53BAB379.3040506@berkeley.edu> <046301cf99f9$2935eca0$7ba1c5e0$@gmx.net> <53BBE5CC.50403@berkeley.edu> In-Reply-To: <53BBE5CC.50403@berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(50986999)(83072002)(81342001)(101416001)(46102001)(77982001)(64706001)(20776003)(93886003)(81542001)(76482001)(80022001)(79102001)(2171001)(2656002)(76576001)(85852003)(87936001)(33646001)(99286002)(95666004)(74662001)(54356999)(76176999)(85306003)(106356001)(31966008)(83322001)(4396001)(99396002)(92566001)(558084003)(105586002)(74316001)(106116001)(107046002)(21056001)(74502001)(86362001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/xYmG0_FUKa3wWUJyEiRbt0qb0Sk Cc: 'Mark Baker' , 'Phillip Hallam-Baker' , "json@ietf.org" Subject: Re: [Json] Media types, extensibility in draft-ietf-json-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Jul 2014 17:05:58 -0000 KzEgdG8gaWRlbnRpZnlpbmcgaS1qc29uIGJ5IGEgcHJvZmlsZSANCg0KLTEgdG8gZGVmaW5pbmcg YSBuZXcgbWVkaWEgdHlwZSBvciBhZGRpbmcgYSBuZXcgcGFyYW1ldGVyLg0KICAgKEknZCBjaGFu Z2UgbXkgbWluZCBpZiBzb21lb25lIGhhZCBhIGNvbXBlbGxpbmcgY29uY3JldGUNCiAgICB1c2Ug Y2FzZSkuDQoNCg0KDQo= From nobody Tue Jul 8 10:27:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF81B2BDB; Tue, 8 Jul 2014 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKJL0sDphDmb; Tue, 8 Jul 2014 10:27:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D17C1B2B67; Tue, 8 Jul 2014 10:27:13 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.985.8; Tue, 8 Jul 2014 17:27:11 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 17:27:11 +0000 From: Larry Masinter To: "apps-discuss@ietf.org" , "json@ietf.org" Thread-Topic: merge-patch in APPSA and i-json in JSON Thread-Index: Ac+a0HjpTP2xgtp6TJenjlRnxiyQMg== Date: Tue, 8 Jul 2014 17:27:10 +0000 Message-ID: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(80022001)(101416001)(15202345003)(107046002)(107886001)(15975445006)(229853001)(76576001)(4396001)(77982001)(85306003)(86362001)(54356999)(50986999)(81542001)(83072002)(19580395003)(83322001)(85852003)(21056001)(76482001)(74502001)(74316001)(105586002)(99396002)(74662001)(81342001)(79102001)(92566001)(106356001)(33646001)(46102001)(64706001)(2656002)(95666004)(99286002)(87936001)(31966008)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/58v7IWdUmJx_8hGfIWM8FDvk0xA Subject: [Json] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:27:16 -0000 SSBkb24ndCBsaWtlIHRvIGNyb3NzLXBvc3QsIGJ1dCBpdCBzZWVtcyBhcHByb3ByaWF0ZSBmb3Ig dGhpcyBuYXJyb3cgdG9waWM6DQoNCkpTT04gV0cgaXMgZGVmaW5pbmcgaS1qc29uIHByb2ZpbGUg aW4gZHJhZnQtaWV0Zi1qc29uLWktanNvbg0KQVBQU0EgV0cgaXMgZGVmaW5pbmcgbWVyZ2Ugb3Bl cmF0aW9uIGRhdGEgc3RydWN0dXJlIGluIGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLW1lcmdlLXBh dGNoIA0KQm90aCBhcmUgbmVhcmluZyBXRyBsYXN0IGNhbGwuDQoNClJlYWRpbmcgaW4gcHJlcCBm b3IgVG9yb250bywgSSBoYXZlIHF1ZXN0aW9ucyBJIGNhbid0IHJlYWRpbHkgYW5zd2VyIGxvb2tp bmcgYXQgdGhlIHR3byBkb2N1bWVudHM6DQotIERvZXMgYXBwbGljYXRpb24vbWVyZ2UtcGF0Y2gr anNvbiByZXF1aXJlL2RlZmF1bHQgdG8gdGhlIGktanNvbiBwcm9maWxlPw0KLSBJcyBtZXJnZSBv cGVyYXRpb24gZGVmaW5lZCBmb3IgdGFyZ2V0IEpTT04gdGhhdCBpc24ndCBpLWpzb24/DQotIElm IHNvLCBkb2VzIGl0IHByZXNlcnZlIGktanNvbj8gKGlzIHRoZSByZXN1bHQgaS1qc29uIGlmIHRo ZSBvcmlnaW5hbCB3YXMgIGktanNvbj8NCi0gT3IgaXMgbWVyZ2UgcmVxdWlyZWQgdG8sIG9yIGFs bG93ZWQgdG8sIEFMV0FZUyBwcm9kdWNlIGktanNvbj8NCg0KWW91J2QgdGhpbmsgaXQgc2hvdWxk IGJlIGVhc3kgdG8gYW5zd2VyIHRoZXNlIHF1ZXN0aW9ucyBnaXZlbiB0aGUgdHdvIGRvY3VtZW50 cy4gUGVyaGFwcyBJJ20gbWlzc2luZyB0aGUgb2J2aW91cy4gSWYgdGhlcmUncyBhIHByb2JsZW0s IEknbSBub3Qgc3VyZSB3aGljaCBvbmUgd291bGQgbmVlZCB0byBjaGFuZ2UuIFBvc3NpYmx5IGJv dGguIENvdWxkIHdlIHNlZSBzb21lIGVkaXRvcmlhbCBjb2xsYWJvcmF0aW9uIHRvIG1ha2UgdGhl IGFuc3dlcnMgY2xlYXJlcj8gDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5l dA0KDQoNCg== From nobody Tue Jul 8 10:36:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7131A0395; Tue, 8 Jul 2014 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n2wCs85XP-B; Tue, 8 Jul 2014 10:36:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CAA1A0376; Tue, 8 Jul 2014 10:36:41 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s68HaaZG049779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 10:36:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> Date: Tue, 8 Jul 2014 10:36:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> To: Larry Masinter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/u8eHH1J3F5gbyZe203P7SAzb9IA Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:36:42 -0000 On Jul 8, 2014, at 10:27 AM, Larry Masinter wrote: > - Does application/merge-patch+json require/default to the i-json = profile? No. draft-ietf-appsawg-json-merge-patch doesn't mention I-JSON. > - Is merge operation defined for target JSON that isn't i-json? Yes. The merge operation is defined for all targets, regardless of the = targets' profile of JSON. > - If so, does it preserve i-json? (is the result i-json if the = original was i-json? There is no assurance of that; it is orthogonal. = draft-ietf-appsawg-json-merge-patch doesn't do anything special for any = profile of JSON. > - Or is merge required to, or allowed to, ALWAYS produce i-json? No. draft-ietf-appsawg-json-merge-patch doesn't mention I-JSON. > You'd think it should be easy to answer these questions given the two = documents. It is easy: draft-ietf-appsawg-json-merge-patch doesn't mention I-JSON. > Perhaps I'm missing the obvious. It seems that you are. draft-ietf-appsawg-json-merge-patch doesn't = mention I-JSON. > If there's a problem, I'm not sure which one would need to change. = Possibly both. Could we see some editorial collaboration to make the = answers clearer?=20 There is no reason for draft-ietf-appsawg-json-merge-patch to consider = any profile of JSON. --Paul Hoffman= From nobody Tue Jul 8 12:06:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00921A0425; Tue, 8 Jul 2014 12:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw7UZ_cEIXxN; Tue, 8 Jul 2014 12:06:44 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1E71A0250; Tue, 8 Jul 2014 12:06:44 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1X4aiq-0000qp-3Q; Tue, 08 Jul 2014 15:06:36 -0400 Date: Tue, 8 Jul 2014 15:06:36 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20140708190635.GD6016@mercury.ccil.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/fgIZENEJ30vJ-kE95W-gcPM1bbc Cc: "json@ietf.org" , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:06:46 -0000 Paul Hoffman scripsit: > > - Is merge operation defined for target JSON that isn't i-json? > > Yes. The merge operation is defined for all targets, regardless of > the targets' profile of JSON. Actually, it isn't. It is far from clear from draft-ietf-appsawg-json-merge-patch-04 what to do if a key appearing in the patch matches more than one key appearing in the target. This has nothing to do with I-JSON as such, but is a deficiency in the merge-patch algorithm, the relevant part of which I reproduce here: for each Key/Value pair in Patch: if Value is null: if Key exists in Target: remove the Key/Value pair from Target else: Target[Key] = MergePatch(Target[Key], Value) What is meant by "the Key/Value pair" if there is more than one? Are all such pairs to be removed or mutated, or only one of them? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org What asininity could I have uttered that they applaud me thus? --Phocion, Greek orator From nobody Tue Jul 8 12:11:42 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62B21A0400; Tue, 8 Jul 2014 12:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlhOGvYX9dNm; Tue, 8 Jul 2014 12:11:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DFF1A0255; Tue, 8 Jul 2014 12:11:38 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s68JBZGu054638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jul 2014 12:11:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140708190635.GD6016@mercury.ccil.org> Date: Tue, 8 Jul 2014 12:11:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <319A4568-1D97-4D34-9C66-9ABF3727CDE6@vpnc.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/6c-RzZAN3QyyPUhnHP6-bF1GcrA Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:11:39 -0000 On Jul 8, 2014, at 12:06 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >>> - Is merge operation defined for target JSON that isn't i-json? >>=20 >> Yes. The merge operation is defined for all targets, regardless of >> the targets' profile of JSON. >=20 > Actually, it isn't. It is far from clear from > draft-ietf-appsawg-json-merge-patch-04 what to do if a key appearing = in > the patch matches more than one key appearing in the target. This has > nothing to do with I-JSON as such, but is a deficiency in the = merge-patch > algorithm, the relevant part of which I reproduce here: >=20 > for each Key/Value pair in Patch: > if Value is null: > if Key exists in Target: > remove the Key/Value pair from Target > else: > Target[Key] =3D MergePatch(Target[Key], Value) >=20 > What is meant by "the Key/Value pair" if there is more than one? > Are all such pairs to be removed or mutated, or only one of them? The horse's carcass is so decomposed that you can't even find what to = kick anymore. RFC 7159 says "When the names within an object are not = unique, the behavior of software that receives such an object is = unpredictable." It would be actively harmful for = draft-ietf-appsawg-json-merge-patch to say "we can make it predictable = in our own unique fashion". --Paul Hoffman= From nobody Wed Jul 9 10:57:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9257A1A8BB1; Wed, 9 Jul 2014 10:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwY6eP7WicAX; Wed, 9 Jul 2014 10:57:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28961A0304; Wed, 9 Jul 2014 10:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s69Hv8wS005900; Wed, 9 Jul 2014 19:57:08 +0200 (CEST) Received: from [192.168.217.106] (p54891137.dip0.t-ipconnect.de [84.137.17.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5CBFDE9E; Wed, 9 Jul 2014 19:57:07 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <20140708190635.GD6016@mercury.ccil.org> Date: Wed, 9 Jul 2014 19:57:05 +0200 X-Mao-Original-Outgoing-Id: 426621425.408012-4e4f4eaa488596eb56d8d9a96346f54a Content-Transfer-Encoding: quoted-printable Message-Id: <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/_wchbvqKYVLvDhJEYTT9SJRl7kM Cc: Larry Masinter , Paul Hoffman , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:57:24 -0000 On 08 Jul 2014, at 21:06, John Cowan wrote: > What is meant by "the Key/Value pair" if there is more than one? > Are all such pairs to be removed or mutated, or only one of them? It may have been intuitively obvious to the authors and reviewers, but = may still be worthwhile mentioning in a sentence, that the merge-patch = operation is defined at the level of the JSON data model. Specifically, = there is no expectation that merge-patch preserves representation level = features such as white space, member ordering etc. Gr=FC=DFe, Carsten From nobody Wed Jul 9 17:59:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21641A002D; Wed, 9 Jul 2014 17:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG5HPv3rG3At; Wed, 9 Jul 2014 17:59:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FAC61A0022; Wed, 9 Jul 2014 17:59:29 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6A0xQGH025918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Jul 2014 17:59:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> Date: Wed, 9 Jul 2014 17:59:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/l-S1rSIsS188NefV4Rp23wgnt_8 Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 00:59:30 -0000 On Jul 9, 2014, at 10:57 AM, Carsten Bormann wrote: > On 08 Jul 2014, at 21:06, John Cowan wrote: >=20 >> What is meant by "the Key/Value pair" if there is more than one? >> Are all such pairs to be removed or mutated, or only one of them? >=20 > It may have been intuitively obvious to the authors and reviewers, but = may still be worthwhile mentioning in a sentence, that the merge-patch = operation is defined at the level of the JSON data model. Specifically, = there is no expectation that merge-patch preserves representation level = features such as white space, member ordering etc. Does the following language work for you? The MergePatch operation is defined at the level of the JSON data model. = Specifically, there is no expectation that the MergePatch operation will = preserve representation-level features such as white space, member = ordering, and so on. If an object in the target has more than one = name/value pair with the same name, the result of the patch operation is = unpredictable. --Paul Hoffman= From nobody Thu Jul 10 08:06:13 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4871A0A74; Thu, 10 Jul 2014 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiQdUHQAfOfr; Thu, 10 Jul 2014 08:06:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9265C1A043D; Thu, 10 Jul 2014 08:06:07 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 15:06:06 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 15:06:06 +0000 From: Larry Masinter To: Paul Hoffman , Carsten Bormann Thread-Topic: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON Thread-Index: Ac+a0HjpTP2xgtp6TJenjlRnxiyQMgAArESAAAMkzwAAL90UgAAOv/SAAAmD+MA= Date: Thu, 10 Jul 2014 15:06:06 +0000 Message-ID: <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> In-Reply-To: <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(558084003)(92566001)(87936001)(33646001)(93886003)(21056001)(83322001)(66066001)(80022001)(46102001)(76576001)(74502001)(20776003)(85306003)(76482001)(2656002)(99396002)(64706001)(99286002)(95666004)(81342001)(31966008)(81542001)(106356001)(4396001)(107046002)(83072002)(85852003)(86362001)(101416001)(79102001)(77982001)(76176999)(50986999)(74316001)(54356999)(105586002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/fdDJCfbUGj-5yp0TWbCF7ighB1s Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:06:10 -0000 PiBUaGUgTWVyZ2VQYXRjaCBvcGVyYXRpb24gaXMgZGVmaW5lZCBhdCB0aGUgbGV2ZWwgb2YgdGhl IEpTT04gZGF0YQ0KPiBtb2RlbC4NCg0KVGhpcyBzZWVtcyByZWFzb25hYmxlLCBidXQgd2hlcmUg ZG8gSSBmaW5kIHRoZSAiSlNPTiBkYXRhIG1vZGVsIg0KZGVzY3JpYmVkPyBJJ3ZlIGxvb2tlZCBp biBhbGwgb2YgdGhlIEpTT04gcHVibGljYXRpb25zLCBSRkNzLCANCmludGVybmV0IGRyYWZ0cywg RUNNQSAyNjIsIDQwNC4NCg0KDQoNCg0KIA0KDQoNCg== From nobody Thu Jul 10 08:42:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436C11A0385; Thu, 10 Jul 2014 08:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvGUYOLdmxYz; Thu, 10 Jul 2014 08:42:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAEC1A0A8C; Thu, 10 Jul 2014 08:42:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6AFgSnA052290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 08:42:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 10 Jul 2014 08:42:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> To: Larry Masinter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/eKdclNoNX-cbdFNd0UaQyrvpscc Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:42:39 -0000 On Jul 10, 2014, at 8:06 AM, Larry Masinter wrote: >> The MergePatch operation is defined at the level of the JSON data >> model. >=20 > This seems reasonable, but where do I find the "JSON data model" > described? I've looked in all of the JSON publications, RFCs,=20 > internet drafts, ECMA 262, 404. RFC 7159. Might you instead suggest better wording for what you think we = should say about what the MergePatch operation works on? --Paul Hoffman= From nobody Thu Jul 10 08:46:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1C31A0653; Thu, 10 Jul 2014 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ay29FWWaPgq; Thu, 10 Jul 2014 08:46:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F8B1A0385; Thu, 10 Jul 2014 08:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6AFkIVg023426; Thu, 10 Jul 2014 17:46:18 +0200 (CEST) Received: from [192.168.217.106] (p54891105.dip0.t-ipconnect.de [84.137.17.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5DDB24D4; Thu, 10 Jul 2014 17:46:17 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 10 Jul 2014 17:46:16 +0200 X-Mao-Original-Outgoing-Id: 426699975.915081-e63d58c47cbb3ff354529fbe730719d1 Content-Transfer-Encoding: quoted-printable Message-Id: <3210BA1B-8A53-4440-8658-5B98CE57A23B@tzi.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> To: Larry Masinter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/hTofXLJTHKDTBYo0geQUmgDn7BY Cc: Paul Hoffman , "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 15:46:25 -0000 On 10 Jul 2014, at 17:06, Larry Masinter wrote: >> The MergePatch operation is defined at the level of the JSON data >> model. >=20 > This seems reasonable, but where do I find the "JSON data model" > described? I've looked in all of the JSON publications, RFCs,=20 > internet drafts, ECMA 262, 404. I agree with Paul here, this is described in RFC 7159 (introduction plus = some details in sections 4 to 7), even if we were too pusillanimous to = call it that way. Gr=FC=DFe, Carsten From nobody Thu Jul 10 10:47:48 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E841B292E; Thu, 10 Jul 2014 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NwBIq1mdUHw; Thu, 10 Jul 2014 10:47:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796801B292C; Thu, 10 Jul 2014 10:47:41 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.985.8; Thu, 10 Jul 2014 17:47:39 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 17:47:39 +0000 From: Larry Masinter To: Paul Hoffman Thread-Topic: [apps-discuss] [Json] merge-patch in APPSA and i-json in JSON Thread-Index: AQHPnFWujFcUbpANzkmg+T38hQFzLpuZjxaA Date: Thu, 10 Jul 2014 17:47:39 +0000 Message-ID: <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> In-Reply-To: <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(76104003)(46102001)(64706001)(99286002)(20776003)(2656002)(110136001)(81342001)(99396002)(74662001)(33646001)(106356001)(95666004)(31966008)(87936001)(105586002)(101416001)(93886003)(15202345003)(107046002)(80022001)(83072002)(19580395003)(66066001)(76176999)(85852003)(77982001)(15975445006)(74502001)(76482001)(76576001)(79102001)(92566001)(86362001)(54356999)(50986999)(81542001)(74316001)(21056001)(106116001)(83322001)(85306003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/Agq15QktVzYOuJmEBWurGH29HdM Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 17:47:43 -0000 PiBSRkMgNzE1OS4gTWlnaHQgeW91IGluc3RlYWQgc3VnZ2VzdCBiZXR0ZXIgd29yZGluZyBmb3Ig d2hhdCB5b3UgdGhpbmsNCj4gd2Ugc2hvdWxkIHNheSBhYm91dCB3aGF0IHRoZSBNZXJnZVBhdGNo IG9wZXJhdGlvbiB3b3JrcyBvbj8NCg0KSGVyZSdzIGFuIGF0dGVtcHQ6DQo9PT0NCiAgVGhlIE1l cmdlUGF0Y2ggb3BlcmF0aW9uIGlzIGRlZmluZWQgdG8gb3BlcmF0ZSBhdCBhbiBvYmplY3QgbGV2 ZWwsDQpub3QgYSB0ZXh0dWFsIGxldmVsLiBUaGVyZSBpcyBubyBleHBlY3RhdGlvbiB0aGF0IHRo ZSBNZXJnZVBhdGNoIG9wZXJhdGlvbiANCndpbGwgcHJlc2VydmUgIHRleHR1YWwgcmVwcmVzZW50 YXRpb24tbGV2ZWwgZmVhdHVyZXMgc3VjaCBhcyB3aGl0ZSBzcGFjZSwgDQptZW1iZXIgb3JkZXJp bmcsIG51bWJlciBwcmVjaXNpb24gYmV5b25kIHdoYXQgaXMgYXZhaWxhYmxlIGluIHRoZQ0KdGFy Z2V0J3MgaW1wbGVtZW50YXRpb24sIGFuZCBzbyBmb3J0aC4gDQogDQpJbiBhZGRpdGlvbiwgZXZl biBpZiB0aGUgdGFyZ2V0IGltcGxlbWVudGF0aW9uIGFsbG93cyBtdWx0aXBsZSBuYW1lL3ZhbHVl IHBhaXJzDQp3aXRoIHRoZSBzYW1lIG5hbWUsIHRoZSByZXN1bHQgb2YgdGhlIHBhdGNoIG9wZXJh dGlvbiBvbiBzdWNoDQpvYmplY3RzIGlzIG5vdCBkZWZpbmVkLg0KPT09DQoNCllvdSBjb3VsZCBp bnN0ZWFkIHNheSB0aGF0IHBhdGNoIGNoYW5nZXMgb25lIG9mIHRoZSB2YWx1ZXMsIGFsbCBvZg0K dGhlIHZhbHVlcywgb3IgY29uc29saWRhdGVzIHRoZW0sIG5haWxpbmcgaXQgZG93biBpbiB0aGUg c3Bpcml0IG9mDQppbnRlcm9wZXJhYmlsaXR5Lg0KDQpJIGFsc28gdGhpbmsgaXQgd291bGQgYmUg YWR2aXNhYmxlIHRvIGRpc2FsbG93IGR1cGxpY2F0ZSBuYW1lcw0KaW4gYXBwbGljYXRpb24vbWVy Z2UtcGF0Y2granNvbiwgYnV0IHRoYXQgcmVxdWlyaW5nIHRoZSBvdGhlcg0KZmVhdHVyZXMgb2Yg SS1qc29uIGlzIHVubmVjZXNzYXJ5Lg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRl ci5uZXQNCg0KDQoNCg== From nobody Thu Jul 10 11:53:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1791B296C; Thu, 10 Jul 2014 11:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0ATNMotGgcx; Thu, 10 Jul 2014 11:53:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B921A0352; Thu, 10 Jul 2014 11:53:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6AIrEbu061626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 11:53:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> Date: Thu, 10 Jul 2014 11:53:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> To: Larry Masinter X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/TxqDKOpVmkuj83I8N37vIIWhpss Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:53:19 -0000 On Jul 10, 2014, at 10:47 AM, Larry Masinter wrote: >> RFC 7159. Might you instead suggest better wording for what you think >> we should say about what the MergePatch operation works on? >=20 > Here's an attempt: > =3D=3D=3D > The MergePatch operation is defined to operate at an object level, > not a textual level. There is no expectation that the MergePatch = operation=20 > will preserve textual representation-level features such as white = space,=20 > member ordering, number precision beyond what is available in the > target's implementation, and so forth.=20 >=20 > In addition, even if the target implementation allows multiple = name/value pairs > with the same name, the result of the patch operation on such > objects is not defined. > =3D=3D=3D The first sentence uses "object" incorrectly because JSON uses that term = for something else. It could bee better worded as "The MergePatch = operation is defined to operate at the level of data items, not at the = level of data representation."=20 > You could instead say that patch changes one of the values, all of > the values, or consolidates them, nailing it down in the spirit of > interoperability. Nope, still not going there. The wording in RFC 7159 is still relevant = here. > I also think it would be advisable to disallow duplicate names > in application/merge-patch+json, but that requiring the other > features of I-json is unnecessary. There is no need to re-argue what RFC 7159 says about this. --Paul Hoffman= From nobody Thu Jul 10 13:40:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5181B29FE; Thu, 10 Jul 2014 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YGCvAdnKIsy; Thu, 10 Jul 2014 13:40:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F121B29E8; Thu, 10 Jul 2014 13:40:43 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 20:40:41 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 20:40:41 +0000 From: Larry Masinter To: Paul Hoffman Thread-Topic: [apps-discuss] [Json] merge-patch in APPSA and i-json in JSON Thread-Index: AQHPnFWujFcUbpANzkmg+T38hQFzLpuZjxaAgAAYpgCAABnWIA== Date: Thu, 10 Jul 2014 20:40:40 +0000 Message-ID: References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> In-Reply-To: <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199002)(189002)(87936001)(74662001)(81542001)(76176999)(31966008)(19580395003)(92566001)(2656002)(101416001)(15202345003)(85306003)(76576001)(20776003)(99286002)(79102001)(77982001)(4396001)(106116001)(93886003)(99396002)(95666004)(46102001)(83072002)(74502001)(21056001)(85852003)(54356999)(106356001)(76482001)(50986999)(105586002)(33646001)(110136001)(83322001)(81342001)(107046002)(66066001)(86362001)(15975445006)(74316001)(80022001)(64706001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/XyVFTDjxUvzX12Ufr6sa7sPttIY Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:40:47 -0000 PiA+IEkgYWxzbyB0aGluayBpdCB3b3VsZCBiZSBhZHZpc2FibGUgdG8gZGlzYWxsb3cgZHVwbGlj YXRlIG5hbWVzDQo+ID4gaW4gYXBwbGljYXRpb24vbWVyZ2UtcGF0Y2granNvbiwgYnV0IHRoYXQg cmVxdWlyaW5nIHRoZSBvdGhlcg0KPiA+IGZlYXR1cmVzIG9mIEktanNvbiBpcyB1bm5lY2Vzc2Fy eS4NCj4gDQo+IFRoZXJlIGlzIG5vIG5lZWQgdG8gcmUtYXJndWUgd2hhdCBSRkMgNzE1OSBzYXlz IGFib3V0IHRoaXMuDQoNCkkgZG9uJ3Qgd2FudCB0byByZS1hcmd1ZSB0aGUgZGVjaXNpb24uIEkn bSBqdXN0IHdvbmRlcmluZw0KImlmIGktanNvbiBpcyB1c2VmdWwsIHdoeSBpc24ndCBpdCB1c2Vm dWwgZm9yIHRoaXM/Ig0KDQppLWpzb24gaXMgYmVpbmcgcHJvcG9zZWQgYXMgYW4gSUVURiBSRkMg ZGVzY3JpYmluZyBhIHBhcnRpY3VsYXJseQ0KaW50ZXJlc3RpbmcgcHJvZmlsZSBvZiBKU09OLCBn aXZpbmcgaXQgYSBzcGVjaWFsIG5hbWUsICJJLUpTT04iDQpiYXNlZCBvbiB0aGUgY2xhaW0gdGhh dCB0aGlzIHByb2ZpbGUgaXMgbW9yZSBpbnRlcmVzdGluZw0KdGhhbiBtb3N0IG90aGVyIGNvbWJp bmF0aW9ucyBvZiByZXN0cmljdGlvbnMuDQoNCkJ1dCBoZXJlJ3MgYW4gYXBwbGljYXRpb24gKGFw cGxpY2F0aW9uLyBtZXJnZS1wYXRjaCtqc29uKQ0Kd2hpY2ggLS0gYXMgeW91IHBvaW50IG91dCAt LSBkb2Vzbid0IG1lbnRpb24gSS1KU09OLA0KZXZlbiB0aG91Z2ggc29tZSBvZiB0aGUgY29uc3Ry YWludHMgb2YgIndoaWNoIGluc3RhbmNlcw0KYXJlIG1lYW5pbmdmdWwgdG8gYXBwbHkiIHdvdWxk IHNlZW0gdG8gYmUgbW9yZSBlYXNpbHkNCmV4cHJlc3NlZCBhcyBhIHdlbGwta25vd24gcHJvZmls ZSBvZiBKU09OLiBKdXN0IG5vdA0KSS1KU09OLiBUaGUgcmVzdHJpY3Rpb24gb24gZHVwbGljYXRl IG5hbWVzIGlzIGZpbmUsIGJ1dA0KdGhlcmUncyBubyBuZWVkIHRvIHJlc3RyaWN0IG51bWJlcnMg dG8gSUVFRSBwcmVjaXNpb24NCmluIHRoZSBwYXRjaCByZXF1ZXN0Lg0KDQpNZXJnZXBhdGNoIGlz IG9uZSBkYXRhIHBvaW50LCBhcmUgdGhlcmUgb3RoZXIgSlNPTg0KYXBwbGljYXRpb24gc3BlY3Mg dGhhdCBDT1VMRCB1c2UgaS1qc29uIGFzIGENCm5vcm1hdGl2ZSByZWZlcmVuY2U/DQoNCklmIG1v c3QgY2FzZXMgb2YgSlNPTiBhcHBsaWNhdGlvbiBzcGVjaWZpY2F0aW9ucyB0aGF0DQpuZWVkICdj bGVhbiBKU09OIGlucHV0IHJlcXVpcmVkIGZvciByZXN1bHRzIHRvIGJlDQptZWFuaW5nZnVsJyBw cm9maWxlcyBjYW4ndCB1c2UgSS1KU09OIGFzIGEgYmFzaXMNCmZvciAnY2xlYW4nLCBpdCBjYXN0 cyBkb3VidHMgYXMgdG8gZGVmaW5pbmcgSS1KU09OIGFzDQphIGNhdGVnb3J5LCByYXRoZXIgdGhh biBqdXN0IGEgc2V0IG9mIGJlc3QgcHJhY3RpY2VzLg0KDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xh cnJ5Lm1hc2ludGVyLm5ldA0KDQo= From nobody Thu Jul 10 22:41:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D357C1A8BB5; Thu, 10 Jul 2014 22:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.697 X-Spam-Level: X-Spam-Status: No, score=-12.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAvqmCw1Hh15; Thu, 10 Jul 2014 22:41:20 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4409F1A0B13; Thu, 10 Jul 2014 22:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=786; q=dns/txt; s=iport; t=1405057286; x=1406266886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uAB6O7awMc4ur25NEVgfhvfRp3Y2zSossxqaEpN5qJE=; b=UgU2VZIXggHA79vf/xq5wYxEyt54dn29doVLo7Co58DC/XHw7ciU5ns4 hbBy8SFbYACXsscENMSyIBMzd3yvk0h+3pt8cDuvx+H7blQgQZHoTY6Af V2foItVD7c4eLtFFQSbiq8m8s3PPG8r/SPILaJGZJfHX/Gv75+WdQTVX3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAI13v1OtJA2J/2dsb2JhbABZgw6BLIJxxAGBQwEZcBZ1hAQBAQQjEUUQAgEIGgImAgICMBUQAgQBDQWIQq0QmQYXgSyIUIUXMweCd4FMAQSbBZQbg0SCMA X-IronPort-AV: E=Sophos;i="5.01,642,1400025600"; d="scan'208";a="59981383" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 11 Jul 2014 05:41:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6B5fJYg002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 05:41:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 00:41:19 -0500 From: "Joe Hildebrand (jhildebr)" To: Larry Masinter , Paul Hoffman Thread-Topic: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON Thread-Index: AQHPnHA9h6TupY8iqkSHgrqZ5k9WgZuaGV0AgAC4lwA= Date: Fri, 11 Jul 2014 05:41:18 +0000 Message-ID: References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.61.164.231] Content-Type: text/plain; charset="utf-8" Content-ID: <82C291942E022B4BB42788C320CAC40B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/5nyYyYc4KWQQDH6Y_vPP8-5visk Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 05:41:22 -0000 T24gNy8xMC8xNCwgMTA6NDAgUE0sICJMYXJyeSBNYXNpbnRlciIgPG1hc2ludGVyQGFkb2JlLmNv bT4gd3JvdGU6DQoNCj5JZiBtb3N0IGNhc2VzIG9mIEpTT04gYXBwbGljYXRpb24gc3BlY2lmaWNh dGlvbnMgdGhhdA0KPm5lZWQgJ2NsZWFuIEpTT04gaW5wdXQgcmVxdWlyZWQgZm9yIHJlc3VsdHMg dG8gYmUNCj5tZWFuaW5nZnVsJyBwcm9maWxlcyBjYW4ndCB1c2UgSS1KU09OIGFzIGEgYmFzaXMN Cj5mb3IgJ2NsZWFuJywgaXQgY2FzdHMgZG91YnRzIGFzIHRvIGRlZmluaW5nIEktSlNPTiBhcw0K PmEgY2F0ZWdvcnksIHJhdGhlciB0aGFuIGp1c3QgYSBzZXQgb2YgYmVzdCBwcmFjdGljZXMuDQoN CisxDQoNCkknZCBzdXBwb3J0IGhhdmluZyBtZXJnZS9wYXRjaCBib3RoIGJlIHZhbGlkIEktSlNP TiBhcyB3ZWxsIGFzIG9ubHkNCm9wZXJhdGluZyBvbiB2YWxpZCBJLUpTT04gKHdoaWNoIGFyZSB0 d28gc2VwYXJhdGUgcmVxdWlyZW1lbnRzKS4NCg0KSSBkb24ndCBjYXJlIGlmIHRoYXQgbWVhbnMg eW91IGNhbid0IHBhdGNoIGNydWZ0eSBKU09OLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0K DQo= From nobody Thu Jul 10 22:51:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E41A0B13; Thu, 10 Jul 2014 22:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.013 X-Spam-Level: ** X-Spam-Status: No, score=2.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBXWwO6zmKC5; Thu, 10 Jul 2014 22:51:45 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4201B280F; Thu, 10 Jul 2014 22:51:45 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7DA1332E579; Fri, 11 Jul 2014 14:51:44 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4291_ce3f_45620044_8123_442e_88c4_e6f970a3cb88; Fri, 11 Jul 2014 14:51:43 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id BAA8CBFBD3; Fri, 11 Jul 2014 14:51:43 +0900 (JST) Message-ID: <53BF7B51.3000208@it.aoyama.ac.jp> Date: Fri, 11 Jul 2014 14:51:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Hoffman , Larry Masinter References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org > In-Reply-To: <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/jonZbZRitl5jvV3a5IicfMRIKbc Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 05:51:47 -0000 On 2014/07/11 03:53, Paul Hoffman wrote: > On Jul 10, 2014, at 10:47 AM, Larry Masinter wrote: >> Here's an attempt: >> === >> The MergePatch operation is defined to operate at an object level, >> not a textual level. There is no expectation that the MergePatch operation >> will preserve textual representation-level features such as white space, >> member ordering, number precision beyond what is available in the >> target's implementation, and so forth. >> >> In addition, even if the target implementation allows multiple name/value pairs >> with the same name, the result of the patch operation on such >> objects is not defined. >> === > > The first sentence uses "object" incorrectly because JSON uses that term for something else. It could bee better worded as "The MergePatch operation is defined to operate at the level of data items, not at the level of data representation." Very much agreed about the "object" bit, but can we do s/data representation/textual representation/, please? "data items" and "data representation" sound too much like the same to me. Regards, Martin. From nobody Thu Jul 10 22:51:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646DF1B280F; Thu, 10 Jul 2014 22:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7eIUNnvZl7u; Thu, 10 Jul 2014 22:51:45 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFC61A0AE7; Thu, 10 Jul 2014 22:51:45 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7BA2E32E53F; Fri, 11 Jul 2014 14:51:44 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 428e_752a_a9339117_aa68_4f1a_9342_4fd6a5a23f65; Fri, 11 Jul 2014 14:51:43 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B92FCBF4C8; Fri, 11 Jul 2014 14:51:43 +0900 (JST) Message-ID: <53BF7B58.2010409@it.aoyama.ac.jp> Date: Fri, 11 Jul 2014 14:51:20 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Masinter , Paul Hoffman References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org > In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/Z5JVeZuY1gp_FLC1wsj5PmRbjtQ Cc: "apps-discuss@ietf.org" , "json@ietf.org" Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 05:51:47 -0000 On 2014/07/11 05:40, Larry Masinter wrote: >>> I also think it would be advisable to disallow duplicate names >>> in application/merge-patch+json, but that requiring the other >>> features of I-json is unnecessary. >> >> There is no need to re-argue what RFC 7159 says about this. > > I don't want to re-argue the decision. I'm just wondering > "if i-json is useful, why isn't it useful for this?" Thinking about it, it looks to me as if i-json and merge-patch are orthogonal, in the following sense: If the original document and the patch data are i-json, then the result of applying the patch is guaranteed to be i-json. I haven't checked this fully, but it seems to be the case at least for the lack of duplicate keys, and for restricted value ranges. If that's the case, then that would provide a data point that these two specs are well designed, just not in the way Larry was looking for. Regards, Martin. > i-json is being proposed as an IETF RFC describing a particularly > interesting profile of JSON, giving it a special name, "I-JSON" > based on the claim that this profile is more interesting > than most other combinations of restrictions. > > But here's an application (application/ merge-patch+json) > which -- as you point out -- doesn't mention I-JSON, > even though some of the constraints of "which instances > are meaningful to apply" would seem to be more easily > expressed as a well-known profile of JSON. Just not > I-JSON. The restriction on duplicate names is fine, but > there's no need to restrict numbers to IEEE precision > in the patch request. > > Mergepatch is one data point, are there other JSON > application specs that COULD use i-json as a > normative reference? > > If most cases of JSON application specifications that > need 'clean JSON input required for results to be > meaningful' profiles can't use I-JSON as a basis > for 'clean', it casts doubts as to defining I-JSON as > a category, rather than just a set of best practices. > > > Larry > -- > http://larry.masinter.net > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Jul 10 23:02:18 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD481A8BAF; Thu, 10 Jul 2014 23:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id josouRXNqKTk; Thu, 10 Jul 2014 23:02:12 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9D91A0B13; Thu, 10 Jul 2014 23:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6B6231d000343; Fri, 11 Jul 2014 08:02:03 +0200 (CEST) Received: from [192.168.217.145] (p548939E3.dip0.t-ipconnect.de [84.137.57.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 04101645; Fri, 11 Jul 2014 08:02:01 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <53BF7B58.2010409@it.aoyama.ac.jp> Date: Fri, 11 Jul 2014 08:02:00 +0200 X-Mao-Original-Outgoing-Id: 426751320.119462-1f7298a26fb91e5e2e31ddb1ecd5098e Content-Transfer-Encoding: quoted-printable Message-Id: <05CEB854-5DA3-42A4-B70A-F4EE31299C62@tzi.org> References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org > <53BF7B58.2010409@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/HMQytPdf4oW9QF5lY9QcfQEy0t8 Cc: "json@ietf.org" , Paul Hoffman , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 06:02:15 -0000 On 11 Jul 2014, at 07:51, Martin J. D=FCrst = wrote: > orthogonal Good point. Gr=FC=DFe, Carsten From nobody Thu Jul 10 23:10:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0CB1A0B13; Thu, 10 Jul 2014 23:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8kSSIams00S; Thu, 10 Jul 2014 23:10:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91BB1A02A2; Thu, 10 Jul 2014 23:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6B6AW1T016490; Fri, 11 Jul 2014 08:10:32 +0200 (CEST) Received: from [192.168.217.145] (p548939E3.dip0.t-ipconnect.de [84.137.57.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2F933649; Fri, 11 Jul 2014 08:10:29 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Fri, 11 Jul 2014 08:10:27 +0200 X-Mao-Original-Outgoing-Id: 426751827.691676-967ac2f3537e60d6887744abe4195e98 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13c1732c5d504e84b80cd82e5e8f05ab@BL2PR02MB307.namprd02.prod.outlook.com> <20140708190635.GD6016@mercury.ccil.org> <4CB92BF6-A5A0-4598-A25F-C3F51E1DFFD5@tzi.org> <7E9AAC20-63CC-48EC-81EE-3F53CB3DEF83@vpnc.org> <4e1c044bf224420f94d1ebfb584f40ff@BL2PR02MB307.namprd02.prod.outlook.com> <7B8DAF84-E799-46A5-BC55-5BF34000A548@vpnc.org> <4ee005b6cf4043b6b5cbe8493e82f14f@BL2PR02MB307.namprd02.prod.outlook.com> <4554206C-0046-4AF2-A893-55949EA9DCF5@vpnc.org> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/73_MVFhe-ZyLpAcj2ubd8sypIGA Cc: "json@ietf.org" , Paul Hoffman , "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [Json] [apps-discuss] merge-patch in APPSA and i-json in JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 06:10:43 -0000 On 11 Jul 2014, at 07:41, Joe Hildebrand (jhildebr) = wrote: > I'd support having merge/patch both be valid I-JSON as well as only > operating on valid I-JSON (which are two separate requirements). I don=92t see a gain from creating a normative dependency here. Gr=FC=DFe, Carsten From nobody Fri Jul 11 15:35:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09B21B29EE for ; Fri, 11 Jul 2014 15:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA0qg9GVzYC6 for ; Fri, 11 Jul 2014 15:35:34 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3C81B29E2 for ; Fri, 11 Jul 2014 15:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1929; q=dns/txt; s=iport; t=1405118134; x=1406327734; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=eBzlmpMSmM2Vf1yucqZGFKoJMGFN46a4+RwJhwCllfI=; b=G+qw9kON+InhMgNHGw1KY4Th+E6bCNEaxrHn4B7oxJnYgX7odSavFuxy J1FbvpExJ8tsLDAZ6KipYsbfmShnBYytb6KbhsAMA8ISAJ5hiBQpQxAlj xMcL3LUwz3kgYUwvUUYdSvkbMMOiRoz5TQjqhijpuWd3v7NygzXj/FM9q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMJAG1mwFOtJV2a/2dsb2JhbABZgw5SWqt6DAEBAQEBAQUBbgGUOYdHAYELFnWEAwEBAQRuChELGAkWDwkDAgECAUUGDQgBAYg+xkwXhXuJGzqEQwEEih46jBOEGoFKhUmNCYNjghE X-IronPort-AV: E=Sophos;i="5.01,646,1400025600"; d="scan'208";a="60214251" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 11 Jul 2014 22:35:33 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6BMZX9a006452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Jul 2014 22:35:33 GMT Received: from [10.89.10.188] (10.89.10.188) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Jul 2014 17:35:33 -0500 Message-ID: <53C066AE.9050104@cisco.com> Date: Fri, 11 Jul 2014 16:35:26 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF JSON WG References: <53B21F69.7010101@cisco.com> In-Reply-To: <53B21F69.7010101@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.10.188] Archived-At: http://mailarchive.ietf.org/arch/msg/json/VllI87NF2BjtML4jAxOb5F_qszM Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Jul 2014 22:35:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/30/14, 8:39 PM, Matt Miller wrote: > This message begins the Working Group Last Call (WGLC) on "The > I-JSON Message Format" < draft-ietf-json-i-json-02 >. WGLC will end > in two weeks, on July 14. > > Please review the document and send comments to the Working Group > mailing list < json at ietf.org > or the co-chairs tools.ietf.org > before the end of the WGLC. Any and all comments > on the document are sought in order to asses the strength of > consensus. Even if you have read and commented on this or earlier > versions of the draft, please feel free to comment again. > > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. > > Note that Working Group Last Call ends on Monday (07/14). What has been brought to the list to date is: * correction on the reference to RFC 7149 (should be RFC 7159) * some discussion about a profile URL We want to hear from as many as possible, even if the comment is "looks good to me". If you've been waiting until the last minute to say something, you can stop waiting! (-: - -- Paul Hoffman and Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTwGauAAoJEDWi+S0W7cO1PMIH/juq29cNTiyCrLT6y8GEmWDm 3x1DlPqJH6Mjf5PjHP/3Aq3Y1bcLfES/wvoUiQDJpDRuEZ6ZMSX6JdM5jZ/D/vEn cImSs462hQMa9QQNbHpJPuDO1EhlBhMCPgbLNVXKfI3Nlb385BfPqzFwy9bMY4P1 +iL5H0iz4aJuk1o5pURpeMmzyRSNsVFJTZYz8bzHrfWcjFBWI8wrwJJ/GaK/C/AN oMXl9LUjxADUW2z5mEjOGdR9OU7gdN4rFIYB9GrFYolLho/PqD4+h6022AQmlB9P Hwiwxpa9M/HkN8y+nZCQ9jm/G9SCRMIOMEQoF5kbSVB97wrSkQOfub7HLpJpdXE= =3Lsh -----END PGP SIGNATURE----- From nobody Fri Jul 11 16:52:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5167E1A0089 for ; Fri, 11 Jul 2014 16:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 794bb1UPd8VN for ; Fri, 11 Jul 2014 16:52:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08DA1B29E5 for ; Fri, 11 Jul 2014 16:52:00 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.980.8; Fri, 11 Jul 2014 23:51:59 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Fri, 11 Jul 2014 23:51:59 +0000 From: Larry Masinter To: Matt Miller , IETF JSON WG Thread-Topic: [Json] Working Group Last Call on draft-ietf-i-json-02 Thread-Index: AQHPlNXlZXjIN4zZsUWNV5uEVDZbg5ubhyYAgAAR0AA= Date: Fri, 11 Jul 2014 23:51:58 +0000 Message-ID: References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> In-Reply-To: <53C066AE.9050104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(52044002)(51704005)(189002)(199002)(83072002)(85852003)(4396001)(106356001)(107046002)(76176999)(107886001)(95666004)(31966008)(74662001)(99286002)(81342001)(81542001)(106116001)(105586002)(50986999)(74316001)(79102001)(86362001)(101416001)(54356999)(77982001)(21056001)(15975445006)(80022001)(92566001)(87936001)(33646001)(15202345003)(2656002)(85306003)(76576001)(74502001)(83322001)(64706001)(46102001)(76482001)(19580395003)(20776003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/doRgqpUfkWyFG3IVuaCX1NpT44E Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 11 Jul 2014 23:52:03 -0000 PiA+IFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIGNvbW1lbnRzIHRvIHRoZSBX b3JraW5nDQo+ID4gR3JvdXAgbWFpbGluZyBsaXN0IDwganNvbiBhdCBpZXRmLm9yZyA+IG9yIHRo ZSBjby1jaGFpcnMgPGpzb24tY2hhaXJzIGF0DQo+ID4gdG9vbHMuaWV0Zi5vcmcgPiBiZWZvcmUg dGhlIGVuZCBvZiB0aGUgV0dMQy4gIEFueSBhbmQgYWxsIGNvbW1lbnRzDQo+ID4gb24gdGhlIGRv Y3VtZW50IGFyZSBzb3VnaHQgaW4gb3JkZXIgdG8gYXNzZXMgdGhlIHN0cmVuZ3RoIG9mDQo+ID4g Y29uc2Vuc3VzLiBFdmVuIGlmIHlvdSBoYXZlIHJlYWQgYW5kIGNvbW1lbnRlZCBvbiB0aGlzIG9y IGVhcmxpZXINCj4gPiB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQsIHBsZWFzZSBmZWVsIGZyZWUgdG8g Y29tbWVudCBhZ2Fpbi4NCg0KSSB0aGluayBJIG9yaWdpbmFsbHkgc3VwcG9ydGVkIHRoZSBkZXZl bG9wbWVudCBvZiBJLUpTT04gYXMNCnVzZWZ1bCBuYW1lZCBwcm9maWxlIG9mIEpTT04uIEhvd2V2 ZXIsIGJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9ucw0KYW5kIGZ1cnRoZXIgZXhhbWluYXRpb24s IG15IG9waW5pb24gbm93IGlzIHRoYXQgdGhlIHBhcnRpY3VsYXINCmNvbGxlY3Rpb24gb2YgY29u c3RyYWludHMgaXNuJ3Qgc3BlY2lhbCwgYW5kIHRoZSBkb2N1bWVudCBzaG91bGQNCmluc3RlYWQg YmUgcmVjYXN0IGFzIGEgIkJlc3QgUHJhY3RpY2VzIGZvciBJbnRlcm5ldCBVc2Ugb2YgSlNPTiIu DQpUbyBmYWNpbGl0YXRlIHVzaW5nIHRoZSBkb2N1bWVudCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVu Y2UsIGVhY2gNCmNvbnN0cmFpbnQvYmVzdCBwcmFjdGljZSBjb3VsZCBiZSBuYW1lZCAibm8tZHVw LW5hbWVzIiwNCiJpZWVlLW51bWJlcnMiLCAidXRmOCIuIElmIHlvdSB0aGVuIHdhbnQgdG8gbmFt ZSB0aGUgdW5pb24NCm9mIGFsbCBjb25zdHJhaW50cyBpbiB0aGUgZG9jdW1lbnQgYXMgImktanNv biIgdGhhdCB3b3VsZCBiZSBPSy4NCg0KTW9zdCBvZiB0aGUgZG9jdW1lbnQgKGluY2x1ZGluZyB0 aGUgbm9ybWF0aXZlIGxhbmd1YWdlDQphc3NvY2lhdGVkIHdpdGggZWFjaCBjb25zdHJhaW50KSB3 b3VsZCByZW1haW4sIGJ1dCB0aGUgZW1waGFzaXMNCm9uICJpLWpzb24iIGFzIGEgdW5pcXVlIGFu ZCBjb21wbGV0ZSBwcm9maWxlIHdvdWxkbid0LCBhbmQgDQp3b3VsZCBtYWtlIGl0IGVhc2llciBm b3IgcmVmZXJlbmNpbmcgYXBwbGljYXRpb25zIHRvIGNob29zZQ0KdGhvc2UgY29uc3RyYWludHMg dGhhdCBhcmUgbWVhbmluZ2Z1bCBmb3IgdGhlbS4NCg0KTGFycnkNCi0tDQpodHRwOi8vbGFycnku bWFzaW50ZXIubmV0DQoNCg0K From nobody Fri Jul 11 18:06:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993181A00C0 for ; Fri, 11 Jul 2014 18:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_TJ0SFrMCma for ; Fri, 11 Jul 2014 18:06:35 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5741A00BF for ; Fri, 11 Jul 2014 18:06:34 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hq11so3537822vcb.13 for ; Fri, 11 Jul 2014 18:06:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xLhU1JrDLGDepuBRb+Su574KbYOEpVXElzaALsCCF2o=; b=GyyVM/DRAZgawKpk9xv7sn2G4W1qdaJ4FNkgiIQ38goQw7Nwni1J62sfZG265v7iWr 0pmAwjLyU/Nelj6trAvjc2Dfs4IQ9y+diQjEiKF/ghGBV1574hxfsI0u2M8lJ8BoO9dh iPyNz7liqYsaMS3mt03MSf9Iohnof15y0cqmsTnEmrspq3MCC+z5f33QupVtylxW2RW7 23jUbLSLsxw0/5EwWeJ37J3BTouOxLtiICkHR2QggdpqZ5xV+reYQwRUi9v36R/byihI WIo9HMRfLjdF44gXiH8B9lhI2zOCcv1D7mImv9VKNQuKDMjSDjkA7dfJMeCbh638pkPv jClg== X-Gm-Message-State: ALoCoQlF5Z0niY7idj2pCHug2Aok4bE68YrNCkhfOcVE39gOf0Yy/vlToFa4qVAz9AifTvs3X9KP X-Received: by 10.52.242.104 with SMTP id wp8mr2089152vdc.31.1405127193975; Fri, 11 Jul 2014 18:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Fri, 11 Jul 2014 18:06:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> From: Tim Bray Date: Fri, 11 Jul 2014 18:06:13 -0700 Message-ID: To: Larry Masinter Content-Type: multipart/alternative; boundary=001a1135f6cc42e38704fdf4ab94 Archived-At: http://mailarchive.ietf.org/arch/msg/json/EFMSN2uOwjX5cK5HD6ThjpmSP7g Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Jul 2014 01:06:36 -0000 --001a1135f6cc42e38704fdf4ab94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, I think this discussion sort of already happened, but here=E2=80=99s = the existence proof: If I-JSON had existed at the time JOSE was getting going, they could have simplified their specs, and implementers=E2=80=99 lives, wi= th the following statement: Use I-JSON. Also, the collection of constraints IS special: It covers everything that 7159 calls out as an interoperability problem, and says =E2=80=9Cdon=E2=80= =99t do that=E2=80=99. On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter wrote: > > > Please review the document and send comments to the Working > > > Group mailing list < json at ietf.org > or the co-chairs at > > > tools.ietf.org > before the end of the WGLC. Any and all comments > > > on the document are sought in order to asses the strength of > > > consensus. Even if you have read and commented on this or earlier > > > versions of the draft, please feel free to comment again. > > I think I originally supported the development of I-JSON as > useful named profile of JSON. However, based on recent discussions > and further examination, my opinion now is that the particular > collection of constraints isn't special, and the document should > instead be recast as a "Best Practices for Internet Use of JSON". > To facilitate using the document as a normative reference, each > constraint/best practice could be named "no-dup-names", > "ieee-numbers", "utf8". If you then want to name the union > of all constraints in the document as "i-json" that would be OK. > > Most of the document (including the normative language > associated with each constraint) would remain, but the emphasis > on "i-json" as a unique and complete profile wouldn't, and > would make it easier for referencing applications to choose > those constraints that are meaningful for them. > > Larry > -- > http://larry.masinter.net > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1135f6cc42e38704fdf4ab94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wel= l, I think this discussion sort of already happened, but here=E2=80=99s the= existence proof: If I-JSON had existed at the time JOSE was getting going,= they could have simplified their specs, and implementers=E2=80=99 lives, w= ith the following statement: Use I-JSON.

Also, the collection of constr= aints IS special: It covers everything that 7159 calls out as an interopera= bility problem, and says =E2=80=9Cdon=E2=80=99t do that=E2=80=99.


On Fri,= Jul 11, 2014 at 4:51 PM, Larry Masinter <masinter@adobe.com> wrote:
> > Please review the = document and send comments to the Working
> > Group mailing list < json at ietf.org > or the co-chairs <json-chairs at
> > tools.ietf.or= g > before the end of the WGLC. =C2=A0Any and all comments
> > on the document are sought in order to asses the strength of
> > consensus. Even if you have read and commented on this or earlier=
> > versions of the draft, please feel free to comment again.

I think I originally supported the development of I-JSON as
useful named profile of JSON. However, based on recent discussions
and further examination, my opinion now is that the particular
collection of constraints isn't special, and the document should
instead be recast as a "Best Practices for Internet Use of JSON".=
To facilitate using the document as a normative reference, each
constraint/best practice could be named "no-dup-names",
"ieee-numbers", "utf8". If you then want to name the un= ion
of all constraints in the document as "i-json" that would be OK.<= br>
Most of the document (including the normative language
associated with each constraint) would remain, but the emphasis
on "i-json" as a unique and complete profile wouldn't, and would make it easier for referencing applications to choose
those constraints that are meaningful for them.

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


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



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--001a1135f6cc42e38704fdf4ab94-- From nobody Fri Jul 11 19:40:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6471B1A0108 for ; Fri, 11 Jul 2014 19:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K50VKLWKrEhz for ; Fri, 11 Jul 2014 19:40:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154811A00F8 for ; Fri, 11 Jul 2014 19:40:48 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1X5mu4-0001py-V2; Fri, 11 Jul 2014 22:19:09 -0400 Date: Fri, 11 Jul 2014 22:19:08 -0400 From: John Cowan To: Larry Masinter Message-ID: <20140712021908.GK14123@mercury.ccil.org> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/czv_yzRjWpbsCXoPWWvoHS5txC8 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 12 Jul 2014 02:40:53 -0000 Larry Masinter scripsit: > I think I originally supported the development of I-JSON as > useful named profile of JSON. However, based on recent discussions > and further examination, my opinion now is that the particular > collection of constraints isn't special, and the document should > instead be recast as a "Best Practices for Internet Use of JSON". -1 > To facilitate using the document as a normative reference, each > constraint/best practice could be named "no-dup-names", > "ieee-numbers", "utf8". This, however, would be a Good Thing. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. --Bilbo From nobody Mon Jul 14 13:59:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7558B1A00EB for ; Mon, 14 Jul 2014 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6VoDngvJ1t3 for ; Mon, 14 Jul 2014 13:59:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4551A00C3 for ; Mon, 14 Jul 2014 13:59:04 -0700 (PDT) Received: from Vostro3500 ([37.116.120.134]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lyj4F-1WT2cj1ix5-016AwL for ; Mon, 14 Jul 2014 22:59:02 +0200 From: "Markus Lanthaler" To: "'IETF JSON WG'" References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> In-Reply-To: <53C066AE.9050104@cisco.com> Date: Mon, 14 Jul 2014 22:58:58 +0200 Message-ID: <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKov2vhk56OUbYXKcowgYH+SabU7AKM8Buimdll/aA= Content-Language: de X-Provags-ID: V03:K0:YCV07L8ChDhSwzCN5+EDcAYawrL2KCYOVCvICes8ljeFmW/dg7S xQwHYIMHKAry6ZAfUpOQUDzL4XtdS893MC+b0joD57Yq2K2vB5qLW81vA8g7RUr/lq19AmL Q7lFdmVeeh2PDQuWIj71XDqtkV0ltgSlZRfjU9Izyt+MGEsULc7QI5zWvjergH1fy1jrqVn IkgKBoFnypFDOFEkSY6Ug== Archived-At: http://mailarchive.ietf.org/arch/msg/json/P7IOo3O74_odrE4KTcgFz9s3RLE Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 20:59:06 -0000 On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote: > Note that Working Group Last Call ends on Monday (07/14). What has > been brought to the list to date is: > > * correction on the reference to RFC 7149 (should be RFC 7159) > * some discussion about a profile URL > > We want to hear from as many as possible, even if the comment is > "looks good to me". As already said, I think it would be a good idea to mint and register a profile URI. -- Markus Lanthaler @markuslanthaler From nobody Mon Jul 14 14:02:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216981A00F8 for ; Mon, 14 Jul 2014 14:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7D8NSJDOZQ0 for ; Mon, 14 Jul 2014 14:02:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D201A00F6 for ; Mon, 14 Jul 2014 14:02:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6EL2Xib094840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Jul 2014 14:02:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Mon, 14 Jul 2014 14:02:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8589650D-21E9-4FF5-BF28-B7D5420A3D62@vpnc.org> References: To: IETF JSON WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/H5q-ff5vZ7Kkn0D-DsmTwP28ri8 Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 14 Jul 2014 21:02:36 -0000 [[ Another nudge on the topic. If no one else cares, that's fine, but I = suspect there are people who have not answered the questions who have = opinions. ]] On Jul 7, 2014, at 1:57 PM, Paul Hoffman wrote: > Greetings again. There is still disagreement in the WG about what the = text separator should be for draft-ietf-json-text-sequence. The current = draft, draft-ietf-json-text-sequence-04, specifies it as the LF = character, and gives rationale for that decision in Section 2.2. Many = people in the WG have expressed a preference for a different character, = one that would not require any stripping from the normal whitespace that = can exist inside the JSON text. There were many suggestions for such a = different character; the one that seemed most favored was the ASCII = record separator (RS) character, U+001e. >=20 > In order to simplify the decision, I'd like to ask a few simple = questions: >=20 > - Do you feel that the protocol will be significantly broken if it = uses LF as the text separator? >=20 > - Do you feel that the protocol will be significantly broken if it = uses RS as the text separator? >=20 > - Do you feel that using LF or RF as the text separator is essentially = the same for the protocol? >=20 > Answers of "yes", "no", and "don't know" are most appreciated. = Explanation of a "yes" and "no" are probably not helpful at this time = because they are likely to cause the thread to go off into discussion of = the explanation, not of the questions. >=20 > Wearing my chair hat, I'm not sure how I will respond depending on = different patterns in the results. Let's answer the questions and then = see what we think it means. >=20 > --Paul Hoffman From nobody Mon Jul 14 21:38:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8371A02BE for ; Mon, 14 Jul 2014 21:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRM9pXuVvQOF for ; Mon, 14 Jul 2014 21:38:46 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DF61A029D for ; Mon, 14 Jul 2014 21:38:46 -0700 (PDT) Received: from 77-56-165-193.dclient.hispeed.ch ([77.56.165.193] helo=[192.168.0.13]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1X6uVo-0005Ub-CA; Mon, 14 Jul 2014 21:38:45 -0700 References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D257) From: Erik Wilde Date: Tue, 15 Jul 2014 06:38:40 +0200 To: Markus Lanthaler Archived-At: http://mailarchive.ietf.org/arch/msg/json/KVmY6RnuhpOuwJLheM7ADn-6weU Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 04:38:47 -0000 > On 14 Jul 2014, at 22:58, "Markus Lanthaler" wr= ote: >=20 >> On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote: >> Note that Working Group Last Call ends on Monday (07/14). What has >> been brought to the list to date is: >>=20 >> * correction on the reference to RFC 7149 (should be RFC 7159) >> * some discussion about a profile URL >>=20 >> We want to hear from as many as possible, even if the comment is >> "looks good to me". >=20 > As already said, I think it would be a good idea to mint and register a > profile URI. +1 cheers, dret. From nobody Mon Jul 14 23:21:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369B1A0178 for ; Mon, 14 Jul 2014 23:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNDrgNvudwnL for ; Mon, 14 Jul 2014 23:21:08 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0281C1B281C for ; Mon, 14 Jul 2014 23:21:08 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id CD44120047B69; Mon, 14 Jul 2014 23:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=loJRiAFFEdC6Bo 83x68Nvm1HdOs=; b=k81dkrSq7wPgQ2bZRBp6k0f16zi8yZlGF46Du6pIMBUuLC 0bK5jtMNIFLWOAFVTy6RKqXs1v8kDVu4U46BnsYdfIhbKa3iTXaUo4nZYkyU1rRb yOFQng1JPhkDHZqsHTPIFzqx17L6byf9rdoA8YhgaTAgSvUruTQHo4QWvZYk0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 7BD5520047B64; Mon, 14 Jul 2014 23:21:07 -0700 (PDT) Date: Tue, 15 Jul 2014 01:20:51 -0500 From: Nico Williams To: Tim Bray Message-ID: <20140715062050.GA2256@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/f9mLnFGg918jsE3wbu1Cr0KrZ0U Cc: Paul Hoffman , IETF JSON WG Subject: [Json] LF and RS are equivalent (Re: The text in draft-ietf-json-text-sequence) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 06:21:09 -0000 On Mon, Jul 07, 2014 at 04:30:19PM -0700, Tim Bray wrote: > On Mon, Jul 7, 2014 at 1:57 PM, Paul Hoffman wrote: > > > > > - Do you feel that the protocol will be significantly broken if it uses LF > > as the text separator? > > > > Yes Not at all. Consider: - a logger has to check that the input doesn't contain any RS, if we go with RS, therefore checking for and replacing LFs with SP is no more burdensome: it costs a few more writes to memory in the infrequent case; - replacing LFs (unescaped LFs; remember that LFs in strings MUST always be escaped) with SP is a valid transformation that does not change the content nor meaning of a JSON text Therefore, LF and RS are equivalent in terms of: work for the implementor, and run-time burden. Also: in terms of what happens if a logger doesn't check (or transform) the texts it logs to make sure they don't contain the text separator. Nico -- From nobody Mon Jul 14 23:30:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B491A0309 for ; Mon, 14 Jul 2014 23:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo2-TddwaXpE for ; Mon, 14 Jul 2014 23:30:25 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E05381A0308 for ; Mon, 14 Jul 2014 23:30:25 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id BB7C920078716; Mon, 14 Jul 2014 23:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iiU/SDbKaQbOQC Tds1l1aNwlYR8=; b=E3cYIs6drIdaBIrGAjN9Vq0mBl/jLREttzJz15/8H5T66c KY5rPePMImEXlgYTkuyBMoT/Vc93xyIwRrYFK2CWECCSDLteJqN8kD/EHJyFqUle TNLqenDtspJAhnQU3HV3FRbP9IEAfBO76w5o/ArmcY0CsXwI6qfTstlrOOSiE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id 610D520078710; Mon, 14 Jul 2014 23:30:25 -0700 (PDT) Date: Tue, 15 Jul 2014 01:30:24 -0500 From: Nico Williams To: "Manger, James" Message-ID: <20140715063023.GB2256@localhost> References: <255B9BB34FB7D647A506DC292726F6E11549A8F764@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11549A8F764@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/NjtwMwKFw7dJLzkAT727-TzvRlo Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 06:30:26 -0000 On Tue, Jul 08, 2014 at 09:43:10AM +1000, Manger, James wrote: > - Do you feel that the protocol will be significantly broken if it uses LF as the text separator? > > No > > - Do you feel that the protocol will be significantly broken if it uses RS as the text separator? > > Yes I agree. I think RS will hurt and won't help. To begin with: there exists running code using LF as the separator. I just demonstrated (separate post, new sub-thread) that RS/LF are equivalent in terms of functionality, semantics, and cost. So why break running code?? And then there's all the text-oriented tools that won't handle RS. Examples have been given in past posts. There's no value to using RS or anything other than LF. Nico -- From nobody Mon Jul 14 23:32:40 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014A61B2820 for ; Mon, 14 Jul 2014 23:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQYMXo-GCyWM for ; Mon, 14 Jul 2014 23:32:37 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 48C791A0309 for ; Mon, 14 Jul 2014 23:32:37 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 2C034B805B; Mon, 14 Jul 2014 23:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=gy0HN9gC+PjvaMdHdyANDnFIyQ0=; b=L5EU0uog1Zq 8RR0aiKmiD7K+CPZ8aWFir8LsJ92gjk7mbkOBfBaN28zOmQaRDxIfI37B5tJjf9X YPpxTBfqOZ6Qqmf+cQSxdzObjA3Y8Fc01jt+PxhTUTLKeayh61vkxvjStDcXPK8H Qf/shTZLSnCckCOCw4/0m0s5+swUURr8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id C85B0B8058; Mon, 14 Jul 2014 23:32:36 -0700 (PDT) Date: Tue, 15 Jul 2014 01:32:36 -0500 From: Nico Williams To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20140715063234.GC2256@localhost> References: <53BB44CB.5040503@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <53BB44CB.5040503@it.aoyama.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/l4Ya8pCiTC6XYo1rdebXdp5yQCk Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 06:32:38 -0000 On Tue, Jul 08, 2014 at 10:09:31AM +0900, "Martin J. D=FCrst" wrote: > On 2014/07/08 05:57, Paul Hoffman wrote: > >- Do you feel that the protocol will be significantly broken if it use= s LF as the text separator? >=20 > Yes. >=20 > >- Do you feel that the protocol will be significantly broken if it use= s RS as the text separator? >=20 > Yes. >=20 > >- Do you feel that using LF or RF as the text separator is essentially= the same for the protocol? >=20 > Yes. >=20 > [...] >=20 > [The above are just a reflection of the fact that I think that this > format (it's not really a protocol) is unnecessary and therefore > broken from the start, and therefore it's broken with whatever > separator there is (except with ',', i.e. simply as a JSON array). > The problem of diverging opinions is best solved by abandoning this > spec.] Do you feel that the IESG ought to request that the RFC-Editor do not publish if we pursue Informational RFC publication? Please explain in detail how this protocol is harmful the Internet. Nico --=20 From nobody Mon Jul 14 23:34:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35431B2820 for ; Mon, 14 Jul 2014 23:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_pVig_xwHbb for ; Mon, 14 Jul 2014 23:34:09 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBDE1B2822 for ; Mon, 14 Jul 2014 23:34:09 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id F38FD2007DA12; Mon, 14 Jul 2014 23:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AtFKbxVYJD07Il Xlcp3+DEyt9NI=; b=I3OAIjxUs+A6RtfLEWFmXgGKOIoN/A9nnGLvhvSJFoti80 1LkNJZBv7p/Sfr1rpZJqYGXPzXEmaxX/M5OE5HHiBWxsJqTMrNzPFVUy5GoOX6aJ YQbttTpQHeUq3+opO97VHVaqFwlcfXeD4yaXrOUIDTwFWGY4EWR+RxPG1VBPs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 8CADE2007DA11; Mon, 14 Jul 2014 23:34:08 -0700 (PDT) Date: Tue, 15 Jul 2014 01:34:08 -0500 From: Nico Williams To: John Cowan Message-ID: <20140715063406.GD2256@localhost> References: <20140708011503.GD1447@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140708011503.GD1447@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/R9V-HcOZAKRPQ3Y1QmN7UNwLvY0 Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 06:34:09 -0000 On Mon, Jul 07, 2014 at 09:15:04PM -0400, John Cowan wrote: > Paul Hoffman scripsit: > > > - Do you feel that the protocol will be significantly broken if it > > uses LF as the text separator? > > No. > > > - Do you feel that the protocol will be significantly broken if it > > uses RS as the text separator? > > No. > > > - Do you feel that using LF or RF as the text separator is essentially > > the same for the protocol? > > Yes. (However, it would be bad to allow both.) Thanks. I agree, though I think LF is better than RS for various reasons (given separately), therefore though they are equivalent on some level, RS is not as useful (not to say harmful) as LF. Nico -- From nobody Mon Jul 14 23:38:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D661A0309 for ; Mon, 14 Jul 2014 23:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SE0PcP108eh for ; Mon, 14 Jul 2014 23:38:55 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D595D1B281C for ; Mon, 14 Jul 2014 23:38:55 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id B6FF32C806C; Mon, 14 Jul 2014 23:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MQkRSqygvpL/Hn KNoLnu1T+WRxo=; b=ROrjI166mwPWdMt4fKbrLdySibfBPAFbnPy8LLndFxsikZ PS4MGECF5wvPRcefZI3TIie7pyli8YC5grc9DaClhCM/9+pVJCLeFmnPylZ+TSri A768Q6He8isoBOFE3EGOFcfk/Xk88uOPF1oku9Gg1mSRena7EO2/97MnFpcJI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 7065E2C806B; Mon, 14 Jul 2014 23:38:55 -0700 (PDT) Date: Tue, 15 Jul 2014 01:38:54 -0500 From: Nico Williams To: "Joe Hildebrand (jhildebr)" Message-ID: <20140715063853.GE2256@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/TLY-Drr6o_RSjyp-t5zgbF3EdUg Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 06:38:57 -0000 On Tue, Jul 08, 2014 at 11:50:54AM +0000, Joe Hildebrand (jhildebr) wrote: > On 7/7/14, 10:57 PM, "Paul Hoffman" wrote: > >- Do you feel that the protocol will be significantly broken if it uses > >LF as the text separator? > > Somewhat. Considering that... - ...LFs cannot appear unescaped in strings, - therefore LFs in JSON texts are just whitespace, - therefore LFs in JSON texts may safely be removed or replaced with other JSON whitespace, and considering that if we used RS a logger would still have to check that a text to be logged does not include RS,... ...what might be broken if we use LF instead of RS? Loggers would have to s/LF/SP/g or s/LF//g or equivalent. But in the common case this is equivalent to checking that a text to be logged has no RS. For loggers that produce their own texts, all they have to do is select a "compact" encoding, as provided by most libraries, or s/LF/SP/g if no such option is available. (My apologies, I'm now repeating myself somewhat.) Nico -- From nobody Tue Jul 15 00:06:31 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252851B282F for ; Tue, 15 Jul 2014 00:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02mxG-BSHSPy for ; Tue, 15 Jul 2014 00:06:21 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F6C1B282D for ; Tue, 15 Jul 2014 00:06:20 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1X6woY-0001Hb-N9; Tue, 15 Jul 2014 03:06:14 -0400 Date: Tue, 15 Jul 2014 03:06:14 -0400 From: John Cowan To: Nico Williams Message-ID: <20140715070614.GH10065@mercury.ccil.org> References: <20140715063853.GE2256@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140715063853.GE2256@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/ql1EV7xqdtS7u5sAwxTjBmOESjA Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 07:06:28 -0000 Nico Williams scripsit: > and considering that if we used RS a logger would still have to check > that a text to be logged does not include RS,... How so? JSON cannot contain unescaped RS; an RS in a string must appear as \u001F. > Loggers would have to s/LF/SP/g or s/LF//g or equivalent. But in the > common case this is equivalent to checking that a text to be logged has > no RS. No such check is called for. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org A rose by any other name may smell as sweet, but if you called it an onion you'd get cooks very confused. --RMS From nobody Tue Jul 15 01:14:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6491B2841 for ; Tue, 15 Jul 2014 01:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7jORfHpYfdk for ; Tue, 15 Jul 2014 01:14:20 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id C4B281B283B for ; Tue, 15 Jul 2014 01:14:19 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id EEA1232E0B2; Tue, 15 Jul 2014 17:14:17 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2b06_91bb_c10d8e2f_29f6_4fea_be8d_2d6373c67253; Tue, 15 Jul 2014 17:14:17 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2A276BFC81; Tue, 15 Jul 2014 17:14:17 +0900 (JST) Message-ID: <53C4E2C8.90708@it.aoyama.ac.jp> Date: Tue, 15 Jul 2014 17:14:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <53BB44CB.5040503@it.aoyama.ac.jp> <20140715063234.GC2256@localhost> In-Reply-To: <20140715063234.GC2256@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/Knr_9DWRVSSAzZzvFPkJy0XJNWg Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 08:14:22 -0000 Hello Nico, On 2014/07/15 15:32, Nico Williams wrote: > On Tue, Jul 08, 2014 at 10:09:31AM +0900, "Martin J. D=C3=BCrst" wrote: >> [The above are just a reflection of the fact that I think that this >> format (it's not really a protocol) is unnecessary and therefore >> broken from the start, and therefore it's broken with whatever >> separator there is (except with ',', i.e. simply as a JSON array). >> The problem of diverging opinions is best solved by abandoning this >> spec.] > > Do you feel that the IESG ought to request that the RFC-Editor do not > publish if we pursue Informational RFC publication? Please explain in > detail how this protocol is harmful the Internet. "harmful" is a bit too strong. I used the word "unnecessary". Good=20 engineering includes *not* doing stuff that isn't necessary. Good=20 engineering includes avoiding unnecessary minor variants. Good=20 engineering includes exploiting reusing solutions (i.e. JSON arrays),=20 rather than reinventing (a slightly edgy) wheel. In my opinion, the IESG should never have chartered the WG for this work=20 item, because the WG wasn't ever actually asked whether we want to work=20 on this. It was just included in the follow-up work after completing the=20 base spec for reasons that I can only speculate about (e.g. the new WG=20 charter otherwise looking a bit thin?). In my view, it's never too late to abandon this work; I'd be sorry for=20 the work you invested in drafting, but we could save the IESG, the IETF,=20 and the RFC editor some work. The former two might be avoided if this is=20 published as an independent contribution, but this would happen outside=20 the WG. If that avenue is persued, I'd probably urge the IESG to request=20 the addition of a comment explicitly saying that JSON arrays are a=20 better solution. Anyway, I hope I don't have to spend too much time anymore on this, sorry= . Regards, Martin. From nobody Tue Jul 15 06:16:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0F1B28B5 for ; Tue, 15 Jul 2014 06:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUx1lvVC5NrO for ; Tue, 15 Jul 2014 06:16:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99E71B2888 for ; Tue, 15 Jul 2014 06:16:17 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6FDGDbK042159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Jul 2014 06:16:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140715063023.GB2256@localhost> Date: Tue, 15 Jul 2014 06:16:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F609FAA-11AA-45F2-A186-CD0ED06A8559@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E11549A8F764@WSMSG3153V.srv.dir.telstra.com> <20140715063023.GB2256@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/MjXXzfG5SDrudq0123gTjSegWbo Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 13:16:18 -0000 Nico: The poll was meant as a poll, not a discussion. As you know, the = poll said: Answers of "yes", "no", and "don't know" are most appreciated. = Explanation of a "yes" and "no" are probably not helpful at this time = because they are likely to cause the thread to go off into discussion of = the explanation, not of the questions. --Paul Hoffman= From nobody Tue Jul 15 06:59:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0131A03F8 for ; Tue, 15 Jul 2014 06:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIGtoNO2W4ct for ; Tue, 15 Jul 2014 06:59:15 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEC51B28B5 for ; Tue, 15 Jul 2014 06:59:13 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so2194400lab.35 for ; Tue, 15 Jul 2014 06:59:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YfjCLdZsBFGjfUBS62o6isYvZKI0jW3tNJSRkEk63n0=; b=Lw2SqSemA/XMxFr7Tem6bkMt25KXyf6gKNYmBjXKxbW1SxVavZS86bT9yHkGI6zhFa aNPCwnRKDmNuTZAaYJijHY/hXrCDNDoAz1kdr36bZgJ7LUUis22f9p/CAWzQ4dUkqL/S uYmgvcnhbc9tyOv959HV4IGrKmwOvfag1SXXNopkPg6pOOohEKVJ1uLrz7AGldeczPw0 dW73FchrFVtoKR6AVwiDI3N7e7Wkr57m03YkEnfHyBxDS3/pHXZAnxptUE50VEhAVtJ3 Ci35PYN0WineFyQxoPVLLv7dIkY3HMoGsuAWq8lVT/Zd8P3cK9e5v8ni1KoBUo+2bgDL Z45w== X-Gm-Message-State: ALoCoQmk+O9PxFHGkyV8vENKJ5rA89LIpnYlciG7rGgLZxUEkMCLasHvQtcvniWdAmJmc/Q26Lao MIME-Version: 1.0 X-Received: by 10.112.133.97 with SMTP id pb1mr1832225lbb.4.1405432752036; Tue, 15 Jul 2014 06:59:12 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.75.178 with HTTP; Tue, 15 Jul 2014 06:59:11 -0700 (PDT) In-Reply-To: <53C066AE.9050104@cisco.com> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> Date: Tue, 15 Jul 2014 09:59:11 -0400 X-Google-Sender-Auth: ROR0_UEzv65ofd-BySrcsBa6h6Q Message-ID: From: Matthew Morley To: Matt Miller Content-Type: multipart/alternative; boundary=047d7b3a8048f0f00d04fe3bcf7e Archived-At: http://mailarchive.ietf.org/arch/msg/json/VGEaK2J-ZlWqj4q574erm3oejjE Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 13:59:19 -0000 --047d7b3a8048f0f00d04fe3bcf7e Content-Type: text/plain; charset=UTF-8 On Fri, Jul 11, 2014 at 6:35 PM, Matt Miller wrote: > We want to hear from as many as possible, even if the comment is > "looks good to me". > I'm a little late to reply, but looks good to me. -- Matthew P. C. Morley --047d7b3a8048f0f00d04fe3bcf7e Content-Type: text/html; charset=UTF-8
On Fri, Jul 11, 2014 at 6:35 PM, Matt Miller <mamille2@cisco.com> wrote:
We want to hear from as many as possible, even if the comment is
"looks good to me".

I'm a little late to reply, but looks good to me.

--
Matthew P. C. Morley
--047d7b3a8048f0f00d04fe3bcf7e-- From nobody Tue Jul 15 07:41:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6191B287F for ; Tue, 15 Jul 2014 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTeydXFvj4M5 for ; Tue, 15 Jul 2014 07:41:10 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212851B28BA for ; Tue, 15 Jul 2014 07:39:52 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so10598684vcb.30 for ; Tue, 15 Jul 2014 07:39:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/SxCx5MWlOY45SkUPFcC4ppHPRrV8gJP3PwDi3Qmmbw=; b=fEmD3hUG40//5uR96IFD0WQFgBOEZnXzEC0TOx4zXeEkedmtathb1mAxOJVxnNpgU3 CZ3SgBujEI0ZXdW4dhMiiPxZQJK3aIxYncETSL1xrMA/QS7RaoFB2XeHgfLOn2mPI54w VT/9T1T0PL1LUALH4J1B8NQKshtm+ZygRCOPKpY6wX18VSOdZnnC+KAoM1SviTQA98pc EvcuYPqO2esVbiU89M3Ob+0mZFTGecEOqxw6SbtdH5NQvdGnWIecu9VbqSvjGotQCgA7 URzEFcr04Elj1Sl75Uxq26aoLBxJB4AFICMiLPUjl/4yQqgdBwXx51L0j0CmZ1xMkxh4 UBCg== X-Gm-Message-State: ALoCoQnZcZnBPJN4yoaz2UrcTocmgWBuqdm2ntyCNI5XdVm7ZsXAQ7RoBtAAudcDqwTneJ+ok5nA X-Received: by 10.52.154.106 with SMTP id vn10mr5954110vdb.36.1405435190943; Tue, 15 Jul 2014 07:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Tue, 15 Jul 2014 07:39:30 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> From: Tim Bray Date: Tue, 15 Jul 2014 07:39:30 -0700 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=bcaec51d2f484fb85204fe3c6173 Archived-At: http://mailarchive.ietf.org/arch/msg/json/1gAEZhcwkFnRW7M8MrOQVavq2iU Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 14:41:26 -0000 --bcaec51d2f484fb85204fe3c6173 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there an example of such a profile proving useful to application builders? Haven=E2=80=99t encountered one myself but I assume there must b= e some out there. On Mon, Jul 14, 2014 at 1:58 PM, Markus Lanthaler wrote: > On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote: > > Note that Working Group Last Call ends on Monday (07/14). What has > > been brought to the list to date is: > > > > * correction on the reference to RFC 7149 (should be RFC 7159) > > * some discussion about a profile URL > > > > We want to hear from as many as possible, even if the comment is > > "looks good to me". > > As already said, I think it would be a good idea to mint and register a > profile URI. > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --bcaec51d2f484fb85204fe3c6173 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is = there an example of such a profile proving useful to application builders? = =C2=A0Haven=E2=80=99t encountered one myself but I assume there must be som= e out there.


On Mon,= Jul 14, 2014 at 1:58 PM, Markus Lanthaler <markus.lanthaler@gmx.ne= t> wrote:
On Saturday, July 12, 2014 1= 2:35 AM, Matt Miller wrote:
> Note that Working Group Last Call ends on Monday (07/14). =C2=A0What h= as
> been brought to the list to date is:
>
> * correction on the reference to RFC 7149 (should be RFC 7159)
> * some discussion about a profile URL
>
> We want to hear from as many as possible, even if the comment is
> "looks good to me".

As already said, I think it would be a good idea to mint and register= a
profile URI.


--
Markus Lanthaler
@markuslanthaler

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



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--bcaec51d2f484fb85204fe3c6173-- From nobody Tue Jul 15 16:13:15 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6CF1B29BC for ; Tue, 15 Jul 2014 16:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mhMs03mYwD6 for ; Tue, 15 Jul 2014 16:13:11 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1561B29B8 for ; Tue, 15 Jul 2014 16:13:11 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 55765BBA063; Tue, 15 Jul 2014 16:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=EoQ+dFPIN0kJ+0 cgSzgRGjbeA18=; b=q0yv3X7xdRb6er8MzCHyiwnQB0P/rOyAzyXKrbmuG6Vewn R8+rmsmJudZrjpnw2EcMhQmg34XMWknTgy/+0EB4kHszp9SWRAFDKxn7ifNiULaj bg3tbc15Ps71NNfAYlwzRmyxl+uLfzRxzA+m6LtJ3IGzotMQ4p7BwjIdZSYpE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id C68CEBBA05F; Tue, 15 Jul 2014 16:13:10 -0700 (PDT) Date: Tue, 15 Jul 2014 18:13:10 -0500 From: Nico Williams To: John Cowan Message-ID: <20140715231308.GA3896@localhost> References: <20140715063853.GE2256@localhost> <20140715070614.GH10065@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140715070614.GH10065@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/OdOTS381GZ-zKIJodukkgIfurgw Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 23:13:13 -0000 On Tue, Jul 15, 2014 at 03:06:14AM -0400, John Cowan wrote: > Nico Williams scripsit: > > > and considering that if we used RS a logger would still have to check > > that a text to be logged does not include RS,... > > How so? JSON cannot contain unescaped RS; an RS in a string must > appear as \u001F. But if a logger is just logging a string purported to be a JSON text, then it has to validate. OTOH, if the logger is logging a JSON _value_ then it can trivially encode with no newlines (or remove/map them). From nobody Tue Jul 15 16:13:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F91B29C1 for ; Tue, 15 Jul 2014 16:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB4AV3Wdl4eT for ; Tue, 15 Jul 2014 16:13:35 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFF61B29BF for ; Tue, 15 Jul 2014 16:13:35 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id DD63535005B; Tue, 15 Jul 2014 16:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=dpT42kmnnN5EZW ltkAORXoaqCbk=; b=xJ/GPbJ9ysfONi/p7eLc00iTj0VBnlzgiADVBzrrhMS9Ti XLXEvCf0LD5fwQQof0T/uEnk7Pk5OS6ddNj+TuMW/ld7khdhU+hS0At2c+jrpE4h tLFxE82L+nfM81leWKH1vtMlgEUr5AQNuI9Chx8Z1RR+9KqiPVTYCx+QNvF2o= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 8D08B350058; Tue, 15 Jul 2014 16:13:34 -0700 (PDT) Date: Tue, 15 Jul 2014 18:13:33 -0500 From: Nico Williams To: Paul Hoffman Message-ID: <20140715231332.GB3896@localhost> References: <255B9BB34FB7D647A506DC292726F6E11549A8F764@WSMSG3153V.srv.dir.telstra.com> <20140715063023.GB2256@localhost> <8F609FAA-11AA-45F2-A186-CD0ED06A8559@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F609FAA-11AA-45F2-A186-CD0ED06A8559@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/_BWGNrhRZPEZlgI2Ry3aFFnAuqI Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 15 Jul 2014 23:13:35 -0000 On Tue, Jul 15, 2014 at 06:16:13AM -0700, Paul Hoffman wrote: > Nico: The poll was meant as a poll, not a discussion. As you know, the > poll said: Oops. What now? From nobody Wed Jul 16 07:45:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783561B29CE for ; Wed, 16 Jul 2014 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s6gEckJv6eh for ; Wed, 16 Jul 2014 07:45:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7653A1B28AB for ; Wed, 16 Jul 2014 07:45:15 -0700 (PDT) Received: from Vostro3500 ([188.216.226.67]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlUZz-1WWhvb40Ax-00bJZS; Wed, 16 Jul 2014 16:45:13 +0200 From: "Markus Lanthaler" To: "'IETF JSON WG'" References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> In-Reply-To: Date: Wed, 16 Jul 2014 16:45:08 +0200 Message-ID: <02d801cfa104$8cdda1f0$a698e5d0$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKov2vhk56OUbYXKcowgYH+SabU7AKM8BuiAidkqSIBftnvzpm+8Bzw Content-Language: de X-Provags-ID: V03:K0:kXGfeUFUoFZJUllgwlcrzK726B2hY19w2AK/DyQPlklz7i2UpgD J4b3D88ThDZxjD3l77R/HnitNMn8DQLIFFITgVKdi4804mMzfpL5aiDmmYK1AXL+uxpMwmg 3N0COOmUTn4CXHRTJMCn+Hc/cl4Kq4F7DyXAtjzhblHRGjRORM2KdfN04SuKxOAkembeffY aMLwgdmUKurfd0L+LVHlw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/J-afAQPSq6gtK1VZwU5ioYdmRxU Cc: 'Tim Bray' Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 14:45:20 -0000 On Tuesday, July 15, 2014 4:40 PM, Tim Bray wrote: > Is there an example of such a profile proving useful to application > builders? Haven=E2=80=99t encountered one myself but I assume there = must be > some out there. We defined some profiles for JSON-LD [1] which make it possible for app = developers to request the data to be serialized in a specific way (there = are typically multiple ways to serialize the same graph). > On Mon, Jul 14, 2014 at 1:58 PM, Markus Lanthaler = wrote: > On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote: > > Note that Working Group Last Call ends on Monday (07/14). What has > > been brought to the list to date is: > > > > * correction on the reference to RFC 7149 (should be RFC 7159) > > * some discussion about a profile URL > > > > We want to hear from as many as possible, even if the comment is > > "looks good to me". > As already said, I think it would be a good idea to mint and register = a > profile URI.=20 [1] http://www.w3.org/TR/json-ld/#iana-considerations -- Markus Lanthaler @markuslanthaler From nobody Wed Jul 16 07:54:36 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7031B28AD for ; Wed, 16 Jul 2014 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ17wO5lWDHs for ; Wed, 16 Jul 2014 07:54:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14E41B28AB for ; Wed, 16 Jul 2014 07:54:30 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so1909103vcb.3 for ; Wed, 16 Jul 2014 07:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pDaQJaORIY1/qskRY480zSsgByxKfWmmXVDtj1oEFuQ=; b=YDsI3sOzpuqowA1pzq4PiYOIwbMYRpo/iuiCCikV1xAUAS0qepTAlX0CPf2SOVxVOx gQDn0hvoR+IqNfrdGBlhC27KPhyxlPGwfTRbO/Fekmk+Jp66gyPNpWoCeoab7A9NyY+N 1D9h/AxXA/c55EooJoV7O9IUFgtn5BKh2U5PO07W3PT0efAujJ//1Gwv/RFiDzYLJjvH qWUnbBFsgaQzhGHFx4B/mBOPL+9TxuZUyfkgR6w/abhjRIpRFz2pAV3QAkktwk/2xJG2 GgT8dmP9bofAVPjnfadaYC/Ye6wU0V4mLS13G+BHKyJ27G+xnJn5L7AW3MHqzbbBf0xh +NWQ== X-Gm-Message-State: ALoCoQnLB540fFJkqnpvxZa5rpTiU7lkrevmludvmTSSVa+R/kYJQuOChyNonh8ShYlxgcyKPS3Y X-Received: by 10.52.241.43 with SMTP id wf11mr7140090vdc.69.1405522469495; Wed, 16 Jul 2014 07:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Wed, 16 Jul 2014 07:54:09 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <02d801cfa104$8cdda1f0$a698e5d0$@gmx.net> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <0c3601cf9fa6$6f79bb30$4e6d3190$@gmx.net> <02d801cfa104$8cdda1f0$a698e5d0$@gmx.net> From: Tim Bray Date: Wed, 16 Jul 2014 07:54:09 -0700 Message-ID: To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a1133f95884bb3304fe50b335 Archived-At: http://mailarchive.ietf.org/arch/msg/json/XgvLNLkpHcEEiDdRoRwC7NX5KP4 Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 14:54:33 -0000 --001a1133f95884bb3304fe50b335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2014 at 7:45 AM, Markus Lanthaler wrote: > On Tuesday, July 15, 2014 4:40 PM, Tim Bray wrote: > > Is there an example of such a profile proving useful to application > > builders? > We defined some profiles for JSON-LD [1] which make it possible for app > developers to request the data to be serialized in a specific way (there > are typically multiple ways to serialize the same graph). > =E2=80=8BThat=E2=80=99s nice in theory; are there any actual real applicati= ons that actual real people actually really use that derive any benefit from this?=E2=80=8B > > > > On Mon, Jul 14, 2014 at 1:58 PM, Markus Lanthaler < > markus.lanthaler@gmx.net> wrote: > > On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote: > > > Note that Working Group Last Call ends on Monday (07/14). What has > > > been brought to the list to date is: > > > > > > * correction on the reference to RFC 7149 (should be RFC 7159) > > > * some discussion about a profile URL > > > > > > We want to hear from as many as possible, even if the comment is > > > "looks good to me". > > As already said, I think it would be a good idea to mint and register a > > profile URI. > > [1] http://www.w3.org/TR/json-ld/#iana-considerations > > > -- > Markus Lanthaler > @markuslanthaler > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1133f95884bb3304fe50b335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Wed, Jul 16, 2014 at 7:45 AM, Markus Lanthaler <markus.lanthaler@gm= x.net> wrote:
On Tuesday, July 15, 2014 4:40 PM, Tim Bray= wrote:
> Is there an example of such a profile proving useful to application > builders?
We defined some profiles for JSON-LD [1] which make it possible for a= pp developers to request the data to be serialized in a specific way (there= are typically multiple ways to serialize the same graph).

= =E2=80=8BThat=E2=80=99s nice in theory; are there any actual real applicati= ons that actual real people actually really use that derive any benefit fro= m this?=E2=80=8B


=C2=A0


> On Mon, Jul 14, 2014 at 1:58 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
> On Saturday, July 12, 2014 12:35 AM, Matt Miller wrote:
> > Note that Working Group Last Call ends on Monday (07/14). =C2=A0W= hat has
> > been brought to the list to date is:
> >
> > * correction on the reference to RFC 7149 (should be RFC 7159) > > * some discussion about a profile URL
> >
> > We want to hear from as many as possible, even if the comment is<= br> > > "looks good to me".
> As already said, I think it would be a good idea to mint and register = a
> profile URI.

[1] http://www.w3.org/TR/json-ld/#iana-considerations


--
Markus Lanthaler
@markuslanthaler




--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a1133f95884bb3304fe50b335-- From nobody Wed Jul 16 12:20:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9151A0190 for ; Wed, 16 Jul 2014 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUIiWLD3Q66P for ; Wed, 16 Jul 2014 12:02:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9541A01D5 for ; Wed, 16 Jul 2014 12:02:49 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 16 Jul 2014 19:02:42 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0985.008; Wed, 16 Jul 2014 19:02:42 +0000 From: Larry Masinter To: Tim Bray Thread-Topic: [Json] Working Group Last Call on draft-ietf-i-json-02 Thread-Index: AQHPlNXlZXjIN4zZsUWNV5uEVDZbg5ubhyYAgAAR0ACAABhQgIAHdhhQ Date: Wed, 16 Jul 2014 19:02:41 +0000 Message-ID: <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2600:100f:b106:e0b8::103] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(199002)(377454003)(52044002)(24454002)(189002)(101416001)(64706001)(21056001)(74502001)(31966008)(81342001)(46102001)(92566001)(106116001)(106356001)(15975445006)(99396002)(54356999)(85306003)(74662001)(76482001)(95246002)(33646002)(80022001)(50986999)(19617315012)(76176999)(105586002)(15202345003)(20776003)(110136001)(92726001)(83072002)(85852003)(107046002)(79102001)(81542001)(19580395003)(93886003)(16236675004)(83322001)(87936001)(4396001)(86362001)(99286002)(77982001)(16601075003)(19580405001)(95666004)(2656002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3b1rk4x0d2dwsnvbr0w1wjya1405535654838emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/QOAZzXl6JvbjFaSm_ivryOBxKt4 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 19:02:52 -0000 --_000_3b1rk4x0d2dwsnvbr0w1wjya1405535654838emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think at least one motivating use case is called for, if not more. But scanning the JOSE documents, I didn't find where you would use I-JSON i= nstead. Could you point it out? Tim Bray wrote: Well, I think this discussion sort of already happened, but here's the exis= tence proof: If I-JSON had existed at the time JOSE was getting going, they= could have simplified their specs, and implementers' lives, with the follo= wing statement: Use I-JSON. Also, the collection of constraints IS special: It covers everything that 7= 159 calls out as an interoperability problem, and says "don't do that'. On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter > wrote: > > Please review the document and send comments to the Working > > Group mailing list < json at ietf.org > or the co-chai= rs > tools.ietf.org > before the end of the WGLC. An= y and all comments > > on the document are sought in order to asses the strength of > > consensus. Even if you have read and commented on this or earlier > > versions of the draft, please feel free to comment again. I think I originally supported the development of I-JSON as useful named profile of JSON. However, based on recent discussions and further examination, my opinion now is that the particular collection of constraints isn't special, and the document should instead be recast as a "Best Practices for Internet Use of JSON". To facilitate using the document as a normative reference, each constraint/best practice could be named "no-dup-names", "ieee-numbers", "utf8". If you then want to name the union of all constraints in the document as "i-json" that would be OK. Most of the document (including the normative language associated with each constraint) would remain, but the emphasis on "i-json" as a unique and complete profile wouldn't, and would make it easier for referencing applications to choose those constraints that are meaningful for them. Larry -- http://larry.masinter.net _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json -- - Tim Bray (If you'd like to send me a private message, see https://keybase= .io/timbray) --_000_3b1rk4x0d2dwsnvbr0w1wjya1405535654838emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think at least one motivating use case is called for, if not more.

But scanning the JOSE documents, I didn't find where you would use I-J= SON instead. Could you point it out?


Tim Bray <tbray@textuality.com> wrote:

Well, I think this d= iscussion sort of already happened, but here’s the existence proof: I= f I-JSON had existed at the time JOSE was getting going, they could have si= mplified their specs, and implementers’ lives, with the following statement: Use I-JSON.

Also, the collection= of constraints IS special: It covers everything that 7159 calls out as an = interoperability problem, and says “don’t do that’.


On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter = <masinter@adobe.= com> wrote:
> > Please review the document and send comments to t= he Working
> > Group mailing list < json at ietf.org > or the co-chairs <json-chairs at
> > tools.ietf.or= g > before the end of the WGLC.  Any and all comments
> > on the document are sought in order to asses the strength of
> > consensus. Even if you have read and commented on this or earlier=
> > versions of the draft, please feel free to comment again.

I think I originally supported the development of I-JSON as
useful named profile of JSON. However, based on recent discussions
and further examination, my opinion now is that the particular
collection of constraints isn't special, and the document should
instead be recast as a "Best Practices for Internet Use of JSON".=
To facilitate using the document as a normative reference, each
constraint/best practice could be named "no-dup-names",
"ieee-numbers", "utf8". If you then want to name the un= ion
of all constraints in the document as "i-json" that would be OK.<= br>
Most of the document (including the normative language
associated with each constraint) would remain, but the emphasis
on "i-json" as a unique and complete profile wouldn't, and
would make it easier for referencing applications to choose
those constraints that are meaningful for them.

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


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



--
- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
--_000_3b1rk4x0d2dwsnvbr0w1wjya1405535654838emailandroidcom_-- From nobody Wed Jul 16 12:20:55 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178C51A01EB for ; Wed, 16 Jul 2014 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkx6hKVER4UL for ; Wed, 16 Jul 2014 12:16:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D031A01E8 for ; Wed, 16 Jul 2014 12:16:06 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so2627086vcb.17 for ; Wed, 16 Jul 2014 12:16:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XffxWpMW690RuL1+oOkE/DntSFTJ3uwcCj5ZPOnMxdQ=; b=UHZESyaPVMVt6BqFWuRy32US8oIsdfPIvh3ORlLV2GEA8+9hghfVcfQC0L1IaxN4CJ 9GEBHHyyJtyG815vIObKl18Pk0xnMoQc5417odPS1lGLJWyIW+IEBnImd0Zb8IIJ6OLg ngchKbspZiv+bijJI/IWrofFOn5sRpQ+F+xUp3B8mG4akXvdST1ljErCf5a+cXBJezK9 weaIjbUlGEzZbdp0SKSYIdo2LZB7u9J1jJp/1Fd3scAUHxyIRjLnxEFV9F4PCGLxodiB pdW30pjh29X4LWMDBVjZMfNip4TC23w2qAXtMQnfg+zFIuonRXHX65I6k/PAmKcCSoaG Mlpg== X-Gm-Message-State: ALoCoQlES4hKfZ8DJWsbXg8SBsa0t85zMlpuEuC9wQELw8YOuw2WWDbYvoOLHAJKSR1zpn8JFEIE X-Received: by 10.221.42.135 with SMTP id ty7mr32364687vcb.14.1405538165386; Wed, 16 Jul 2014 12:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Wed, 16 Jul 2014 12:15:45 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> From: Tim Bray Date: Wed, 16 Jul 2014 12:15:45 -0700 Message-ID: To: Larry Masinter Content-Type: multipart/alternative; boundary=001a11339974110ae604fe545b33 Archived-At: http://mailarchive.ietf.org/arch/msg/json/LZLOEfOzF-xx_MZTCRCs6-PIOSM Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 16 Jul 2014 19:16:08 -0000 --001a11339974110ae604fe545b33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For example, http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-4 If I-JSON were published, they=E2=80=99d switch to it in the blink of an ey= e, based on previous conversations. On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter wrote= : > I think at least one motivating use case is called for, if not more. > > But scanning the JOSE documents, I didn't find where you would use > I-JSON instead. Could you point it out? > > > Tim Bray wrote: > > Well, I think this discussion sort of already happened, but here=E2=80= =99s the > existence proof: If I-JSON had existed at the time JOSE was getting going= , > they could have simplified their specs, and implementers=E2=80=99 lives, = with the > following statement: Use I-JSON. > > Also, the collection of constraints IS special: It covers everything > that 7159 calls out as an interoperability problem, and says =E2=80=9Cdon= =E2=80=99t do > that=E2=80=99. > > > On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter > wrote: > >> > > Please review the document and send comments to the Working >> > > Group mailing list < json at ietf.org > or the co-chairs >> > > > tools.ietf.org > before the end of the WGLC. Any and all comments >> > > on the document are sought in order to asses the strength of >> > > consensus. Even if you have read and commented on this or earlier >> > > versions of the draft, please feel free to comment again. >> >> I think I originally supported the development of I-JSON as >> useful named profile of JSON. However, based on recent discussions >> and further examination, my opinion now is that the particular >> collection of constraints isn't special, and the document should >> instead be recast as a "Best Practices for Internet Use of JSON". >> To facilitate using the document as a normative reference, each >> constraint/best practice could be named "no-dup-names", >> "ieee-numbers", "utf8". If you then want to name the union >> of all constraints in the document as "i-json" that would be OK. >> >> Most of the document (including the normative language >> associated with each constraint) would remain, but the emphasis >> on "i-json" as a unique and complete profile wouldn't, and >> would make it easier for referencing applications to choose >> those constraints that are meaningful for them. >> >> Larry >> -- >> http://larry.masinter.net >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11339974110ae604fe545b33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For= example,=C2=A0http://tools.ietf.org/html/draft-iet= f-jose-json-web-key-31#section-4

If I-JSON were published, they= =E2=80=99d switch to it in the blink of an eye, based on previous conversat= ions.


On Wed, Jul 1= 6, 2014 at 12:02 PM, Larry Masinter <masinter@adobe.com> wr= ote:
I think at least one motivating use case is called for, if not more.

But scanning the JOSE documents, I didn't find where you would use= I-JSON instead. Could you point it out?


Tim Bray <tbra= y@textuality.com> wrote:

Well, I think this d= iscussion sort of already happened, but here=E2=80=99s the existence proof:= If I-JSON had existed at the time JOSE was getting going, they could have = simplified their specs, and implementers=E2=80=99 lives, with the following statement: Use I-JSON.

Also, the collection= of constraints IS special: It covers everything that 7159 calls out as an = interoperability problem, and says =E2=80=9Cdon=E2=80=99t do that=E2=80=99.=


On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter = <masinter@adobe.= com> wrote:
> > Please review the document and send comments to the Working<= br> > > Group mailing list < json at ietf.org > or the co-chairs <json-chairs at
> > tools.ietf.or= g > before the end of the WGLC. =C2=A0Any and all comments
> > on the document are sought in order to asses the strength of
> > consensus. Even if you have read and commented on this or earlier=
> > versions of the draft, please feel free to comment again.

I think I originally supported the development of I-JSON as
useful named profile of JSON. However, based on recent discussions
and further examination, my opinion now is that the particular
collection of constraints isn't special, and the document should
instead be recast as a "Best Practices for Internet Use of JSON".=
To facilitate using the document as a normative reference, each
constraint/best practice could be named "no-dup-names",
"ieee-numbers", "utf8". If you then want to name the un= ion
of all constraints in the document as "i-json" that would be OK.<= br>
Most of the document (including the normative language
associated with each constraint) would remain, but the emphasis
on "i-json" as a unique and complete profile wouldn't, and would make it easier for referencing applications to choose
those constraints that are meaningful for them.

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


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



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



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a11339974110ae604fe545b33-- From nobody Wed Jul 16 22:15:33 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898321A0645 for ; Wed, 16 Jul 2014 22:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwD-x7FXBS8b for ; Wed, 16 Jul 2014 22:15:31 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5DA1A0290 for ; Wed, 16 Jul 2014 22:15:31 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id CF29F1E05C; Wed, 16 Jul 2014 22:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mvheUC+swLmk1w +OfDTXo4XeqxU=; b=RLJqgiC/93wVzagGT/3ZByeaIrhP1S6M8yLLhof4Yjke7N mW+IVI400vCAO4hywnwrZ8k2mhsNRkdM89q7t2DQhQ3Bb1npF0kJJzHBzI5kLS5H VAI5ihE1NZmCp19+HZQkWqI67B/s2HWij+qmZxi+8SgrHqyuyyQHGVbhmZWl4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 7EC631E059; Wed, 16 Jul 2014 22:15:30 -0700 (PDT) Date: Thu, 17 Jul 2014 00:15:28 -0500 From: Nico Williams To: Paul Hoffman Message-ID: <20140717051527.GC3896@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/OuIb0eqQdL89fEMVb_Q89eh6wyw Cc: IETF JSON WG Subject: Re: [Json] The text in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 05:15:32 -0000 On Mon, Jul 07, 2014 at 01:57:45PM -0700, Paul Hoffman wrote: > - Do you feel that the protocol will be significantly broken if it > uses LF as the text separator? Not in the least. > - Do you feel that the protocol will be significantly broken if it uses RS as the text separator? No, but it will be inconvenient. > - Do you feel that using LF or RF as the text separator is essentially the same for the protocol? Yes, except that LF is much more convenient. Nico -- From nobody Thu Jul 17 13:18:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAAA1A017C for ; Thu, 17 Jul 2014 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_2Bugk9rDLN for ; Thu, 17 Jul 2014 13:18:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBF91A00AA for ; Thu, 17 Jul 2014 13:18:38 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 17 Jul 2014 20:18:30 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Thu, 17 Jul 2014 20:18:30 +0000 From: Larry Masinter To: Tim Bray Thread-Topic: [Json] Working Group Last Call on draft-ietf-i-json-02 Thread-Index: AQHPlNXlZXjIN4zZsUWNV5uEVDZbg5ubhyYAgAAR0ACAABhQgIAHdhhQgAADpYCAAaFlgA== Date: Thu, 17 Jul 2014 20:18:29 +0000 Message-ID: References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [97.94.246.70] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(52044002)(51704005)(189002)(199002)(24454002)(19617315012)(85306003)(81342001)(83072002)(93886003)(50986999)(110136001)(15975445006)(83322001)(19580405001)(15202345003)(74662001)(54356999)(74316001)(76176999)(107046002)(87936001)(19609705001)(31966008)(2656002)(16601075003)(74502001)(85852003)(81542001)(92566001)(95666004)(80022001)(66066001)(16236675004)(77982001)(79102001)(106116001)(20776003)(21056001)(106356001)(19625215002)(46102001)(86362001)(76576001)(33646002)(19300405004)(99286002)(101416001)(99396002)(64706001)(4396001)(105586002)(76482001)(19580395003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f44a34b22e4c42dc8f6164d8ece5a934BL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/d1rZhP8VpBIPofOrzQVYWH8lbg0 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 20:18:40 -0000 --_000_f44a34b22e4c42dc8f6164d8ece5a934BL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIG5vdGhpbmcgaW4gdGhhdCBzZWN0aW9uIGFib3V0IElFRUUgZmxvYXRpbmcgcG9p bnQgKG9yIGFueXdoZXJlIGVsc2UgaW4gSk9TRSB0aGF0IEkgY2FuIGZpbmQuIEFuZCBpLWpzb24g ZG9lc27igJl0IHNheSBhbnl0aGluZyBhYm91dCBjYW5vbmljYWxpemF0aW9uLCB3aGljaCB3b3Vs ZCBsaWtlbHkgYmUgd2hhdCBKT1NFIG5lZWRzLg0KDQrigJx0aGV54oCZZCBzd2l0Y2ggdG8gaXQg aW4gdGhlIGJsaW5rIG9mIGFuIGV5ZeKAnSBzZWVtcyBsaWtlIGFuIHVuZGVyZXN0aW1hdGUgYnkg c2V2ZXJhbCBvcmRlcnMgb2YgbWFnbml0dWRlLg0KDQpNeSBwb2ludCBpcyB0aGF0IHRoZXJlIGlz IG5vIG9idmlvdXMgd2F5IHRoYXQgSk9TRSBjb3VsZCBtYWtlIG5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gdGhlIGktanNvbiBkb2N1bWVudCBhcyBpdCBzdGFuZHMsIGV2ZW4gaWYgZXZlcnlvbmUgYWdy ZWVkIHRvIGl0IChidXQgYWdyZWVtZW50IHdvdWxkIGRlcGVuZCBvbiB0aGUgZGV0YWlscyBvZiB3 aGF0IHRoZSByZWZlcmVuY2Ugc2FpZCkuDQoNCkZyb206IFRpbSBCcmF5IFttYWlsdG86dGJyYXlA dGV4dHVhbGl0eS5jb21dDQpzU2VudDogV2VkbmVzZGF5LCBKdWx5IDE2LCAyMDE0IDEyOjE2IFBN DQpUbzogTGFycnkgTWFzaW50ZXINCkNjOiBNYXR0IE1pbGxlcjsgSUVURiBKU09OIFdHDQpTdWJq ZWN0OiBSZTogW0pzb25dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtaS1q c29uLTAyDQoNCkZvciBleGFtcGxlLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxI3NlY3Rpb24tNA0KDQpJZiBJLUpTT04gd2VyZSBwdWJs aXNoZWQsIHRoZXnigJlkIHN3aXRjaCB0byBpdCBpbiB0aGUgYmxpbmsgb2YgYW4gZXllLCBiYXNl ZCBvbiBwcmV2aW91cyBjb252ZXJzYXRpb25zLg0KDQpPbiBXZWQsIEp1bCAxNiwgMjAxNCBhdCAx MjowMiBQTSwgTGFycnkgTWFzaW50ZXIgPG1hc2ludGVyQGFkb2JlLmNvbTxtYWlsdG86bWFzaW50 ZXJAYWRvYmUuY29tPj4gd3JvdGU6DQpJIHRoaW5rIGF0IGxlYXN0IG9uZSBtb3RpdmF0aW5nIHVz ZSBjYXNlIGlzIGNhbGxlZCBmb3IsIGlmIG5vdCBtb3JlLg0KDQpCdXQgc2Nhbm5pbmcgdGhlIEpP U0UgZG9jdW1lbnRzLCBJIGRpZG4ndCBmaW5kIHdoZXJlIHlvdSB3b3VsZCB1c2UgSS1KU09OIGlu c3RlYWQuIENvdWxkIHlvdSBwb2ludCBpdCBvdXQ/DQoNCg0KVGltIEJyYXkgPHRicmF5QHRleHR1 YWxpdHkuY29tPG1haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNvbT4+IHdyb3RlOg0KV2VsbCwgSSB0 aGluayB0aGlzIGRpc2N1c3Npb24gc29ydCBvZiBhbHJlYWR5IGhhcHBlbmVkLCBidXQgaGVyZeKA mXMgdGhlIGV4aXN0ZW5jZSBwcm9vZjogSWYgSS1KU09OIGhhZCBleGlzdGVkIGF0IHRoZSB0aW1l IEpPU0Ugd2FzIGdldHRpbmcgZ29pbmcsIHRoZXkgY291bGQgaGF2ZSBzaW1wbGlmaWVkIHRoZWly IHNwZWNzLCBhbmQgaW1wbGVtZW50ZXJz4oCZIGxpdmVzLCB3aXRoIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50OiBVc2UgSS1KU09OLg0KDQpBbHNvLCB0aGUgY29sbGVjdGlvbiBvZiBjb25zdHJhaW50 cyBJUyBzcGVjaWFsOiBJdCBjb3ZlcnMgZXZlcnl0aGluZyB0aGF0IDcxNTkgY2FsbHMgb3V0IGFz IGFuIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbSwgYW5kIHNheXMg4oCcZG9u4oCZdCBkbyB0aGF0 4oCZLg0KDQpPbiBGcmksIEp1bCAxMSwgMjAxNCBhdCA0OjUxIFBNLCBMYXJyeSBNYXNpbnRlciA8 bWFzaW50ZXJAYWRvYmUuY29tPG1haWx0bzptYXNpbnRlckBhZG9iZS5jb20+PiB3cm90ZToNCj4g PiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgV29y a2luZw0KPiA+IEdyb3VwIG1haWxpbmcgbGlzdCA8IGpzb24gYXQgaWV0Zi5vcmc8aHR0cDovL2ll dGYub3JnPiA+IG9yIHRoZSBjby1jaGFpcnMgPGpzb24tY2hhaXJzIGF0DQo+ID4gdG9vbHMuaWV0 Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPiA+IGJlZm9yZSB0aGUgZW5kIG9mIHRoZSBXR0xD LiAgQW55IGFuZCBhbGwgY29tbWVudHMNCj4gPiBvbiB0aGUgZG9jdW1lbnQgYXJlIHNvdWdodCBp biBvcmRlciB0byBhc3NlcyB0aGUgc3RyZW5ndGggb2YNCj4gPiBjb25zZW5zdXMuIEV2ZW4gaWYg eW91IGhhdmUgcmVhZCBhbmQgY29tbWVudGVkIG9uIHRoaXMgb3IgZWFybGllcg0KPiA+IHZlcnNp b25zIG9mIHRoZSBkcmFmdCwgcGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50IGFnYWluLg0KSSB0 aGluayBJIG9yaWdpbmFsbHkgc3VwcG9ydGVkIHRoZSBkZXZlbG9wbWVudCBvZiBJLUpTT04gYXMN CnVzZWZ1bCBuYW1lZCBwcm9maWxlIG9mIEpTT04uIEhvd2V2ZXIsIGJhc2VkIG9uIHJlY2VudCBk aXNjdXNzaW9ucw0KYW5kIGZ1cnRoZXIgZXhhbWluYXRpb24sIG15IG9waW5pb24gbm93IGlzIHRo YXQgdGhlIHBhcnRpY3VsYXINCmNvbGxlY3Rpb24gb2YgY29uc3RyYWludHMgaXNuJ3Qgc3BlY2lh bCwgYW5kIHRoZSBkb2N1bWVudCBzaG91bGQNCmluc3RlYWQgYmUgcmVjYXN0IGFzIGEgIkJlc3Qg UHJhY3RpY2VzIGZvciBJbnRlcm5ldCBVc2Ugb2YgSlNPTiIuDQpUbyBmYWNpbGl0YXRlIHVzaW5n IHRoZSBkb2N1bWVudCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIGVhY2gNCmNvbnN0cmFpbnQv YmVzdCBwcmFjdGljZSBjb3VsZCBiZSBuYW1lZCAibm8tZHVwLW5hbWVzIiwNCiJpZWVlLW51bWJl cnMiLCAidXRmOCIuIElmIHlvdSB0aGVuIHdhbnQgdG8gbmFtZSB0aGUgdW5pb24NCm9mIGFsbCBj b25zdHJhaW50cyBpbiB0aGUgZG9jdW1lbnQgYXMgImktanNvbiIgdGhhdCB3b3VsZCBiZSBPSy4N Cg0KTW9zdCBvZiB0aGUgZG9jdW1lbnQgKGluY2x1ZGluZyB0aGUgbm9ybWF0aXZlIGxhbmd1YWdl DQphc3NvY2lhdGVkIHdpdGggZWFjaCBjb25zdHJhaW50KSB3b3VsZCByZW1haW4sIGJ1dCB0aGUg ZW1waGFzaXMNCm9uICJpLWpzb24iIGFzIGEgdW5pcXVlIGFuZCBjb21wbGV0ZSBwcm9maWxlIHdv dWxkbid0LCBhbmQNCndvdWxkIG1ha2UgaXQgZWFzaWVyIGZvciByZWZlcmVuY2luZyBhcHBsaWNh dGlvbnMgdG8gY2hvb3NlDQp0aG9zZSBjb25zdHJhaW50cyB0aGF0IGFyZSBtZWFuaW5nZnVsIGZv ciB0aGVtLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KanNvbiBtYWlsaW5n IGxpc3QNCmpzb25AaWV0Zi5vcmc8bWFpbHRvOmpzb25AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCg0KDQoNCi0tDQotIFRpbSBCcmF5IChJZiB5 b3XigJlkIGxpa2UgdG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwgc2VlIGh0dHBzOi8va2V5 YmFzZS5pby90aW1icmF5KQ0KDQoNCg0KLS0NCi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0 byBzZW5kIG1lIGEgcHJpdmF0ZSBtZXNzYWdlLCBzZWUgaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJy YXkpDQo= --_000_f44a34b22e4c42dc8f6164d8ece5a934BL2PR02MB307namprd02pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJl4oCZcyBub3RoaW5nIGluIHRoYXQg c2VjdGlvbiBhYm91dCBJRUVFIGZsb2F0aW5nIHBvaW50IChvciBhbnl3aGVyZSBlbHNlIGluIEpP U0UgdGhhdCBJIGNhbiBmaW5kLiBBbmQgaS1qc29uIGRvZXNu4oCZdCBzYXkgYW55dGhpbmcgYWJv dXQgY2Fub25pY2FsaXphdGlvbiwNCiB3aGljaCB3b3VsZCBsaWtlbHkgYmUgd2hhdCBKT1NFIG5l ZWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+4oCcdGhleeKAmWQgc3dpdGNoIHRvIGl0IGluIHRoZSBibGluayBvZiBh biBleWXigJ0gc2VlbXMgbGlrZSBhbiB1bmRlcmVzdGltYXRlIGJ5IHNldmVyYWwgb3JkZXJzIG9m IG1hZ25pdHVkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHBvaW50IGlzIHRoYXQgdGhlcmUgaXMgbm8gb2J2aW91 cyB3YXkgdGhhdCBKT1NFIGNvdWxkIG1ha2Ugbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUgaS1q c29uIGRvY3VtZW50IGFzIGl0IHN0YW5kcywgZXZlbiBpZiBldmVyeW9uZSBhZ3JlZWQgdG8gaXQg KGJ1dCBhZ3JlZW1lbnQNCiB3b3VsZCBkZXBlbmQgb24gdGhlIGRldGFpbHMgb2Ygd2hhdCB0aGUg cmVmZXJlbmNlIHNhaWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaW0gQnJheSBbbWFpbHRvOnRicmF5 QHRleHR1YWxpdHkuY29tXQ0KPGJyPg0KPGI+c1NlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMTYs IDIwMTQgMTI6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IExhcnJ5IE1hc2ludGVyPGJyPg0KPGI+Q2M6 PC9iPiBNYXR0IE1pbGxlcjsgSUVURiBKU09OIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb SnNvbl0gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1pLWpzb24tMDI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsJm5i c3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLWtleS0zMSNzZWN0aW9uLTQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxI3NlY3Rpb24tNDwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg SS1KU09OIHdlcmUgcHVibGlzaGVkLCB0aGV54oCZZCBzd2l0Y2ggdG8gaXQgaW4gdGhlIGJsaW5r IG9mIGFuIGV5ZSwgYmFzZWQgb24gcHJldmlvdXMgY29udmVyc2F0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gV2VkLCBKdWwgMTYsIDIwMTQgYXQgMTI6MDIgUE0sIExhcnJ5IE1hc2ludGVyICZs dDs8YSBocmVmPSJtYWlsdG86bWFzaW50ZXJAYWRvYmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFz aW50ZXJAYWRvYmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgYXQgbGVhc3Qgb25lIG1vdGl2YXRpbmcg dXNlIGNhc2UgaXMgY2FsbGVkIGZvciwgaWYgbm90IG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBzY2FubmluZyB0aGUgSk9TRSBk b2N1bWVudHMsIEkgZGlkbid0IGZpbmQgd2hlcmUgeW91IHdvdWxkIHVzZSBJLUpTT04gaW5zdGVh ZC4gQ291bGQgeW91IHBvaW50IGl0IG91dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KPGJyPg0KVGltIEJyYXkgJmx0OzxhIGhyZWY9Im1haWx0bzp0YnJheUB0 ZXh0dWFsaXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRicmF5QHRleHR1YWxpdHkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZWxsLCBJIHRoaW5rIHRoaXMgZGlzY3Vzc2lvbiBzb3J0IG9mIGFscmVhZHkg aGFwcGVuZWQsIGJ1dCBoZXJl4oCZcyB0aGUgZXhpc3RlbmNlIHByb29mOiBJZiBJLUpTT04gaGFk IGV4aXN0ZWQgYXQgdGhlIHRpbWUgSk9TRSB3YXMgZ2V0dGluZyBnb2luZywgdGhleSBjb3VsZCBo YXZlIHNpbXBsaWZpZWQgdGhlaXIgc3BlY3MsIGFuZCBpbXBsZW1lbnRlcnPigJkgbGl2ZXMsIHdp dGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQogVXNlIEktSlNPTi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdGhlIGNvbGxlY3Rp b24gb2YgY29uc3RyYWludHMgSVMgc3BlY2lhbDogSXQgY292ZXJzIGV2ZXJ5dGhpbmcgdGhhdCA3 MTU5IGNhbGxzIG91dCBhcyBhbiBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW0sIGFuZCBzYXlzIOKA nGRvbuKAmXQgZG8gdGhhdOKAmS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1 bCAxMSwgMjAxNCBhdCA0OjUxIFBNLCBMYXJyeSBNYXNpbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1hc2ludGVyQGFkb2JlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hc2ludGVyQGFkb2JlLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7ICZndDsgUGxlYXNlIHJldmlldyB0aGUgZG9jdW1l bnQgYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIFdvcmtpbmc8YnI+DQomZ3Q7ICZndDsgR3JvdXAg bWFpbGluZyBsaXN0ICZsdDsganNvbiBhdCA8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZXRmLm9yZzwvYT4gJmd0OyBvciB0aGUgY28tY2hhaXJzICZsdDtqc29uLWNo YWlycyBhdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4gJmd0OyBiZWZvcmUgdGhlIGVuZCBvZiB0 aGUgV0dMQy4gJm5ic3A7QW55IGFuZCBhbGwgY29tbWVudHM8YnI+DQomZ3Q7ICZndDsgb24gdGhl IGRvY3VtZW50IGFyZSBzb3VnaHQgaW4gb3JkZXIgdG8gYXNzZXMgdGhlIHN0cmVuZ3RoIG9mPGJy Pg0KJmd0OyAmZ3Q7IGNvbnNlbnN1cy4gRXZlbiBpZiB5b3UgaGF2ZSByZWFkIGFuZCBjb21tZW50 ZWQgb24gdGhpcyBvciBlYXJsaWVyPGJyPg0KJmd0OyAmZ3Q7IHZlcnNpb25zIG9mIHRoZSBkcmFm dCwgcGxlYXNlIGZlZWwgZnJlZSB0byBjb21tZW50IGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkgb3JpZ2luYWxseSBzdXBwb3J0ZWQg dGhlIGRldmVsb3BtZW50IG9mIEktSlNPTiBhczxicj4NCnVzZWZ1bCBuYW1lZCBwcm9maWxlIG9m IEpTT04uIEhvd2V2ZXIsIGJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9uczxicj4NCmFuZCBmdXJ0 aGVyIGV4YW1pbmF0aW9uLCBteSBvcGluaW9uIG5vdyBpcyB0aGF0IHRoZSBwYXJ0aWN1bGFyPGJy Pg0KY29sbGVjdGlvbiBvZiBjb25zdHJhaW50cyBpc24ndCBzcGVjaWFsLCBhbmQgdGhlIGRvY3Vt ZW50IHNob3VsZDxicj4NCmluc3RlYWQgYmUgcmVjYXN0IGFzIGEgJnF1b3Q7QmVzdCBQcmFjdGlj ZXMgZm9yIEludGVybmV0IFVzZSBvZiBKU09OJnF1b3Q7Ljxicj4NClRvIGZhY2lsaXRhdGUgdXNp bmcgdGhlIGRvY3VtZW50IGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgZWFjaDxicj4NCmNvbnN0 cmFpbnQvYmVzdCBwcmFjdGljZSBjb3VsZCBiZSBuYW1lZCAmcXVvdDtuby1kdXAtbmFtZXMmcXVv dDssPGJyPg0KJnF1b3Q7aWVlZS1udW1iZXJzJnF1b3Q7LCAmcXVvdDt1dGY4JnF1b3Q7LiBJZiB5 b3UgdGhlbiB3YW50IHRvIG5hbWUgdGhlIHVuaW9uPGJyPg0Kb2YgYWxsIGNvbnN0cmFpbnRzIGlu IHRoZSBkb2N1bWVudCBhcyAmcXVvdDtpLWpzb24mcXVvdDsgdGhhdCB3b3VsZCBiZSBPSy48YnI+ DQo8YnI+DQpNb3N0IG9mIHRoZSBkb2N1bWVudCAoaW5jbHVkaW5nIHRoZSBub3JtYXRpdmUgbGFu Z3VhZ2U8YnI+DQphc3NvY2lhdGVkIHdpdGggZWFjaCBjb25zdHJhaW50KSB3b3VsZCByZW1haW4s IGJ1dCB0aGUgZW1waGFzaXM8YnI+DQpvbiAmcXVvdDtpLWpzb24mcXVvdDsgYXMgYSB1bmlxdWUg YW5kIGNvbXBsZXRlIHByb2ZpbGUgd291bGRuJ3QsIGFuZDxicj4NCndvdWxkIG1ha2UgaXQgZWFz aWVyIGZvciByZWZlcmVuY2luZyBhcHBsaWNhdGlvbnMgdG8gY2hvb3NlPGJyPg0KdGhvc2UgY29u c3RyYWludHMgdGhhdCBhcmUgbWVhbmluZ2Z1bCBmb3IgdGhlbS48YnI+DQo8YnI+DQpMYXJyeTxi cj4NCi0tPGJyPg0KPGEgaHJlZj0iaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQ8L2E+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KanNvbiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86anNvbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpzb25A aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9qc29uIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9qc29uPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRpbSBCcmF5IChJ ZiB5b3XigJlkIGxpa2UgdG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwgc2VlIDxhIGhyZWY9 Imh0dHBzOi8va2V5YmFzZS5pby90aW1icmF5IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2tl eWJhc2UuaW8vdGltYnJheTwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRpbSBCcmF5IChJZiB5b3XigJlkIGxpa2Ug dG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2FnZSwgc2VlIDxhIGhyZWY9Imh0dHBzOi8va2V5YmFz ZS5pby90aW1icmF5IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2tleWJhc2UuaW8vdGltYnJh eTwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_f44a34b22e4c42dc8f6164d8ece5a934BL2PR02MB307namprd02pro_-- From nobody Thu Jul 17 13:37:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7DA1A023F for ; Thu, 17 Jul 2014 13:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.047 X-Spam-Level: X-Spam-Status: No, score=-12.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdjQb73DLjsT for ; Thu, 17 Jul 2014 13:37:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466401A0218 for ; Thu, 17 Jul 2014 13:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4887; q=dns/txt; s=iport; t=1405629461; x=1406839061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x21baiH8ek1aW6ShxnCDvaZB1ZF3fW4LBDqq5Je4x/Y=; b=aCfWQbBV8yk7sCTnjAXG//LP28bde0zu4HbD2sDYT13Qk+8NSguFTy4K Ov9eNoWg/jZM3k1/2f0utQhQyTpq1fvTd0HRQOVWlqZSpuHBoLS57mWWF AYB3ww7yGQapR1L3wuMRdgq+OYayreh5h7aQQU+Ri7gxflNaTKfqWgeiD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMGALEwyFOtJV2c/2dsb2JhbABZgw5SVwSCdKohAQEBBQFulXUKhgCBQwGBBxZ2hAMBAQEEAQEBIA8BOwoBEAsVAgECAgUWCAMCAgkDAgECARUfCQgGAQwBBQIBAYg+Da4ylygXgSyET4kdMwcGgnKBTgWKZIwghBuBTIVIjRiDY02BRQ X-IronPort-AV: E=Sophos;i="5.01,680,1400025600"; d="scan'208";a="61768483" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 17 Jul 2014 20:37:40 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6HKbeLc021408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 20:37:40 GMT Received: from [10.89.8.151] (10.89.8.151) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 17 Jul 2014 15:37:40 -0500 Message-ID: <53C83403.6030809@cisco.com> Date: Thu, 17 Jul 2014 14:37:23 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Masinter , Tim Bray References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.89.8.151] Archived-At: http://mailarchive.ietf.org/arch/msg/json/ORwlVx3aIGbzxOeB1R_CWl7wopw Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 20:37:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 /me doffs hat. Speaking as an active participant of the JOSE WG since its charter: As far as I can tell, I-JSON contains everything that the JOSE WG has reached consensus on but is lacking from RFC 7159. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 7/17/14, 2:18 PM, Larry Masinter wrote: > There’s nothing in that section about IEEE floating point (or > anywhere else in JOSE that I can find. And i-json doesn’t say > anything about canonicalization, which would likely be what JOSE > needs. > > > > “they’d switch to it in the blink of an eye” seems like an > underestimate by several orders of magnitude. > > > > My point is that there is no obvious way that JOSE could make > normative reference to the i-json document as it stands, even if > everyone agreed to it (but agreement would depend on the details of > what the reference said). > > > > *From:*Tim Bray [mailto:tbray@textuality.com] *sSent:* Wednesday, > July 16, 2014 12:16 PM *To:* Larry Masinter *Cc:* Matt Miller; IETF > JSON WG *Subject:* Re: [Json] Working Group Last Call on > draft-ietf-i-json-02 > > > > For example, > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-4 > > > > > If I-JSON were published, they’d switch to it in the blink of an > eye, based on previous conversations. > > > > On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter > > wrote: > > I think at least one motivating use case is called for, if not > more. > > > > But scanning the JOSE documents, I didn't find where you would use > I-JSON instead. Could you point it out? > > > > Tim Bray > > wrote: > > Well, I think this discussion sort of already happened, but here’s > the existence proof: If I-JSON had existed at the time JOSE was > getting going, they could have simplified their specs, and > implementers’ lives, with the following statement: Use I-JSON. > > > > Also, the collection of constraints IS special: It covers > everything that 7159 calls out as an interoperability problem, and > says “don’t do that’. > > > > On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter > > wrote: > >>> Please review the document and send comments to the Working >>> Group mailing list < json at ietf.org > or > the co-chairs >> tools.ietf.org > before the end of > the WGLC. Any and all comments >>> on the document are sought in order to asses the strength of >>> consensus. Even if you have read and commented on this or > earlier >>> versions of the draft, please feel free to comment again. > > I think I originally supported the development of I-JSON as useful > named profile of JSON. However, based on recent discussions and > further examination, my opinion now is that the particular > collection of constraints isn't special, and the document should > instead be recast as a "Best Practices for Internet Use of JSON". > To facilitate using the document as a normative reference, each > constraint/best practice could be named "no-dup-names", > "ieee-numbers", "utf8". If you then want to name the union of all > constraints in the document as "i-json" that would be OK. > > Most of the document (including the normative language associated > with each constraint) would remain, but the emphasis on "i-json" as > a unique and complete profile wouldn't, and would make it easier > for referencing applications to choose those constraints that are > meaningful for them. > > Larry -- http://larry.masinter.net > > > > _______________________________________________ json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > > -- > > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) > > > > > > -- > > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTyDQDAAoJEDWi+S0W7cO1VtAH/3a/g4wCIX1RIcc3d9kyArAU +BueHk2g9M2yiOkdjsPOpZQhZ5N5KS4Egxt6i7R2/WhBisdwxmJ9HS8rzKLUDNCi FCDc2CXjF701qAj5fkBhQGOHCvRR58tnEW19xM4gYtG5WG27qus+8dF8FSJWYhOY UKc1k7wTrWlZRbjyzfPNuHWQbIMPEg9mhfMF7PtSqqkINv3Vao9gWTdYiwKM8NgP MagyMcuOg/vgC1wQpwwWhNSjMIRwGZkqUVLcG4du6OKFkxqy6EZFtPU+TdcAzgF2 QSuwtS29TzK1BUw04cqjKl+G2vIjrqwgxLPUY6dYpaiWpSMFbxjz6ESBUKznsZ8= =YTK7 -----END PGP SIGNATURE----- From nobody Thu Jul 17 15:11:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDD1A0334 for ; Thu, 17 Jul 2014 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvD3hn3Q11VU for ; Thu, 17 Jul 2014 15:11:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9295D1B2807 for ; Thu, 17 Jul 2014 15:11:21 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 17 Jul 2014 22:11:20 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Thu, 17 Jul 2014 22:11:20 +0000 From: Larry Masinter To: Matt Miller , Tim Bray Thread-Topic: [Json] Working Group Last Call on draft-ietf-i-json-02 Thread-Index: AQHPlNXlZXjIN4zZsUWNV5uEVDZbg5ubhyYAgAAR0ACAABhQgIAHdhhQgAADpYCAAaFlgIAAB7+AgAAVpqA= Date: Thu, 17 Jul 2014 22:11:19 +0000 Message-ID: <8a315f85c2704f2a828bdbd5f4ca09b7@BL2PR02MB307.namprd02.prod.outlook.com> References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> <53C83403.6030809@cisco.com> In-Reply-To: <53C83403.6030809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [97.94.246.70] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(52044002)(189002)(199002)(13464003)(24454002)(377454003)(479174003)(106116001)(20776003)(77982001)(79102001)(106356001)(21056001)(95666004)(92566001)(66066001)(80022001)(105586002)(4396001)(76482001)(19580395003)(33646002)(76576001)(46102001)(86362001)(64706001)(99286002)(99396002)(101416001)(19580405001)(575784001)(15202345003)(15975445006)(50986999)(76176999)(107046002)(54356999)(74662001)(74316001)(81342001)(85306003)(83072002)(93886003)(85852003)(74502001)(81542001)(87936001)(2656002)(16601075003)(31966008)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/json/f2kQmWaWmIQ12h_b-XFRbHOg2Y4 Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 17 Jul 2014 22:11:30 -0000 SSB0aGluayB5b3UncmUgc2F5aW5nIHRoZSBKT1NFIHdvcmtpbmcgZ3JvdXAgaGFzbid0IGFkZGVk IGFueSBzdWNoDQpjb25zdHJhaW50cyBpbiAzMSB2ZXJzaW9ucyBidXQgaGFzIHJvdWdoIGNvbnNl bnN1cywgYW5kIGFyZSBvbmx5IA0KbGFja2luZyBpLWpzb24gdG8gYmUgZG9jdW1lbnRlZCB0byBz aW1wbGlmeSBzcGVjaWZ5aW5nIHRoZSBjb25zdHJhaW50cz8NCg0KIEkgc3RpbGwgY2FuJ3QgdGVs bCB3aGF0IHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGktanNvbiBmcm9tIEpPU0UgZG9jdW1l bnRzIHdvdWxkIGxvb2sgbGlrZS4NCldvdWxkIHlvdSBub3JtYWxpemUgdG8gaS1qc29uIGJlZm9y ZSBzaWduaW5nIChsaWtlIFhNTCBkaWdpdGFsIHNpZ25hdHVyZXMgbm9ybWFsaXplcyBYTUwgYmVm b3JlIHNpZ25pbmcpLCBhbmQgd2hhdCB3b3VsZCB0aGF0IG1lYW4/IEZvciBkdXBsaWNhdGUgYXR0 cmlidXRlcywgbnVtYmVycyB3aXRoIHByZWNpc2lvbiBoaWdoZXIgb3IgbnVtYmVycyBvdXQgb2Yg cmFuZ2Ugb2YgSUVFRT8NCg0KT3Igd291bGQgeW91IGRlZmluZSBKU09OIHNpZ25hdHVyZXMgdG8g b25seSB3b3JrIG9uIGktanNvbj8gT3IgaXMgaXQgYSBjb25zdHJhaW50IG9uIHRoZSBzaWduYXR1 cmUgb2JqZWN0IGl0c2VsZj8gDQoNCkZvciBleGFtcGxlLCBpLWpzb24gc2F5cyANCiJJLUpTT04N CiAgIG1lc3NhZ2VzIFNIT1VMRCBOT1QgaW5jbHVkZSBudW1iZXJzIHdoaWNoIGV4cHJlc3MgZ3Jl YXRlciBtYWduaXR1ZGUNCiAgIG9yIHByZWNpc2lvbiB0aGFuIGFuIElFRUUgNzU0IGRvdWJsZSBw cmVjaXNpb24gbnVtYmVyIHByb3ZpZGVzLCBmb3INCiAgIGV4YW1wbGUgMUU0MDAgb3IgMy4xNDE1 OTI2NTM1ODk3OTMyMzg0NjI2NDMzODMyNzkuIg0KDQpTby4uIHdoYXQgZG9lcyB0aGlzIFNIT1VM RCBOT1QgbWVhbiBmb3IgSk9TRS4gWW91IFNIT1VMRCBOT1Qgc2lnbiBzdWNoIG1lc3NhZ2VzPw0K U0hPVUxEIE5PVCByZWx5IG9uIHRoZSByZXN1bHRzPw0KDQpJIGhvcGUgSSdtIG1ha2luZyBteSBw b2ludC4uLiBJJ20ganVzdCBhc2tpbmcgZm9yIGEgY29uY3JldGUgdXNlIGNhc2Ugd2hlcmUgdGhl IGN1cnJlbnQgaS1qc29uIGRvY3VtZW50IGlzIGFjdHVhbGx5IHVzZWZ1bC4gSnVzdCBvbmUuIEJ1 dCBhY3R1YWxseSB1c2VmdWwsIG5vdCBtYXliZS1raW5kb2Ytc29ydGEgY2xvc2UgaW4gc3Bpcml0 LiANCg0KTWF5YmUgSk9TRSBpcyB0b28gY29tcGxpY2F0ZWQ/DQoNCkxhcnJ5DQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXR0IE1pbGxlciBbbWFpbHRvOm1hbWlsbGUyQGNp c2NvLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVseSAxNywgMjAxNCAxOjM3IFBNDQpUbzogTGFy cnkgTWFzaW50ZXI7IFRpbSBCcmF5DQpDYzogSUVURiBKU09OIFdHDQpTdWJqZWN0OiBSZTogW0pz b25dIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtaS1qc29uLTAyDQoNCi0t LS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6IFNIQTUxMg0KDQovbWUgZG9m ZnMgaGF0Lg0KDQpTcGVha2luZyBhcyBhbiBhY3RpdmUgcGFydGljaXBhbnQgb2YgdGhlIEpPU0Ug V0cgc2luY2UgaXRzIGNoYXJ0ZXI6DQoNCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCBJLUpTT04gY29u dGFpbnMgZXZlcnl0aGluZyB0aGF0IHRoZSBKT1NFIFdHIGhhcyByZWFjaGVkIGNvbnNlbnN1cyBv biBidXQgaXMgbGFja2luZyBmcm9tIFJGQyA3MTU5Lg0KDQoNCi0gLS0NCi0gLSBtJm0NCg0KTWF0 dCBNaWxsZXIgPCBtYW1pbGxlMkBjaXNjby5jb20gPg0KQ2lzY28gU3lzdGVtcywgSW5jLg0KDQpP biA3LzE3LzE0LCAyOjE4IFBNLCBMYXJyeSBNYXNpbnRlciB3cm90ZToNCj4gVGhlcmXigJlzIG5v dGhpbmcgaW4gdGhhdCBzZWN0aW9uIGFib3V0IElFRUUgZmxvYXRpbmcgcG9pbnQgKG9yIGFueXdo ZXJlIA0KPiBlbHNlIGluIEpPU0UgdGhhdCBJIGNhbiBmaW5kLiBBbmQgaS1qc29uIGRvZXNu4oCZ dCBzYXkgYW55dGhpbmcgYWJvdXQgDQo+IGNhbm9uaWNhbGl6YXRpb24sIHdoaWNoIHdvdWxkIGxp a2VseSBiZSB3aGF0IEpPU0UgbmVlZHMuDQo+IA0KPiANCj4gDQo+IOKAnHRoZXnigJlkIHN3aXRj aCB0byBpdCBpbiB0aGUgYmxpbmsgb2YgYW4gZXll4oCdIHNlZW1zIGxpa2UgYW4gDQo+IHVuZGVy ZXN0aW1hdGUgYnkgc2V2ZXJhbCBvcmRlcnMgb2YgbWFnbml0dWRlLg0KPiANCj4gDQo+IA0KPiBN eSBwb2ludCBpcyB0aGF0IHRoZXJlIGlzIG5vIG9idmlvdXMgd2F5IHRoYXQgSk9TRSBjb3VsZCBt YWtlIA0KPiBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRoZSBpLWpzb24gZG9jdW1lbnQgYXMgaXQg c3RhbmRzLCBldmVuIGlmIA0KPiBldmVyeW9uZSBhZ3JlZWQgdG8gaXQgKGJ1dCBhZ3JlZW1lbnQg d291bGQgZGVwZW5kIG9uIHRoZSBkZXRhaWxzIG9mIA0KPiB3aGF0IHRoZSByZWZlcmVuY2Ugc2Fp ZCkuDQo+IA0KPiANCj4gDQo+ICpGcm9tOipUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxp dHkuY29tXSAqc1NlbnQ6KiBXZWRuZXNkYXksIEp1bHkgDQo+IDE2LCAyMDE0IDEyOjE2IFBNICpU bzoqIExhcnJ5IE1hc2ludGVyICpDYzoqIE1hdHQgTWlsbGVyOyBJRVRGIEpTT04gV0cgDQo+ICpT dWJqZWN0OiogUmU6IFtKc29uXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbg0KPiBkcmFmdC1p ZXRmLWktanNvbi0wMg0KPiANCj4gDQo+IA0KPiBGb3IgZXhhbXBsZSwNCj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMSNzZWN0aW9uLTQN Cj4NCj4gDQo+IA0KPiANCj4gSWYgSS1KU09OIHdlcmUgcHVibGlzaGVkLCB0aGV54oCZZCBzd2l0 Y2ggdG8gaXQgaW4gdGhlIGJsaW5rIG9mIGFuIGV5ZSwgDQo+IGJhc2VkIG9uIHByZXZpb3VzIGNv bnZlcnNhdGlvbnMuDQo+IA0KPiANCj4gDQo+IE9uIFdlZCwgSnVsIDE2LCAyMDE0IGF0IDEyOjAy IFBNLCBMYXJyeSBNYXNpbnRlciA8bWFzaW50ZXJAYWRvYmUuY29tIA0KPiA8bWFpbHRvOm1hc2lu dGVyQGFkb2JlLmNvbT4+IHdyb3RlOg0KPiANCj4gSSB0aGluayBhdCBsZWFzdCBvbmUgbW90aXZh dGluZyB1c2UgY2FzZSBpcyBjYWxsZWQgZm9yLCBpZiBub3QgbW9yZS4NCj4gDQo+IA0KPiANCj4g QnV0IHNjYW5uaW5nIHRoZSBKT1NFIGRvY3VtZW50cywgSSBkaWRuJ3QgZmluZCB3aGVyZSB5b3Ug d291bGQgdXNlIA0KPiBJLUpTT04gaW5zdGVhZC4gQ291bGQgeW91IHBvaW50IGl0IG91dD8NCj4g DQo+IA0KPiANCj4gVGltIEJyYXkgPHRicmF5QHRleHR1YWxpdHkuY29tIDxtYWlsdG86dGJyYXlA dGV4dHVhbGl0eS5jb20+Pg0KPiB3cm90ZToNCj4gDQo+IFdlbGwsIEkgdGhpbmsgdGhpcyBkaXNj dXNzaW9uIHNvcnQgb2YgYWxyZWFkeSBoYXBwZW5lZCwgYnV0IGhlcmXigJlzIHRoZSANCj4gZXhp c3RlbmNlIHByb29mOiBJZiBJLUpTT04gaGFkIGV4aXN0ZWQgYXQgdGhlIHRpbWUgSk9TRSB3YXMg Z2V0dGluZyANCj4gZ29pbmcsIHRoZXkgY291bGQgaGF2ZSBzaW1wbGlmaWVkIHRoZWlyIHNwZWNz LCBhbmQgaW1wbGVtZW50ZXJz4oCZIA0KPiBsaXZlcywgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRl bWVudDogVXNlIEktSlNPTi4NCj4gDQo+IA0KPiANCj4gQWxzbywgdGhlIGNvbGxlY3Rpb24gb2Yg Y29uc3RyYWludHMgSVMgc3BlY2lhbDogSXQgY292ZXJzIGV2ZXJ5dGhpbmcgDQo+IHRoYXQgNzE1 OSBjYWxscyBvdXQgYXMgYW4gaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtLCBhbmQgc2F5cyDigJxk b27igJl0IGRvIA0KPiB0aGF04oCZLg0KPiANCj4gDQo+IA0KPiBPbiBGcmksIEp1bCAxMSwgMjAx NCBhdCA0OjUxIFBNLCBMYXJyeSBNYXNpbnRlciA8bWFzaW50ZXJAYWRvYmUuY29tIA0KPiA8bWFp bHRvOm1hc2ludGVyQGFkb2JlLmNvbT4+IHdyb3RlOg0KPiANCj4+PiBQbGVhc2UgcmV2aWV3IHRo ZSBkb2N1bWVudCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgV29ya2luZyBHcm91cCANCj4+PiBt YWlsaW5nIGxpc3QgPCBqc29uIGF0IGlldGYub3JnIDxodHRwOi8vaWV0Zi5vcmc+ID4gb3INCj4g dGhlIGNvLWNoYWlycyA8anNvbi1jaGFpcnMgYXQNCj4+PiB0b29scy5pZXRmLm9yZyA8aHR0cDov L3Rvb2xzLmlldGYub3JnPiA+IGJlZm9yZSB0aGUgZW5kIG9mDQo+IHRoZSBXR0xDLiAgQW55IGFu ZCBhbGwgY29tbWVudHMNCj4+PiBvbiB0aGUgZG9jdW1lbnQgYXJlIHNvdWdodCBpbiBvcmRlciB0 byBhc3NlcyB0aGUgc3RyZW5ndGggb2YgDQo+Pj4gY29uc2Vuc3VzLiBFdmVuIGlmIHlvdSBoYXZl IHJlYWQgYW5kIGNvbW1lbnRlZCBvbiB0aGlzIG9yDQo+IGVhcmxpZXINCj4+PiB2ZXJzaW9ucyBv ZiB0aGUgZHJhZnQsIHBsZWFzZSBmZWVsIGZyZWUgdG8gY29tbWVudCBhZ2Fpbi4NCj4gDQo+IEkg dGhpbmsgSSBvcmlnaW5hbGx5IHN1cHBvcnRlZCB0aGUgZGV2ZWxvcG1lbnQgb2YgSS1KU09OIGFz IHVzZWZ1bCANCj4gbmFtZWQgcHJvZmlsZSBvZiBKU09OLiBIb3dldmVyLCBiYXNlZCBvbiByZWNl bnQgZGlzY3Vzc2lvbnMgYW5kIA0KPiBmdXJ0aGVyIGV4YW1pbmF0aW9uLCBteSBvcGluaW9uIG5v dyBpcyB0aGF0IHRoZSBwYXJ0aWN1bGFyIGNvbGxlY3Rpb24gDQo+IG9mIGNvbnN0cmFpbnRzIGlz bid0IHNwZWNpYWwsIGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxkIGluc3RlYWQgYmUgDQo+IHJlY2Fz dCBhcyBhICJCZXN0IFByYWN0aWNlcyBmb3IgSW50ZXJuZXQgVXNlIG9mIEpTT04iLg0KPiBUbyBm YWNpbGl0YXRlIHVzaW5nIHRoZSBkb2N1bWVudCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIGVh Y2ggDQo+IGNvbnN0cmFpbnQvYmVzdCBwcmFjdGljZSBjb3VsZCBiZSBuYW1lZCAibm8tZHVwLW5h bWVzIiwgDQo+ICJpZWVlLW51bWJlcnMiLCAidXRmOCIuIElmIHlvdSB0aGVuIHdhbnQgdG8gbmFt ZSB0aGUgdW5pb24gb2YgYWxsIA0KPiBjb25zdHJhaW50cyBpbiB0aGUgZG9jdW1lbnQgYXMgImkt anNvbiIgdGhhdCB3b3VsZCBiZSBPSy4NCj4gDQo+IE1vc3Qgb2YgdGhlIGRvY3VtZW50IChpbmNs dWRpbmcgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBhc3NvY2lhdGVkIHdpdGggDQo+IGVhY2ggY29u c3RyYWludCkgd291bGQgcmVtYWluLCBidXQgdGhlIGVtcGhhc2lzIG9uICJpLWpzb24iIGFzIGEg DQo+IHVuaXF1ZSBhbmQgY29tcGxldGUgcHJvZmlsZSB3b3VsZG4ndCwgYW5kIHdvdWxkIG1ha2Ug aXQgZWFzaWVyIGZvciANCj4gcmVmZXJlbmNpbmcgYXBwbGljYXRpb25zIHRvIGNob29zZSB0aG9z ZSBjb25zdHJhaW50cyB0aGF0IGFyZSANCj4gbWVhbmluZ2Z1bCBmb3IgdGhlbS4NCj4gDQo+IExh cnJ5IC0tIGh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCj4gDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18ganNvbiBtYWlsaW5nIGxpc3Qg DQo+IGpzb25AaWV0Zi5vcmcgPG1haWx0bzpqc29uQGlldGYub3JnPiANCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qc29uDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gLS0N Cj4gDQo+IC0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1lIGEgcHJpdmF0ZSBt ZXNzYWdlLCBzZWUNCj4gaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkpDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gLS0NCj4gDQo+IC0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1l IGEgcHJpdmF0ZSBtZXNzYWdlLCBzZWUNCj4gaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkpDQo+ IA0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcvTWFjR1BH MiB2Mi4wLjIyIChEYXJ3aW4pDQpDb21tZW50OiBHUEdUb29scyAtIGh0dHBzOi8vZ3BndG9vbHMu b3JnDQpDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIFRodW5kZXJiaXJkIC0gaHR0cDovL3d3dy5l bmlnbWFpbC5uZXQvDQoNCmlRRWNCQUVCQ2dBR0JRSlR5RFFEQUFvSkVEV2krUzBXN2NPMVZ0QUgv M2EvZzR3Q0lYMVJJY2MzZDlreUFyQVUNCitCdWVIazJnOU0yeWlPa2Rqc1BPcFpRaFo1TjVLUzRF Z3h0Nmk3UjIvV2hCaXNkd3htSjlIUzhyektMVUROQ2kNCkZDRGMyQ1hqRjcwMXFBajVma0JoUUdP SEN2UlI1OHRuRVcxOXhNNGdZdEc1V0cyN3F1cys4ZEY4RlNKV1loT1kNClVLYzFrN3dUcldsWlJi anl6ZlBOdUhXUWJJTVBFZzltaGZNRjdQdFNxcWtJTnYzVmFvOWdXVGRZaXdLTThOZ1ANCk1hZ3lN Y3VPZy92Z0Mxd1Fwd3dXaE5Tak1JUndHWmtxVVZMY0c0ZHU2T0tGa3hxeTZFWkZ0UFUrVGRjQXpn RjINClFTdXd0UzI5VHpLMUJVdzA0Y3FqS2wrRzJ2SWpycXdneExQVVk2ZFlwYWlXcFNNRmJ4ano2 RVNCVUt6bnNaOD0NCj1ZVEs3DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From nobody Sun Jul 20 11:53:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19421B27F0 for ; Sun, 20 Jul 2014 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPjxMTDKI-OL for ; Sun, 20 Jul 2014 11:53:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439D91B2CAF for ; Sun, 20 Jul 2014 11:53:42 -0700 (PDT) Received: from Philemon (unknown [66.207.208.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E7B752CA1A; Sun, 20 Jul 2014 11:53:40 -0700 (PDT) From: "Jim Schaad" To: "'Larry Masinter'" , "'Tim Bray'" References: <53B21F69.7010101@cisco.com> <53C066AE.9050104@cisco.com> <3b1rk4x0d2dwsnvbr0w1wjya.1405535654838@email.android.com> In-Reply-To: Date: Sun, 20 Jul 2014 14:51:29 -0400 Message-ID: <092b01cfa44b$9eac7b00$dc057100$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_092C_01CFA42A.179E8480" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKov2vhk56OUbYXKcowgYH+SabU7AKM8BuiAOQA3dsCfBTaUgGv4WIyAp27E+MAhce3JJmhBzFA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/json/z-kBf4L7jLZ8LziGJ_wLwTCgCjI Cc: 'Matt Miller' , 'IETF JSON WG' Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jul 2014 18:53:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_092C_01CFA42A.179E8480 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Currently there are no issues for JOSE dealing with numbers, however = there is a big issue dealing with the fact that there needs to only be = one named item at any given lexical scope. This was one of the things = that I was pushing for on the JSON update but was roundly defeated on. =20 Jim =20 =20 From: json [mailto:json-bounces@ietf.org] On Behalf Of Larry Masinter Sent: Thursday, July 17, 2014 4:18 PM To: Tim Bray Cc: IETF JSON WG; Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 =20 There=E2=80=99s nothing in that section about IEEE floating point (or = anywhere else in JOSE that I can find. And i-json doesn=E2=80=99t say = anything about canonicalization, which would likely be what JOSE needs. =20 =E2=80=9Cthey=E2=80=99d switch to it in the blink of an eye=E2=80=9D = seems like an underestimate by several orders of magnitude. =20 My point is that there is no obvious way that JOSE could make normative = reference to the i-json document as it stands, even if everyone agreed = to it (but agreement would depend on the details of what the reference = said). =20 From: Tim Bray [mailto:tbray@textuality.com]=20 sSent: Wednesday, July 16, 2014 12:16 PM To: Larry Masinter Cc: Matt Miller; IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 =20 For example, = http://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#section-4 =20 If I-JSON were published, they=E2=80=99d switch to it in the blink of an = eye, based on previous conversations. =20 On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter = wrote: I think at least one motivating use case is called for, if not more. =20 But scanning the JOSE documents, I didn't find where you would use = I-JSON instead. Could you point it out? Tim Bray wrote: Well, I think this discussion sort of already happened, but = here=E2=80=99s the existence proof: If I-JSON had existed at the time = JOSE was getting going, they could have simplified their specs, and = implementers=E2=80=99 lives, with the following statement: Use I-JSON. =20 Also, the collection of constraints IS special: It covers everything = that 7159 calls out as an interoperability problem, and says = =E2=80=9Cdon=E2=80=99t do that=E2=80=99. =20 On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter = wrote: > > Please review the document and send comments to the Working > > Group mailing list < json at ietf.org > or the co-chairs = > tools.ietf.org > before the end of the WGLC. Any and all comments > > on the document are sought in order to asses the strength of > > consensus. Even if you have read and commented on this or earlier > > versions of the draft, please feel free to comment again. I think I originally supported the development of I-JSON as useful named profile of JSON. However, based on recent discussions and further examination, my opinion now is that the particular collection of constraints isn't special, and the document should instead be recast as a "Best Practices for Internet Use of JSON". To facilitate using the document as a normative reference, each constraint/best practice could be named "no-dup-names", "ieee-numbers", "utf8". If you then want to name the union of all constraints in the document as "i-json" that would be OK. Most of the document (including the normative language associated with each constraint) would remain, but the emphasis on "i-json" as a unique and complete profile wouldn't, and would make it easier for referencing applications to choose those constraints that are meaningful for them. Larry -- http://larry.masinter.net _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) =20 --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) ------=_NextPart_000_092C_01CFA42A.179E8480 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Currently there are no issues for JOSE dealing with numbers, however = there is a big issue dealing with the fact that there needs to only be = one named item at any given lexical scope.=C2=A0=C2=A0 This was one of = the things that I was pushing for on the JSON update but was roundly = defeated on.

 

Jim

 

 

From:= = json [mailto:json-bounces@ietf.org] On Behalf Of Larry = Masinter
Sent: Thursday, July 17, 2014 4:18 PM
To: = Tim Bray
Cc: IETF JSON WG; Matt Miller
Subject: Re: = [Json] Working Group Last Call on = draft-ietf-i-json-02

 

There=E2=80=99s nothing in that section about IEEE floating point (or = anywhere else in JOSE that I can find. And i-json doesn=E2=80=99t say = anything about canonicalization, which would likely be what JOSE = needs.

 

=E2=80=9Cthey=E2=80=99d switch to it in the blink of an eye=E2=80=9D = seems like an underestimate by several orders of = magnitude.

 

My point is that there is no obvious way that JOSE could make = normative reference to the i-json document as it stands, even if = everyone agreed to it (but agreement would depend on the details of what = the reference said).

 

From: Tim Bray = [mailto:tbray@textuality.com] =
sSent: Wednesday, July 16, 2014 12:16 PM
To: Larry = Masinter
Cc: Matt Miller; IETF JSON WG
Subject: Re: = [Json] Working Group Last Call on = draft-ietf-i-json-02

 

 

If I-JSON were published, they=E2=80=99d switch to it = in the blink of an eye, based on previous = conversations.

 

On Wed, Jul 16, 2014 at 12:02 PM, Larry Masinter = <masinter@adobe.com> = wrote:

I think at least one = motivating use case is called for, if not = more.

 

But scanning the JOSE documents, I didn't find where = you would use I-JSON instead. Could you point it = out?



Tim Bray <tbray@textuality.com> = wrote:

Well, I think = this discussion sort of already happened, but here=E2=80=99s the = existence proof: If I-JSON had existed at the time JOSE was getting = going, they could have simplified their specs, and implementers=E2=80=99 = lives, with the following statement: Use = I-JSON.

 

Also, the collection of constraints IS special: It = covers everything that 7159 calls out as an interoperability problem, = and says =E2=80=9Cdon=E2=80=99t do = that=E2=80=99.

 

On Fri, Jul 11, 2014 at 4:51 PM, Larry Masinter <masinter@adobe.com> = wrote:

> > = Please review the document and send comments to the Working
> > = Group mailing list < json at ietf.org > or the co-chairs <json-chairs = at
> > tools.ietf.org > before the end of the WGLC. =  Any and all comments
> > on the document are sought in = order to asses the strength of
> > consensus. Even if you have = read and commented on this or earlier
> > versions of the = draft, please feel free to comment again.

I think I originally supported the development of = I-JSON as
useful named profile of JSON. However, based on recent = discussions
and further examination, my opinion now is that the = particular
collection of constraints isn't special, and the document = should
instead be recast as a "Best Practices for Internet Use = of JSON".
To facilitate using the document as a normative = reference, each
constraint/best practice could be named = "no-dup-names",
"ieee-numbers", "utf8". = If you then want to name the union
of all constraints in the document = as "i-json" that would be OK.

Most of the document = (including the normative language
associated with each constraint) = would remain, but the emphasis
on "i-json" as a unique and = complete profile wouldn't, and
would make it easier for referencing = applications to choose
those constraints that are meaningful for = them.

Larry
--
http://larry.masinter.net

<= p = class=3DMsoNormal>

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



 

-- =

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



 

-- =

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

------=_NextPart_000_092C_01CFA42A.179E8480-- From nobody Mon Jul 21 10:40:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F221A00F1 for ; Mon, 21 Jul 2014 10:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwrI-k3L0E4W for ; Mon, 21 Jul 2014 10:40:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AFB1A017F for ; Mon, 21 Jul 2014 10:40:40 -0700 (PDT) Received: from dhcp-a243.meeting.ietf.org (dhcp-a243.meeting.ietf.org [31.133.162.67]) by mail.nic.cz (Postfix) with ESMTPSA id 5448613FACA for ; Mon, 21 Jul 2014 19:40:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1405964437; bh=gllq2Rjc2O+7cCRCTj9KeLuk6pLBFBwtyScTiRpv9xM=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=H1LMvFb5Q6h8VkWK04o+7oQYgPlmRfDK2sw9L91yEjPa1mAXjiC+ALe4E/vpIFVj9 0B0W1z4doEm39RrDnyndzypcp+zBLFuuxxRiljwCkyCeqadArei6vs4WR7XDlPkyew OY4jNXZTpDEn8kFVOehKjWGZ++lOl4FnYjUhjs+I= From: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> Date: Mon, 21 Jul 2014 13:40:34 -0400 To: JSON WG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/json/kD6fMDlw2HNi5l2hF59AiIGrAvo Subject: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:40:43 -0000 Hi, I=92d like to ask about the reasoning behind the choice of base64url as = the encoding format for binary data. I am working on the I-D http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 which defines JSON encoding for data modelled with the YANG language = [RFC6020]. Such data are primarily intended to be used in remote = configuration protocols such as NETCONF or RESTCONF, so it seems to be a = good use case for I-JSON and we would certainly like to comply with = I-JSON rules. However, YANG has the data type =93binary=94 which requires base64 = encoding. So I wonder - is there any reason for preferring base64url = over base64? We most likely don=92t need the encoded data to be = URL-safe. Thanks, Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 21 10:46:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781191A0097 for ; Mon, 21 Jul 2014 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-ZnmH-pn0j6 for ; Mon, 21 Jul 2014 10:46:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA231A0045 for ; Mon, 21 Jul 2014 10:46:46 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so12931994vcb.17 for ; Mon, 21 Jul 2014 10:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=I3TE/OJ5TRT+i6uBwhQ77Qxwo+/rwRa0O0e7fxd1Nd8=; b=S6XWQCr0gncUzR5oiYErdqh1jp8q8QlIZnbRN5Bf3OejqCg9WIiKHQ8GAiEG65t72R MO5O+YC4ey3N16ccOAniCNkfCMEuNZgyc0WShSRFrFOiESF3t07w83eFyuMEsTL+PtUb xNfu7wOEcpMZQGXWvbdXQnV/te/m6RmcPjdNuc27Fx78aXXPKLI0uTo/HSzEdzrt19jt ooodm+4KlDzY2kL1Xj6QgOb9CdI2ZmvSufVViQnsiXYPWP1EVHDvGLq1iEZRi2KqXNpB 6MFcgysePILDY4Jpxe7Xy2ifJGaVNYUVifg+MzJB+YVvjvDajhv+RnFJnyUroCLt/pRx qznA== X-Gm-Message-State: ALoCoQlWH4DIxb5iA2P7aRXIkY4N7VA9Pjwd9gTp+qRQuyGZ4oA6GhFrCnkueNFbG1rQA63owO+4 X-Received: by 10.221.59.194 with SMTP id wp2mr6491846vcb.59.1405964805802; Mon, 21 Jul 2014 10:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.199 with HTTP; Mon, 21 Jul 2014 10:46:25 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> From: Tim Bray Date: Mon, 21 Jul 2014 10:46:25 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11335472d1300b04feb7b0da Archived-At: http://mailarchive.ietf.org/arch/msg/json/8YXLzCrfo98GnP9BPZuIFXdH724 Cc: JSON WG Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:46:48 -0000 --001a11335472d1300b04feb7b0da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good question. I think I agree with Ladislav=E2=80=8B; what=E2=80=99s the b= enefit to URL-safety in a JSON field value? On Mon, Jul 21, 2014 at 10:40 AM, Ladislav Lhotka wrote: > Hi, > > I=E2=80=99d like to ask about the reasoning behind the choice of base64ur= l as the > encoding format for binary data. > > I am working on the I-D > > http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 > > which defines JSON encoding for data modelled with the YANG language > [RFC6020]. Such data are primarily intended to be used in remote > configuration protocols such as NETCONF or RESTCONF, so it seems to be a > good use case for I-JSON and we would certainly like to comply with I-JSO= N > rules. > > However, YANG has the data type =E2=80=9Cbinary=E2=80=9D which requires b= ase64 encoding. > So I wonder - is there any reason for preferring base64url over base64? W= e > most likely don=E2=80=99t need the encoded data to be URL-safe. > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11335472d1300b04feb7b0da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Goo= d question. I think I agree with Ladislav=E2=80=8B; what=E2=80=99s the bene= fit to URL-safety in a JSON field value?


On Mon, Jul 21, 2014 at 10:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

I=E2=80=99d like to ask about the reasoning behind the choice of base64url = as the encoding format for binary data.

I am working on the I-D

http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00<= br>
which defines JSON encoding for data modelled with the YANG language [RFC60= 20]. Such data are primarily intended to be used in remote configuration pr= otocols such as NETCONF or RESTCONF, so it seems to be a good use case for = I-JSON and we would certainly like to comply with I-JSON rules.

However, YANG has the data type =E2=80=9Cbinary=E2=80=9D which requires bas= e64 encoding. So I wonder - is there any reason for preferring base64url ov= er base64? We most likely don=E2=80=99t need the encoded data to be URL-saf= e.

Thanks, Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a11335472d1300b04feb7b0da-- From nobody Mon Jul 21 12:49:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E21A03C9 for ; Mon, 21 Jul 2014 12:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-oF4kq020aS for ; Mon, 21 Jul 2014 12:49:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7A41A03C8 for ; Mon, 21 Jul 2014 12:49: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.5/8.14.5) with ESMTP id s6LJnfCx001509; Mon, 21 Jul 2014 21:49:41 +0200 (CEST) Received: from dhcp-9c03.meeting.ietf.org (dhcp-9c03.meeting.ietf.org [31.133.156.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9BB8F5E9; Mon, 21 Jul 2014 21:49:39 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 21 Jul 2014 15:49:36 -0400 X-Mao-Original-Outgoing-Id: 427664976.55521-c0f8849d61e5b0b3e0b70878f39154b8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/SVowKckn13WESDQ8ac98QNgNhig Cc: Ladislav Lhotka , JSON WG Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:49:48 -0000 For this usage, base64 and base64url are exactly equivalent. For other usages, base64url has advantages. If you pick one, it has to be base64url. Of course, then you get problems with the base64 legacy. You can=92t win this one. Do it right or do it compatibly. Gr=FC=DFe, Carsten From nobody Mon Jul 21 13:04:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130CD1A03F5 for ; Mon, 21 Jul 2014 13:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 327W8vGlkOoD for ; Mon, 21 Jul 2014 13:04:16 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933811A03C8 for ; Mon, 21 Jul 2014 13:04:16 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so11630587vcb.30 for ; Mon, 21 Jul 2014 13:04:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9EHvSw/iRnX6R1P1sS2nKu0jxD6UwOGkMgZeclFn2RY=; b=RWuQvXMMQpBBUX090OL8rBONzLsRvsDiDGf0mWArvDUy71usPMakTkr2NlxAXjnKNx B8gvxKk4lKtlW4EzpZj2NX/HrBNkuvYj+QeGxFSuUDdPFEz9fx11uqeduWtMXoC5W/LQ PZnnq552Km8InOia/dM6ChWmtAJGskAZ8FDkv7vc+/QXE4zrBWhVAat7mZouvf1v2vM5 dYBKMU2vdWcZ2yk8p0Cd2AH20+GTuc2rEcBRnV0ZjbSzCVR9OzT3GGZHcps8DPHGVQmh np2QZhz8rIC0c6W5zZfyCs52KhIfiNloPsdDpZrewdoPiwo0pM+TpybB/dhF7rvEfAR+ ypZQ== X-Gm-Message-State: ALoCoQnOvHtzTPkWPxjZRbXYPdfpQ6Nf5YmrDtV+qMICbHBMDzEZt59bW/6SY/zlF4NWNtrApLMa MIME-Version: 1.0 X-Received: by 10.221.41.135 with SMTP id tu7mr5800417vcb.70.1405973054125; Mon, 21 Jul 2014 13:04:14 -0700 (PDT) Received: by 10.221.49.199 with HTTP; Mon, 21 Jul 2014 13:04:14 -0700 (PDT) X-Originating-IP: [209.121.225.214] Received: by 10.221.49.199 with HTTP; Mon, 21 Jul 2014 13:04:14 -0700 (PDT) In-Reply-To: References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> Date: Mon, 21 Jul 2014 13:04:14 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1133901c7490df04feb99c2f Archived-At: http://mailarchive.ietf.org/arch/msg/json/l_fgFe-WpUMXnHSlbic4qR9HQRw Cc: Ladislav Lhotka , json@ietf.org Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:04:23 -0000 --001a1133901c7490df04feb99c2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I vote for "compatibly". On Jul 21, 2014 12:49 PM, "Carsten Bormann" wrote: > For this usage, base64 and base64url are exactly equivalent. > For other usages, base64url has advantages. > > If you pick one, it has to be base64url. > > Of course, then you get problems with the base64 legacy. > You can=E2=80=99t win this one. Do it right or do it compatibly. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a1133901c7490df04feb99c2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I vote for "compatibly".

On Jul 21, 2014 12:49 PM, "Carsten Bormann&= quot; <cabo@tzi.org> wrote:
For this usage, base64 and base64url are exactly equivalent.
For other usages, base64url has advantages.

If you pick one, it has to be base64url.

Of course, then you get problems with the base64 legacy.
You can=E2=80=99t win this one. =C2=A0Do it right or do it compatibly.

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

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a1133901c7490df04feb99c2f-- From nobody Mon Jul 21 13:08:34 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6F1A03CF for ; Mon, 21 Jul 2014 13:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQxXi8Qr70qq for ; Mon, 21 Jul 2014 13:08:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029781A02EF for ; Mon, 21 Jul 2014 13:08:30 -0700 (PDT) Received: from dhcp-a243.meeting.ietf.org (dhcp-a243.meeting.ietf.org [31.133.162.67]) by mail.nic.cz (Postfix) with ESMTPSA id 7A7DA13FACA; Mon, 21 Jul 2014 22:08:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1405973309; bh=ICY+IU3euO/EDLg3VhBCUNz98pNsQ4F5wTfWz3LSLDk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ISiS5o1BuhdFhDFA3iaUzXZ8WFB/1yRGdvuOr+muhKkQD/MlfL9T1ylj8XOYsPKcu lXw8D6+UgUETFsP9RC941LoYF7F8VE7bL80/Zu5bI9m9f0QDTSDhYP1tOyOh1GSEGB LMkrfLSM0V+NaI7U2HxRPjz5hVPEb4+z2mASdltA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 21 Jul 2014 16:08:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> To: Carsten Bormann X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/json/E6e5EtIAqN7_3beMg0_igCB_hOI Cc: Tim Bray , JSON WG Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:08:32 -0000 On 21 Jul 2014, at 15:49, Carsten Bormann wrote: > For this usage, base64 and base64url are exactly equivalent. > For other usages, base64url has advantages. Sec. 4.4 in I-JSON spec is clearly about JSON field values, and I can=92t = see any real advantage there. =20 >=20 > If you pick one, it has to be base64url. I guess the problem we have with sec. 4.4 of I-JSON spec is that = base64url is RECOMMENDED using an RFC 2119 keyword. IMO, it should just = state the properties an encoding should possess for maximum = interoperability, and perhaps give base64url as an example. Lada >=20 > Of course, then you get problems with the base64 legacy. > You can=92t win this one. Do it right or do it compatibly. >=20 > Gr=FC=DFe, Carsten >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 21 13:08:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C72E1A03CF for ; Mon, 21 Jul 2014 13:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgzXEpDIgjjF for ; Mon, 21 Jul 2014 13:08:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502E31A03FA for ; Mon, 21 Jul 2014 13:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6LK8Xl7010250; Mon, 21 Jul 2014 22:08:33 +0200 (CEST) Received: from dhcp-9b7d.meeting.ietf.org (dhcp-9b7d.meeting.ietf.org [31.133.155.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C4B945F3; Mon, 21 Jul 2014 22:08:31 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: Date: Mon, 21 Jul 2014 16:08:29 -0400 X-Mao-Original-Outgoing-Id: 427666109.66793-b1aedd974cb2177b3f88f34db9f1efb2 Content-Transfer-Encoding: quoted-printable Message-Id: <357CBD07-7013-4921-B141-C299082C279E@tzi.org> References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/json/H2OMKk8cY5TkmZlFEecSzTZhgxI Cc: Ladislav Lhotka , json@ietf.org Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:08:37 -0000 On 21 Jul 2014, at 16:04, Tim Bray wrote: > I vote for "compatibly". OK, so strike section 4.4; that covers all the bases. But if you want to make a RECOMMENDATION, base64url is still the right = one. Gr=FC=DFe, Carsten From nobody Mon Jul 21 14:24:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2641A04A7 for ; Mon, 21 Jul 2014 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgfm1zESRAGT for ; Mon, 21 Jul 2014 14:24:22 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4231A0452 for ; Mon, 21 Jul 2014 14:24:22 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so7371154iec.39 for ; Mon, 21 Jul 2014 14:24:21 -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:content-transfer-encoding; bh=nHoN/Ozhq7IfGyRIm3tKQj9mggETj/qQzsmNyoOk1Rs=; b=K3cRBFIfLz0z3GI6Ibz122PqPCcffEGkF4s6u6PCOxiXOWF6hpHIY0bbwK39LPaKb7 ztePJpXnFO6Frvj1a1IGdrk/P41LOaWHZ8KtsRyTTR20zNn/52nV1D+dUj5Aw2ZLSbWn 11oEMv+GMG6TSFGykuMml+54fzLzJpUyk2O1w9MHeYODSCURNMhMPU/UawCtJrTh7g5D PTz0WlPVJd/nvWOn3mlyh8Jb7EJ8Tvv/r/4oyy6ayhYcCJxJxgWi1rqqDLdc4iqQbP/U vWUHpxxwfOg6G9yqOu2tlsisU0sqj2PxI+7832EFB+RsUlbVnSQJvXpGUV0ZKYFw4d6g l54Q== X-Received: by 10.50.67.7 with SMTP id j7mr9489188igt.8.1405977861629; Mon, 21 Jul 2014 14:24:21 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.50.16.141 with HTTP; Mon, 21 Jul 2014 14:24:01 -0700 (PDT) In-Reply-To: <357CBD07-7013-4921-B141-C299082C279E@tzi.org> References: <2EB7C24D-5A94-47DC-877E-E0EFC6F789BA@nic.cz> <357CBD07-7013-4921-B141-C299082C279E@tzi.org> From: Jacob Davies Date: Mon, 21 Jul 2014 14:24:01 -0700 X-Google-Sender-Auth: 8QFL6IYn9ugZDP7HUFTglFEjQhM Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/moe71IfjIRQCcIJVkB8Rt7sloGc Cc: Tim Bray , Ladislav Lhotka , IETF JSON WG Subject: Re: [Json] binary data in I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:24:23 -0000 I don't know that there's enough evidence to say whether base64, base64url, hex, or hacky-use-of-illegal-\u-escapes would be most compatible with existing practice. I mean, there is one data point here obviously. Since there is admittedly no difference between base64 and base64url for the purposes of JSON I can't see that it matters much which one is recommended; even though I agree that base64url is to be preferred where possible, base64 doesn't seem "wrong", but maybe I am missing something. I still think the binary encoding is a recommendation worth making, whichever way. On Mon, Jul 21, 2014 at 1:08 PM, Carsten Bormann wrote: > On 21 Jul 2014, at 16:04, Tim Bray wrote: > >> I vote for "compatibly". > > OK, so strike section 4.4; that covers all the bases. > But if you want to make a RECOMMENDATION, base64url is still the right on= e. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue Jul 29 23:13:41 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4C1A0184 for ; Tue, 29 Jul 2014 23:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6gm-jNiE3CV for ; Tue, 29 Jul 2014 23:13:34 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D715D1A00BB for ; Tue, 29 Jul 2014 23:13:34 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id A7A2C1E071 for ; Tue, 29 Jul 2014 23:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=Jtnecg2NI+zFeXAMCUIQKjitMqo=; b=csfYFn9oHJU EAXa/GYOzHdPHIacKffm+LAg+cBbY23X7/wclFA7/XPNFz98Oo9niIGlf1/eCb7C SpG55VrTUdQHiay7K0Ggi17Q0n8Ly9bYAasuyLt9XjHv0Enc1zIcZ35cBPCp7/7Q PBxfYTpJ0rQriDAxxam7K0L15Ilh8lkg= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 587771E05C for ; Tue, 29 Jul 2014 23:13:34 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so1685993wib.8 for ; Tue, 29 Jul 2014 23:13:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.13 with SMTP id hg13mr3000299wib.28.1406700813162; Tue, 29 Jul 2014 23:13:33 -0700 (PDT) Received: by 10.217.98.6 with HTTP; Tue, 29 Jul 2014 23:13:33 -0700 (PDT) Date: Wed, 30 Jul 2014 01:13:33 -0500 Message-ID: From: Nico Williams To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/-FQ4N5IZconzLOxX4oWPxmeEmQY Subject: [Json] Example of JSON text sequences in the wild: Riak X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jul 2014 06:13:39 -0000 http://littleriakbook.com/ http://docs.basho.com/riak/1.1.0/references/appendices/MapReduce-Implementation/ Search for "stream". Here's a very sad example of why a simple encoding using LF (with internal LFs removed) would be so convenient: http://stackoverflow.com/questions/14531708/how-can-i-delete-a-riak-bucket-in-python Here's a node implementation that uses a streaming JSON parser: https://github.com/nisaacson/riak-streaming-node Here's another implementation that'd be helped by having an LF-based solution: https://github.com/nisaacson/riak-streaming-node Nico --