Re: [Json] JSON for Internet messages

Tatu Saloranta <tsaloranta@gmail.com> Wed, 03 July 2013 20:21 UTC

Return-Path: <tsaloranta@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DF111E8220 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 13:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4YbLjLQis-S for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 13:21:52 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 581E911E821B for <json@ietf.org>; Wed, 3 Jul 2013 13:21:52 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id p58so481304wes.40 for <json@ietf.org>; Wed, 03 Jul 2013 13:21:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eCjcA0vRHCqq/GIxm3pSnaQ6mqXlYsXfwUdjVx/KNsc=; b=a1GtW7AjGRdSVh+rbE5e3oc4C6DYayIXn+AGkF1jU0X8SXn8x/nuPlYqzCGr1cZtQ8 Jb4RMf4hX/qdDNbmN3Nco3ifGLGGIDyciRd4ApTlXHEpibP86tM/N2q5X5SklYHH+tAS JDu4rd+dFOtPMN/GFjUyPHeDcoJXZ8nltT1+3P9F9RB9HLNtE4yNVyf0UCkLmJaAxIez QDOl/hsG5aKuHPh4CsjEZD1m5taLX7Spt0p1XfyarrxZUdHqcroKrgi1Et3I2m+PrIsq 9XcWztsSiz4q/ZwHJGzhX240jYObQICsut5F5i4p+0JDu+rA0sFllwOjlvcn8LdERaJ4 Yocg==
MIME-Version: 1.0
X-Received: by 10.180.188.36 with SMTP id fx4mr18951761wic.55.1372882910583; Wed, 03 Jul 2013 13:21:50 -0700 (PDT)
Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 13:21:50 -0700 (PDT)
In-Reply-To: <20130703201522.GM32044@mercury.ccil.org>
References: <CAHBU6it55C5vCNLBki1LvjpWd4fANY8LdC4fzxj3a2G_+q=qSA@mail.gmail.com> <CAGrxA27wLfhLXBUF6cuuFbCEJ6yJYBtG8puiHXxNcoT3xem2zQ@mail.gmail.com> <20130703201522.GM32044@mercury.ccil.org>
Date: Wed, 3 Jul 2013 13:21:50 -0700
Message-ID: <CAGrxA24Cta+VDYxGwk6dW-L_vUVMuhvTB8ROpngJaQ3P46H9nw@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: multipart/alternative; boundary=001a11c25cd834224e04e0a1366c
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] JSON for Internet messages
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 20:21:53 -0000

On Wed, Jul 3, 2013 at 1:15 PM, John Cowan <cowan@mercury.ccil.org> wrote:

> Tatu Saloranta scripsit:
>
> > It has never been a problem for me, nor has there been user requests
> beyond
> > schema (and schema validator) implementors who care more. But it is
> > possible that perhaps this has been a significant problem for others.
>
> The trouble is that with sufficiently bad implementations, or chains
> of implementations, such permissiveness can lead to a security breach,
> and security being a Yang Worship Word these days, everyone cowers in
> fear which such things are mentioned.  My most recent use case for
> JSON (to represent the MicroXML data model) doesn't even require parsing
> it,
> but I never suppose that for that reason JSON might as well be limited
> to nothing but arrays in which the first element is always a string and
> the second element is always an object with string values.
>


Ok. This makes more sense to me. I hope that security aspect can be
emphasized in context of duplicates, if it is the leading reason (which is
consistent with earlier discussions I think).
I also do not think there is anything wrong in having multiple documents
that add layers of requirements: strict handling of duplicates seems best
handled at higher level, and not at basic format level.

-+ Tatu +-