
From nobody Tue Oct 26 12:26:52 2021
Return-Path: <cabo@tzi.org>
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 2692F3A1764; Tue, 26 Oct 2021 12:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lvJL7Cqu0HxI; Tue, 26 Oct 2021 12:26:41 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6E83A1761; Tue, 26 Oct 2021 12:26:41 -0700 (PDT)
Received: from [192.168.217.118] (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Hf1yy17Ghz2xHl; Tue, 26 Oct 2021 21:26:34 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
Date: Tue, 26 Oct 2021 21:26:33 +0200
Cc: asdf@ietf.org
X-Mao-Original-Outgoing-Id: 656969193.780653-b7321c559521a863ad9799de32e36238
Content-Transfer-Encoding: quoted-printable
Message-Id: <13AB383A-D467-400F-B48D-A0EC6B6D82AA@tzi.org>
To: json@ietf.org, rfc-interest <rfc-interest@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/UQu7zJaGvs0OBvcHA9Zzuu5UG2U>
Subject: [Json] sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Oct 2021 19:26:46 -0000

https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html

includes a number of JSON examples, or at least it claims so.

We created 15 examples that are marked =C2=BB<sourcecode =
type=3D=E2=80=9Cjson=E2=80=9D>=C2=AB.  Of these, 3 are JSON, and 12 are =
a single member (or two) without surrounding braces, meant to be put =
into larger JSON objects.

E.g.:
=
https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html#section-3.2-6

These braces can of course be added, but they are really noise =
distracting from the content that is in these members (and the objects =
formed this way may be valid JSON, but they usually aren=E2=80=99t valid =
SDF).

Should we introduce a new sourcecode type =E2=80=9Cjson-members=E2=80=9D?
Or should we bite the bullet and add the noise to get real JSON texts?

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


From nobody Tue Oct 26 13:19:13 2021
Return-Path: <petejson@codalogic.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 C4F0F3A12F7 for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 13:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.23
X-Spam-Level: 
X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 V8NoR5ix9L4e for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 13:19:02 -0700 (PDT)
Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (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 1C4B73A11B7 for <json@ietf.org>; Tue, 26 Oct 2021 13:19:00 -0700 (PDT)
Received: (qmail 17632 invoked from network); 26 Oct 2021 21:18:58 +0100
Received: from host86-140-57-185.range86-140.btcentralplus.com (HELO ?192.168.1.72?) (86.140.57.185) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted, authenticated); 26 Oct 2021 20:18:58 -0000
To: Carsten Bormann <cabo@tzi.org>, json@ietf.org, rfc-interest <rfc-interest@rfc-editor.org>
Cc: asdf@ietf.org
References: <13AB383A-D467-400F-B48D-A0EC6B6D82AA@tzi.org>
From: Pete Cordell <petejson@codalogic.com>
Message-ID: <eaa076b0-7782-dbbe-628c-8aa7c5588d6c@codalogic.com>
Date: Tue, 26 Oct 2021 21:18:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <13AB383A-D467-400F-B48D-A0EC6B6D82AA@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/byzA3Z7wuoP66phwsYDBfYItJc4>
Subject: Re: [Json] sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Oct 2021 20:19:08 -0000

On 26/10/2021 20:26, Carsten Bormann wrote:
> https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html
> 
> includes a number of JSON examples, or at least it claims so.
> 
> We created 15 examples that are marked »<sourcecode type=“json”>«.  Of these, 3 are JSON, and 12 are a single member (or two) without surrounding braces, meant to be put into larger JSON objects.
> 
> E.g.:
> https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html#section-3.2-6
> 
> These braces can of course be added, but they are really noise distracting from the content that is in these members (and the objects formed this way may be valid JSON, but they usually aren’t valid SDF).
> 
> Should we introduce a new sourcecode type “json-members”?
> Or should we bite the bullet and add the noise to get real JSON texts?

For a fragment of something bigger in free-form text I'd add ellipsis 
either side, e.g.:

    ...
    "namespace": {
      "cap": "https://example.com/capability/cap",
      "zcl": "https://zcl.example.com/sdf"
    },
    "defaultNamespace": "cap",
    ...

Is there not a precedent using things other than JSON (such as code 
samples) that offers guidance on whether to keep with a type="json" or 
add a new type?

HTH,

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------


From nobody Tue Oct 26 15:58:22 2021
Return-Path: <mnot@mnot.net>
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 5D50D3A193C; Tue, 26 Oct 2021 15:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XQL9Rqxu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ckCttE5J
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 elCgb57NDavy; Tue, 26 Oct 2021 15:58:15 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281533A1936; Tue, 26 Oct 2021 15:58:15 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 50F4E3201E22; Tue, 26 Oct 2021 18:58:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 26 Oct 2021 18:58:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=p IPby+jmcUgs+8ztKXxGlOokd1SKBodchriHiSGafjQ=; b=XQL9RqxuWavZ8Y0CJ ZSv6pqOUVkFoUx2maWT74Zu2oX8WiJpnlm4r8xgQVui0Z1zsQmjS0dJUNvYj2zXx e23vPae86NFHZWDDGwssEqFJ3CUIgxU6VS212+RKU8N/dF13RdkdxJBMuKeoRV/K 6LknhAvKg0NtupGoPs+YjE0EHkJ9cwLhqyoBEl1V4cEqhqAH2uByVMvdfPM6Kizz 3DBhM53HxSIADd3g1gqiYPGyBvnmE0v4C4XjaHA9v4fQ5G/OzNgPLnNzDEzRI61c hQKAxWZZBIVcQN0UstO1l9UKFCSJAv9DeSaXpkeMPX5Q1AiNfsMK5j2BpQ9VoSDz AqwwA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pIPby+jmcUgs+8ztKXxGlOokd1SKBodchriHiSGaf jQ=; b=ckCttE5J2s5JnZZxEXctFIV+/lCE0IVXK+zzY35IschPd7GlK8zyTQVHI 6Ugd2WMLX5eJZqxxnMDk5pvL0fCu1YJ2DnccQLqJOZAROgX/ikokOj0q/0UIEJnn LtqCl3uTcyE6ehjFwAhKkMP2shEJoAL3pEfbNkPcF4bxArHE/NzcLRhtrHq4aEHQ hnNHTe7sypGc/ZzSR7IrCSjwJKVO1OFCX13IS8Zs90PumkRAhIRbRxjTVGj9Bkgz onD/QJaMmNzpNezpjQOq/qIeRg01hR9nUsR4aG71x8C+nqSutSAieB1MzfjCNUq1 U7jmCGm/KBAczXkMUxfiiyq6D7SFg==
X-ME-Sender: <xms:BYh4YfT_SShRLwa91nAzczO3qOSggtSzlGYLNGpYTM1j20KJMdt0UQ> <xme:BYh4YQxPXXicezv1GgNi5essPPEI96FYwYkOXGl8Gu-YZNXTjMLSHrHjzDBGFVUOf ZG6jaDSzNoTvMarig>
X-ME-Received: <xmr:BYh4YU3IL1NmWCrPQrhr6oeYxGFDcJ60Jq9butLQ3IKvzLekF08TWLwXqH6DDNp88I0rvdtoEunUrrSCsI79uIbbTfTlW9nvgd0_n1CiIJvw7wmU2p8YQ3UH>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefledgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefgedvgfejgedvteeuudekveefhfehleeiveejjeekhfffheekjeeikeejtdeh jeenucffohhmrghinhepihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhn vght
X-ME-Proxy: <xmx:BYh4YfDiLAuloaoriCkRPVDE6le8wwuF_QmtP_bAC56BYYJNG18HzA> <xmx:BYh4YYgEhKcPgL9XydxjPmzWg2hVA1uptTYi4xJFGYGV-RCZQjl64w> <xmx:BYh4YTq6jo14P6AUcMd0XLo4Q9djo_keHJO_kbU1SN9norcaWpcSUg> <xmx:BYh4YSbhEbrrGPnQWPt4mN9T3U5dHHZ0QOMO130aRqKjl6kmuoiSoA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Oct 2021 18:58:11 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <13AB383A-D467-400F-B48D-A0EC6B6D82AA@tzi.org>
Date: Wed, 27 Oct 2021 09:58:09 +1100
Cc: json@ietf.org, rfc-interest <rfc-interest@rfc-editor.org>, asdf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <58E80F54-FABD-4AF3-8885-B70E070360F2@mnot.net>
References: <13AB383A-D467-400F-B48D-A0EC6B6D82AA@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/DHioGISUMMPMVUH2sApNz4_Bcl4>
Subject: Re: [Json] sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Oct 2021 22:58:20 -0000

For http, we use 'http-message', which is defined to be either a full =
*or* partial message. Remember, this is not a media type...


> On 27 Oct 2021, at 6:26 am, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html
>=20
> includes a number of JSON examples, or at least it claims so.
>=20
> We created 15 examples that are marked =C2=BB<sourcecode =
type=3D=E2=80=9Cjson=E2=80=9D>=C2=AB.  Of these, 3 are JSON, and 12 are =
a single member (or two) without surrounding braces, meant to be put =
into larger JSON objects.
>=20
> E.g.:
> =
https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html#section-3.2-6
>=20
> These braces can of course be added, but they are really noise =
distracting from the content that is in these members (and the objects =
formed this way may be valid JSON, but they usually aren=E2=80=99t valid =
SDF).
>=20
> Should we introduce a new sourcecode type =E2=80=9Cjson-members=E2=80=9D=
?
> Or should we bite the bullet and add the noise to get real JSON texts?
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue Oct 26 17:36:19 2021
Return-Path: <johnl@iecc.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 67BEE3A1970 for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 17:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=URXDVqTk; dkim=pass (2048-bit key) header.d=taugh.com header.b=yd0iRuVF
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 zSCQBMVqH2si for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 17:36:12 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 2167A3A0908 for <json@ietf.org>; Tue, 26 Oct 2021 17:36:11 -0700 (PDT)
Received: (qmail 32007 invoked from network); 27 Oct 2021 00:36:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7d02.61789ef8.k2110; bh=nqkpUKGOzkRsufiz3mTOy3i+kPBAK8YCQCKdHNwnXFs=; b=URXDVqTkOnJuQ2pG3ZvJydrxX6hZck0l7rpBdt7mGshVNynq5sYFZJbUnCQmIlmxe2CUBfOY9w4ByCZpubKx+suoEit8RLBI/CTiQoalFHoEQULNLs2/FpsyZioY4k9P1yPLDJHvT2/1DbDTIqnL2nYyjhI6unjyuPTtAmi94TrZ0PpJAOSSq7CDZTiXUTdUfs8hBot5oLXIfVbHdNEpKRUVuah6Si5wDXfFG7nURk5v0LapKowxCLfkVACYv/p2rJJ90aVJM4onrkNdrHoMM/uPsJ5uN5BVFGTNaUb4ugLegI+KuX4JRqk5x7N58B/W50BNw/kJyeO8J9vAByT/HA==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7d02.61789ef8.k2110; bh=nqkpUKGOzkRsufiz3mTOy3i+kPBAK8YCQCKdHNwnXFs=; b=yd0iRuVFFbl8sg5gRSWT+8kkcAIwcW/C0++Ya40lQdIrDD7SookZVuewYyGYpWgnXpG0kL3EoHOZD7pqJUaPpkQ/z5i6HgcEdB5eaSUSLDpkBnQe/N0mZoP9E/JrZcIq+PGoH5QcmhKUDt85C98CtIq0IObrVQ9P3t0sFOksPoEJsQvAZSOgG3nneM6GcAxKbMYJtxSKFmr14W4sWBES+BuyCu46Kucmi8EvP7kRT77fJ+1NXgXevYkqj83l9CJtlW2edxDQhAnJ6E1faa9NWIV74l4jS2ykOS3aARVMYw4ZoTQeY1p+az9izXL2Hb/JO0Mq+PC0dGXcV8g5FeqQ3A==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Oct 2021 00:36:07 -0000
Received: by ary.qy (Postfix, from userid 501) id 5C4472E60559; Tue, 26 Oct 2021 20:36:05 -0400 (EDT)
Date: 26 Oct 2021 20:36:05 -0400
Message-Id: <20211027003607.5C4472E60559@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: rfc-interest@rfc-editor.org, json@ietf.org
Cc: mnot@mnot.net
In-Reply-To: <58E80F54-FABD-4AF3-8885-B70E070360F2@mnot.net>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/OQBZuan7ySTF5j4qgHVp7kPVJ_Q>
Subject: Re: [Json] sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Oct 2021 00:36:18 -0000

It appears that Mark Nottingham  <mnot@mnot.net> said:
>For http, we use 'http-message', which is defined to be either a full *or* partial message. Remember, this is not a media type...

Right.  We have lots of sourcecode which is a chunk of a program, not a full program.

If it's a chunk of JSON, call it JSON.

R's,
John

>> We created 15 examples that are marked »<sourcecode type=“json”>«.  Of these, 3 are JSON, and 12 are a single member (or two)
>without surrounding braces, meant to be put into larger JSON objects.
>> 
>> E.g.:
>> https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html#section-3.2-6
>> 
>> These braces can of course be added, but they are really noise distracting from the content that is in these members (and the objects
>formed this way may be valid JSON, but they usually aren’t valid SDF).
>> 
>> Should we introduce a new sourcecode type “json-members”?
>> Or should we bite the bullet and add the noise to get real JSON texts?


From nobody Tue Oct 26 23:21:12 2021
Return-Path: <cabo@tzi.org>
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 B421D3A0A87 for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 23:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tlbL1wkFdixY for <json@ietfa.amsl.com>; Tue, 26 Oct 2021 23:21:05 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7D53A0970 for <json@ietf.org>; Tue, 26 Oct 2021 23:21:04 -0700 (PDT)
Received: from smtpclient.apple (p5089a10c.dip0.t-ipconnect.de [80.137.161.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HfJV51GvWz2xLG; Wed, 27 Oct 2021 08:21:01 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20211027003607.5C4472E60559@ary.qy>
Date: Wed, 27 Oct 2021 08:21:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <86844357-A8C7-4590-B8DC-D801E223A60A@tzi.org>
References: <20211027003607.5C4472E60559@ary.qy>
To: rfc-interest <rfc-interest@rfc-editor.org>, json@ietf.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/_FgQkgb9_3T1QUVGXXBuLbJ7xec>
Subject: Re: [Json] [rfc-i]  sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Oct 2021 06:21:11 -0000

Thank you all for your great feedback.

> On 27. Oct 2021, at 02:36, John Levine <johnl@taugh.com> wrote:
>=20
> Right.  We have lots of sourcecode which is a chunk of a program, not =
a full program.
>=20
> If it's a chunk of JSON, call it JSON.

That is certainly true of e.g. C language =E2=80=94 there is no =
expectation that C language in a sourcecode block is a complete program.

The question is really why are we marking up sourcecode as to its type =
in the first place.

One need would be for rendering.
But amazingly, it=E2=80=99s 2021 and we don=E2=80=99t yet have syntax =
coloring in RFCs.
This, however, could be added from the information that is in the XML =
today; full JSON texts and JSON fragments probably can be handled by the =
same coloring engine.
(The coloring would be heuristic during rendering, not embedded in the =
XML; only the type information would be needed to select the appropriate =
heuristics.)

With FDT languages such as ABNF or CDDL, extraction is needed; since =
some ABNF/CDDL is just for exposition, extraction needs the distinction =
between that and the normative ABNF/CDDL; in recent RFCs that has =
sometimes been done by using the @name attribute alongside @type.

Apart from that, the needs I=E2=80=99m more interested in are as a =
support for authoring.
This is mostly based on extraction, but also on the ability to run CI =
processes on the sourcecode extracted (per-block and between them).
Additional metadata may be required as input to e.g. a validation =
process; YANG puts that into the =E2=80=9C<CODE BEGINS>=E2=80=9D line.

The specific question came up because I was adding some CI to the SDF =
spec repo.
Inevitably, that made me find one typo, which although not obscuring the =
intention, if undetected would sooner or later have led to an errata =
report.
I expect authoring tools like kramdown-rfc will provide some of this =
validation as a matter of course, but that requires metadata.
Of course, these don=E2=80=99t *have* to be saved in the XML, but for =
practical reasons much of the CI processing operates on the XML output.

So I=E2=80=99d rather have a way to embed metadata that is required for =
automatic processing (extraction, validation) in the XML.
This would also help with maintaining validation through the RFC =
production.

My current CI code has to guess whether type=3Djson means JSON text or =
JSON fragment (where the latter is well-defined for SDF, but maybe not =
in general).
My concern is less that this adds 5 lines of code to the now 19-line =
validation script.
I=E2=80=99d rather not require that a validation step needs to guess the =
author=E2=80=99s intention.

(The next step then is to add CDDL validation for the JSON texts and =
fragments.
Additional metadata needed here is: which specific CDDL rule is intended =
to govern that text/fragment.
I=E2=80=99m not too happy if I need to cram that into @name, but it =
looks that way.)=20

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


From nobody Wed Oct 27 11:39:11 2021
Return-Path: <johnl@iecc.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 CC1F63A1059 for <json@ietfa.amsl.com>; Wed, 27 Oct 2021 11:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Gqyy+GmQ; dkim=pass (2048-bit key) header.d=taugh.com header.b=mPV1Uum5
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 8Gt_H8Azx2zY for <json@ietfa.amsl.com>; Wed, 27 Oct 2021 11:39:03 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 68A1B3A1051 for <json@ietf.org>; Wed, 27 Oct 2021 11:39:03 -0700 (PDT)
Received: (qmail 88051 invoked from network); 27 Oct 2021 18:39:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=157f1.61799cc5.k2110; bh=nmjiKuLtKdwf1MX4BcX1BLc6fOz/xDJSEvcEiWvK+mQ=; b=Gqyy+GmQC9lkJvq6ZlIfbsxRHdm31LAwmsgWV6W0PYDBfJ09xDQJ1juGm02g03uTwX44WAX0qetzNxkS1N8EO4s5auqSE9zxfcSiVNTFm29Sb0IrENM6/pTmj5egddRaZodrMMdfscI1THseuYAo9IELBdlzQWiqf4Qmu3Ll3uY/CulrXoa1ZUoMcc+c4WcZ9CI3rQ9CmUWV38zKFTFA7OHq4Biigx+pyeyp00if3cFPlxJZg8jMzXJgi84tsrMBcfZbVMlikewgsJkaOFRrs3QzE/B48EEv3K62ogER3t/bz2B8/6i+9//XuK2soN8GBtuH6EPys7H2wM3p46302w==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=157f1.61799cc5.k2110; bh=nmjiKuLtKdwf1MX4BcX1BLc6fOz/xDJSEvcEiWvK+mQ=; b=mPV1Uum5f0SZl0jKBQN+f4dOL3vCKqPMuig6NZ4k2KIuMmezCV8OxM0CJeHTEF8vBHlH+4hWPOdD8KUy42Btzj//Z/BvhroObo8RA1k+I9g/j0VFJsBlPUfwGuhY6mJOK0KGhVLOZN255dvo98HsCt1UtX75aPWsTvae/gVUEKLamTCsQkO5nJJHiq+5HJG3QlG+1tYHmwZjvi76pqdeQh2/yzcIK/KtFMSeBX7VqDmeglsV3Usot6DsbZft5u/kprsA606kaTuu3oZRS00brC2Ew5fOGykjuGfGSQNK3PHsPvbWtzZ80nT2OoJXlDgTUd6P6nSWokxJl+0h9Mfakg==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Oct 2021 18:39:01 -0000
Received: by ary.qy (Postfix, from userid 501) id C2FF82F215F6; Wed, 27 Oct 2021 14:39:00 -0400 (EDT)
Date: 27 Oct 2021 14:39:00 -0400
Message-Id: <20211027183900.C2FF82F215F6@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: rfc-interest@rfc-editor.org, json@ietf.org
Cc: cabo@tzi.org
In-Reply-To: <86844357-A8C7-4590-B8DC-D801E223A60A@tzi.org>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/8dV91pk2aJ6nvW6m9rPn52MpHdI>
Subject: Re: [Json] [rfc-i]  sourcecode type="json"
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Oct 2021 18:39:09 -0000

It appears that Carsten Bormann  <cabo@tzi.org> said:
>The question is really why are we marking up sourcecode as to its type in the first place.
>
>One need would be for rendering. ...

>With FDT languages such as ABNF or CDDL, extraction is needed; ...

>Apart from that, the needs I’m more interested in are as a support for authoring.

That seems about right.  If we really care about extraction, we'd need attributes with
more clues about how to do it since in most languages unlike ABNF, the order in which
you paste fragments together makes a difference, and you often need hints about what
version of the language, e.g. python 2 vs python 3.

I don't think we should try and solve this problem now, just throw it on the heap of
things to donsider for xml2rfc v4.

R's
John

