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

Pete Resnick <presnick@qti.qualcomm.com> Wed, 03 July 2013 19:49 UTC

Return-Path: <presnick@qti.qualcomm.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 5185C11E8224 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 12:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y3k0yz6vAc3 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 12:48:59 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F411E8210 for <json@ietf.org>; Wed, 3 Jul 2013 12:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1372880939; x=1404416939; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OwK/btaplHkITgMqF7uh5tudwe6AZiJdwPE7rgYRzS8=; b=YmwImAZXFr+jCLxHMBI90t6RF8i0aW9hkcpl7zeLXn0f3vvJt/WTkE3/ cIIvmQAQ8z0fPBNNg90jaHPQOGIFEGGv0VB9xNn1p9e1WhZvncavsOVP/ dhrX6MvUJQd42WRNUWldxLlndhQT1UrGO6hXmVBBbRnHBpS/5YbHMt5TN A=;
X-IronPort-AV: E=Sophos;i="4.87,990,1363158000"; d="scan'208";a="46702109"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 03 Jul 2013 12:48:53 -0700
X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="474124229"
Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 12:48:53 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:48:53 -0700
Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:48:52 -0700
Message-ID: <51D48023.1020008@qti.qualcomm.com>
Date: Wed, 3 Jul 2013 14:48:51 -0500
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com>
In-Reply-To: <51D3C63C.5030703@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: Nico Williams <nico@cryptonector.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "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: Wed, 03 Jul 2013 19:49:03 -0000

Speaking strictly as a participant, and just to give guidance, not 
insist on an outcome.

On 7/3/13 1:35 AM, Eliot Lear wrote:
> Nico,
>    
>> In short, for streaming parsers (and generators) there's nothing we can do.
>>
>> What we can do is RECOMMEND that a) generators not produce duplicates
>> (and explain how streaming ones cannot prevent dups), and b) that
>> parsers use the last name (and explain how streaming ones will produce
>> all dups).
>>      
> To me this isn't strong enough.  I have some sympathy for both the
> existing base and for parsers, but generators as an architectural
> component should generate unambiguous output, streaming or otherwise.
>    

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."

In this instance, saying that generators SHOULD not produce duplicates 
is to say that if you do produce them, you might not interoperate or you 
might cause harm to some parsers, but there might be valid reasons 
(i.e., because your storage or compute footprint is too small to retain 
state) to produce duplicates. And documenting that there may be reasons 
that generators will produce duplicates (and explicitly stating those 
reasons) certainly puts parsers on notice that they will need to deal 
with it. Giving parsers some guidance on what to do in that case is all 
the better.

So I don't think saying RECOMMENDED or SHOULD regarding not producing 
duplicates should be seen as a non-starter. That's a defensible position 
for the WG to take.

pr

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