Re: [Json] Proposed minimal change for duplicate names in objects

Tatu Saloranta <tsaloranta@gmail.com> Thu, 04 July 2013 22:17 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 308E311E80D3 for <json@ietfa.amsl.com>; Thu, 4 Jul 2013 15:17:23 -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=[AWL=0.000, 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 1xw28c9iA2-f for <json@ietfa.amsl.com>; Thu, 4 Jul 2013 15:17:22 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53811E81DD for <json@ietf.org>; Thu, 4 Jul 2013 15:17:21 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a12so1465111wgh.4 for <json@ietf.org>; Thu, 04 Jul 2013 15:17:21 -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=XHR8O0rUBZXrBTceBwX4SO/ZwsGDE4vZsL0havhNMNs=; b=MwExN11WHcswkcH9LxyW+0SI7Ma8JJk48Xr1KunFdVMqMtozcMVZgrFt4EmK9oOHgN FBks48rCl7nFwKFxREQ+j3xSghpYJAMTFhM8rWMg0Or/lNKKq80VOu4z+yjCefI1poQw GGHMp/m6+ISKGxn2TXJ5Z8NWBEfbwcn/57Z17hsMTqEQ4UBUWb1ReF3pPuyolfe05tMZ Uw8IAvF5sFnhN+m9eNLQXEDTJuwzSr1lEIhPrz6lhfljSgt5K/mwkvfbqiTJ9zch95JG bXA2RDC4N++EVK2Rr5k7vIvNfo4wtN0S8LAxXcm2O88ZUjhBHeNs6GdVItl4g11mHxpQ 7Fzg==
MIME-Version: 1.0
X-Received: by 10.180.11.146 with SMTP id q18mr3160442wib.50.1372976241239; Thu, 04 Jul 2013 15:17:21 -0700 (PDT)
Received: by 10.227.34.199 with HTTP; Thu, 4 Jul 2013 15:17:21 -0700 (PDT)
In-Reply-To: <CAK3OfOijGyGMEaeM6CmV+AbRHq2aJ3KaEc7sbrGDvQYuzSCc3Q@mail.gmail.com>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> <CAK3OfOijGyGMEaeM6CmV+AbRHq2aJ3KaEc7sbrGDvQYuzSCc3Q@mail.gmail.com>
Date: Thu, 4 Jul 2013 15:17:21 -0700
Message-ID: <CAGrxA24di1VgXZrHZfSGQ1YohuhidaRM2yPahbeKZpW4LQ7-kA@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a11c24d1624ee3d04e0b6f152
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Eliot Lear <lear@cisco.com>, "json@ietf.org WG" <json@ietf.org>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
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: Thu, 04 Jul 2013 22:17:23 -0000

On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Wed, Jul 3, 2013 at 3:29 PM, Eliot Lear <lear@cisco.com> wrote:
> > On 7/3/13 9:48 PM, Pete Resnick wrote:
> >> Let's remember the meaning of these capitalized words in IETF
> >> parlance. We use them "where it is actually required for
> >> interoperation or to limit behavior which has potential for causing
> >> harm." So a MUST would mean that not doing so would prevent
> >> interoperation or cause harm. RECOMMENDED (like SHOULD) would also
> >> mean that not doing so would prevent interoperation or cause harm, but
> >> "that there may exist valid reasons in particular circumstances to
> >> ignore a particular item, but the full implications must be understood
> >> and carefully weighed before choosing a different course."
> >
> > I have to say that ambiguity of a language implies an introduction to
> > interoperability problems.  But MUST we use MUST in those cases?   I
> > would prefer the catch the problem when we have the opportunity.  If the
> > WG feels differently, Meh.  As Nico said, deal with it at a higher layer.
>
> I think we're very likely to get consensus for SHOULD language with an
> out for streaming generators/parsers pushing the MUST to the
> application.
>
> We could force MUST with an out for streaming generators/parsers
> pushing the MUST to the application, but it'd leave some implementors
> on the rough side of consensus and unhappy.
>
>
One problem I have had is assumption that we only have 2 layers
(application, parser/generator). While it simplifies language, it makes it
difficult to define whether combination of parser and deserializer (as well
as serializer and generator) should be considered "parser" (and
"generator") in specifications or not.
Perhaps "application" here would then refer to serialization library and
application code?

I would be happy with "SHOULD" at parser/generator level, and even "MUST"
for serializer/deserializer level, since those are cases that are easy to
support efficiently.

At the same time, given such separation of processing layers, nothing
prevents applications from doing custom serialization/deserialization, and
by-passing strict checks. I don't personally mind that -- as long as
ramifications are made clear, it's their responsibility -- but I don't
think is universally agreed view.

-+ Tatu +-