Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments
Tom Harrison <tomh@apnic.net> Sun, 29 May 2022 04:42 UTC
Return-Path: <tomh@apnic.net>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACBAC15AE2F for <regext@ietfa.amsl.com>; Sat, 28 May 2022 21:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=apnic.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgNk5TqqBImu for <regext@ietfa.amsl.com>; Sat, 28 May 2022 21:42:46 -0700 (PDT)
Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2077.outbound.protection.outlook.com [40.107.107.77]) (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 AEB9BC15949D for <regext@ietf.org>; Sat, 28 May 2022 21:42:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tkhjewxaj9zQyCwve3CCZfpAUK0rcrDrxjMBBtkox0V7UR+B/ZRYEir2Vdvt7vrh7hOPgbi855IKj4Ph/zcePwsF/MmYpXB360YCUgEk2UuKKqzU1xpNzy9xVGw+/wqnxWh5L9CPuw0oz+QuRyVXnoMl4jFqQUyd9LQe2aHLUrb8yiT36zQ5wy2OjrT+9MjzjNiZd1y+8Ee1fj3l9ScEgcBCTyILUluNv09YLoXeeFnI9fdmOpoz147p/TdYf/3n6m7IwaHQy8p3EkB98v/SAJ084DjS5bGIHavuG+MdQDVkQJ77TY6iNdJfdGzOnDMv8tFTQd3XPGTxEze+CzBxWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ob+rPl1YVHBkwwjL9t7gqnLs/0QbTGaD/xbJyiN2G6g=; b=fPzPCtHJJYi1z3NUS5wGA47j6pERhu91yZjAJBv0S5/XwOPym/YeXL/By5sc9LhMFztuhqZH0V0GaLNpZpZoZRBOhuE4UnKrKqjGJMZ2lb66+Rb+psZJfn3kovESz8AfATMp2P/LBe0tSK1018u1v4g7j7HhlEe9Ppb2ogvaxs455I2a703gGynY8GISzTPTIhfu1WgnxWaBopQL+c2wN6afHKeKSU4kBXkBbpYc+CGp7BuYIXpfSN/Ee9udnoUX0AM1S5zjMzG/JSJowkozV7wtpwyOg0oLEpFQezXruaX3abN3JPyLm7dbO4u4GyDvHJa4q+0Npnq26HQWvVyVyg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ob+rPl1YVHBkwwjL9t7gqnLs/0QbTGaD/xbJyiN2G6g=; b=EU+cxHBpz0+STL7CB96D1YeP4yuEQo6H3AohGoMODDH1/ViKHajpfnTgjBR66cQq++VnbYhoihkju3fhopQy57qK12LfLBPth6CEzgwQlU1zQbFh9fwwap1uawP2CewJKjopVSGbTcYsAJDapujXqdQ0kzXurTfYQu/StvzLOZ4=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=apnic.net;
Received: from SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:68::12) by MEYP282MB4171.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:165::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.13; Sun, 29 May 2022 04:42:38 +0000
Received: from SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM ([fe80::4d8f:bd0d:749c:bf8e]) by SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM ([fe80::4d8f:bd0d:749c:bf8e%3]) with mapi id 15.20.5293.018; Sun, 29 May 2022 04:42:38 +0000
Date: Sun, 29 May 2022 14:42:34 +1000
From: Tom Harrison <tomh@apnic.net>
To: Mario Loffredo <mario.loffredo@iit.cnr.it>
Cc: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
Message-ID: <YpL5uqGP+RHVKTEM@TomH-802418>
Mail-Followup-To: Mario Loffredo <mario.loffredo@iit.cnr.it>, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
References: <3EE8519B-CEFE-4DEB-9E43-F68DCA446BBB@verisign.com> <84c5706314a248df80af5c14802acf51@verisign.com> <AED70457-5263-4F08-8500-08C027912EF2@verisign.com> <b0683ce9a5c6447c9c9be8741b9d9cf5@verisign.com> <fbd37e63-b179-9a14-dffe-3082ab1edfa0@iit.cnr.it> <Yo6uz05Oc5iKvoee@TomH-802418> <65427a66-7149-26e4-ae79-88966a36d89e@iit.cnr.it>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <65427a66-7149-26e4-ae79-88966a36d89e@iit.cnr.it>
X-ClientProxiedBy: SYBPR01CA0154.ausprd01.prod.outlook.com (2603:10c6:10:d::22) To SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:68::12)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d0a227b2-fb2a-4186-d5dc-08da412da89e
X-MS-TrafficTypeDiagnostic: MEYP282MB4171:EE_
X-Microsoft-Antispam-PRVS: <MEYP282MB4171EFDE3D894D8DDC8124D9C0DA9@MEYP282MB4171.AUSP282.PROD.OUTLOOK.COM>
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: YELIeJMc4o8Kcw77jrPbnFoNMxXPsud0AcZYLQgzfL3/+qfz5oLWb0wNS9IUfmpnKJW/Jlle5S4weW0HTR+bvIKI42xFTM0xnb+CRXLiFYK6qwpCH4ooD9eVE+iiTsh34bulKOmTWe08UbBLZ7y52n1QQT/GK6S9mrhz8DF98pjmnuyS4OusMrYxbX63S6P0tlNt0zxU882gjT3pHHl5ORof0W+1BNVmez+8jAJb98aW9P3bs/zYG5qPK+LdQ5b2Hf+Gdiv7Q6zouO93kr6EFac9KxLi0bjNkq/EGUpHSfB+x6MhwVQMvCsOYjcl1LO+Hp/y45KCKjKY+Rcj5alHJpbynCqw/GpQlrh9oIcPr3r8Zne5NKGnPTv/zASMtH0WqRB9lRF7zS2yVD2KGsNm01QR1M63qDRgOAjYXNPF3yt7zZiazwvI/f30fZutQy96l4YJdfio1VpWoIUuSKHg84RiZLcy7N7/bJH0622RDsh2gRnrEL5lAzwE+/MNH2dGhNhyXn8DkAywRFS/Dhr8z0FXt3IcowZlMlOyTW5cfgNRYh+HzdSMsROp/aJm9JlOV8iZt78yA+Iq0AwGHe15AMqNR5/mdzAR6yRy4iysgDwb0eR46zC2dHJDQ+i0NW/yYc0UcHTJVU1GMACR3UIsV4Dnmkm2Tvusnrhm7czWeGWYhIy+NKPfed7Febnl4YTub/BRtLwPqkthVKFR/Y2oUGjw3ZCF7xPeQxh30KRei9w=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(4636009)(7916004)(346002)(366004)(376002)(136003)(39830400003)(396003)(6486002)(316002)(508600001)(52116002)(54906003)(66946007)(66556008)(66476007)(6916009)(9686003)(5660300002)(8936002)(33716001)(2906002)(41300700001)(8676002)(4326008)(6512007)(26005)(86362001)(38350700002)(38100700002)(83380400001)(186003)(6506007)(6666004)(67856001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: WeaD1MOfslrQr/nauQG1ncnYrkWiDI8H7eHnJ0oJXwaTVYuJ+CNrXI2pvf2JLLoJZWYGLPq99SN5yhRxNGXTi6fYC/kGvq/hlglNrZXU5rVG1Kv2fF2RJ6z08OllyzPM7jaitVxK7LmHmtt8louj7If2IApwxiei95URSh9/B4y1uHESz9Zo5fRH4QXBgyMYckLuqXt1FIm1fwAq0LYPLyweVbNY2ASN/pL9z5sDXHG8N0z5vJWSW7/o2lPoRBumPfYTA6w32Ws4JCB8bsOc2X+VSQVA9+ZTGdq6BktHtpapt7Hz+1lp8bFZviiNP8IZwn+WffOcoSVH7VO2/I8FWRltUr5eF9rin172IrD666ygajmFFHCVUP+CwcfapPPBOo9bYNTKy+U49sjM07TnXxVjqD2Ap/Gj2CrJPZX4dcEagQHGUpVWMcduWxOci5c+vl7IjuEhv69QwPLq2q4ixIa78kfspp7EWgbCGhHKrPCf6F+/whxux0dva3fVO5LDgEuQc3nsfrXaGWYmPtosZUwwznTICNkTAFHDdcZwERhyWs2BBektRhVtKoVSoTduTDHEJ/R2dodhjGK+lWIId3wHWVo3iUL4lSEQAbg4sJnCofeDasKg3cdcz34CRywGITFYfIFK/NXuBzP05Y2EPMVVitFLGSnUBKcv0ZZiaEK/VMkiPuRyEuBRZ+veMZ+5h6j3SGC0g2cQtI2W+J83hTLSuLhOiZc5bR6mscSarXh5MEbSwoc95gggz1cVmP0kSOpkvxItQYr8mHI5GrM2Mf9/vWdx+9wxsVw+Bpni6EW59rRjaYok6ovVb9xkkk+J8eGYHTOT3aMVZsTXg0odo4LMLCOOzUynHajw/iiRvl7GcI9hN04cZqRIFCrLjD16vbEMbR42CoYopVgvsUjjvSlosr2Aw4JbQfR1tRBOWHNRS5N45z+vMLMs6zednwyP17NYweAVMVcAosUfoSV0Rw+nMDGJMCDctNzVf4Qy4iDKU+zucNfA3rGR09y0P3W4oy79+ILVLxkurzsc1WPhc8/NFMyzG0/MwceHdjCwxkGwhUm1ksr88NZarnRdIK2uj1INBZdR6gpks1zzs4rhYBpdRlngik8ryYuZpOada6NUzOZI50ao5eyPVGsGqTmsapw1ubk59rBXej5yYsmFmLbQsoBpb5gvlkcNGcfF0DyhsCmw3906AF8VNdGW2xS8xDae8ZK/2qeEq7bn+3oNrTyO8R7NENHwxWAgglRjhAbBZexm6qATp5ehEkaptMFZOdG1m5rkU+jy+J8hTq3Hb9TkExUC8qBFP8TmbBIpRHaw7brACvoJwI65Y38av/TiLMycUlh/BOVulY/PP6RgVnwSD3FQtLJTkeybcY/0RQxaM5yOtARubuu0BEfRLZQKyrYTOOVV9wpkQrTKm30e0nX3+aumB3GEfQL3459gOxMcVTxJIVazXAi2RvgC3W5U5y0RZM53QjoJJPhRISz/SNVakBlnibAo5pI/xqa5Wh1XQAfAVrYcCOZVnLPm5505+G2S/H9zGUw+KXhip9jMY5dYjLVNtQzAlndlmVNbn4zRvEgw3TozYXiy7jSjTCaQv3DyLRGWkn3knfZOHCNO7L8AvdrBKl0QuEnD+4ned/mKDFw96XTkthcmmd1lZi7My2GOFT9dDvsA15ZWevNfSlP6fHmnrF1aMMpNGld4QsBTGtacMVNvQbuDon2li+f9
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d0a227b2-fb2a-4186-d5dc-08da412da89e
X-MS-Exchange-CrossTenant-AuthSource: SYBP282MB0553.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2022 04:42:38.5755 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HSe8nLvi0IYn/lBO5EycuUDDgHZ9fjWa+9kR/4T1GNFG9qI+x1fZDeY4sUmSAquq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEYP282MB4171
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/XBS3x6gNtigk0-s8XdSdpGnJm0I>
Subject: Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 May 2022 04:42:50 -0000
Hi Mario, On Fri, May 27, 2022 at 12:41:27PM +0200, Mario Loffredo wrote: > Think the matter is that even the possible backwards-compatible changes > would result in being hardly backwards-compatible. > > Let te me give an example to make myself clear and move the discussion on a > practical perspective. > > Let's call "ext1" the rdapConformance value signaling the support of > "ext1_data" response extension. The response would be: > > { > > "rdapConformance" : [ ....., "ext1"], > > ... > "ext1_data" : { ... }, > .... > > } > > Now, let's suppose to add the field "newfield" to "ext1_data" and signal > this change by a version update from "ext1" to "ext2". The response should > be (in theory): > > { > > "rdapConformance" [ ....., "ext2"], > > ... > > "ext2_data" : { ... }, // where ext2_data includes all the member of > "ext1_data" plus "newfield" > .... > > } > > To avoid a breakage in the REST contract, the RDAP server should implement a > deprecation process ending with the replacement of "ext1_data" with > "ext2_data". This means that, for a period of time, both the version of the > response extensions should be provided: > > { > > "rdapConformance" [ ....., "ext1", "ext2"], > > ... > "ext1_data" : { ... }, > "ext2_data" : { ... }, > .... > > } > > > This situation would result in the following paradox as well: being the > introduction of new field in a JSON response widely considered a non > breaking change, it should be signaled by a minor version update (e.g. > "ext1_1). But, since the final effect would be the replacement of a response > field with another, a major version change should be used instead. In > short, every new version of the response extension would imply a major > version update ("ext1", "ext2", "ext3", ..) and a consequent deprecation > process the server should support. I don't understand the relevance of the scenario given above to the approach I set out for handing backwards-compatible changes. To avoid any doubt about the models I was proposing, I'll step through them in more detail, per your approach above. - Scenario A: add single field (backwards-compatible): - Initial: register extension "ext1", which notes that "ext1_data" will be included in responses, with a single field named "field1": "rdapConformance": [ ..., "ext1" ], ... "ext1_data": { "field1": ... } - Later: update the existing registration for extension "ext1", noting that some implementations of this extension may now return "field2". Implementations in accordance with the original version of "ext1" continue working as they do today. Implementations in accordance with the new version of "ext1" return responses like so: "rdapConformance": [ ..., "ext1" ], ... "ext1_data": { "field1": ..., "field2": ... } - The presence of "field2" is enough to distinguish the new version from the original version. Clients written to work with the original version do not change, and clients written to work with the new version are also fine, because they can determine whether the new version has been implemented by way of the presence of "field2". - Scenario B: add multiple fields (backwards-compatible): - Initial: register extension "ext1", which notes that "ext1_data" will be included in responses, with a single field named "field1". Subversioning is managed by way of an additional "conformance" field, which is used to note minor (backwards-compatible) updates: "rdapConformance": [ ..., "ext1" ], ... "ext1_data": { "conformance": "ext1", "field1": ... } - Later: update the existing registration for extension "ext1", noting that a new "ext1_data.conformance" value of "ext1_1" may be used, implementations of which will return "field2" and "field3" in the "ext1_data" element. Implementations in accordance with the original version of "ext1" continue working as they do today. Implementations in accordance with the new version of "ext1" return responses like so: "rdapConformance": [ ..., "ext1" ], ... "ext1_data": { "conformance": "ext1_1", "field1": ..., "field2": ..., "field3": ... } - The "ext1_data.conformance" field is enough to distinguish the new version from the original version. Clients written to work with the original version do not change, and clients written to work with the new version are also fine, because they can inspect at the "conformance" field. Backwards-incompatible changes continue to require a new top-level "rdapConformance" value and a transition process where both "ext1_data" and "ext2_data" (or their equivalents) are returned, per the example you gave above. Again, my concern here is not to say that the above are ideal mechanisms for versioning or similar, but simply to note that the existing strict reading is not so fundamentally problematic that it necessitates an alternative reading/approach. > A possible inelegant and misleading workaround would be to treat any new > version as a new extension like in the following: > > { > > "rdapConformance" [ ....., "ext1", "newfield1"], > > ... > "ext1_data" : { > ... > "newfiled1" : { ... } > }, > .... > > } If "newfield1" were named e.g. "ext1_1", I'm not sure that it would be particularly misleading, at least on a current strict reading of the text. It's probably fair to say that it's inelegant, but I think the key thing about this contention between a strict reading and some other potential reading is whether the strict reading is so problematic that some other reading must have been intended, and I don't think this (arguable) inelegance is so serious that that is the case here. > Stripping the version information from the extension prefix (Approach B or > C) would simplify the management of this case: > > { > > "rdapConformance": [ ....., "ext_1_1"], // (or "ext_level_1_1") to be > determined if the RDAP server should include both "ext_1" and "ext_1_1" at > least for a period of time > > ... > "ext_data" : { > ... > "newfiled" : { ... } > }, > .... > > } > > > Definitively, no breakages in the REST API contract, no deprecation process > to be managed by the server, no extra effort for both client and server > owing to the fact that JSON is schemeless and, by default, JSON libraries > don't block the deserialization of an object including an unknown property. The above example would require the extension author to document their intent to occupy a namespace of sorts in the extension registry, because otherwise a client written to operate against "ext_1" will not know what to do when it encounters "ext_1_1" (i.e. it won't be possible to make backwards-compatible changes). The idea of an extension declaring ownership of a namespace is at odds with the text in 9083 about extensions being identified by "a unique string literal value registered in the IANA RDAP Extensions registry", too. Given that, I'm not sure that it would be open to take this approach with the text as it stands. > A similar example is about adding a new optional query parameter to an URI > path defined by a request extension. I think scenario B that I set out previously (i.e. embed further versioning information in the extension response) would work for this aspect as well. -Tom
- [regext] Extension Prefixes, JSON Values, and URI… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Pawel Kowalik
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Andrew Newton
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Andrew Newton
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Hollenbeck, Scott
- Re: [regext] Extension Prefixes, JSON Values, and… Andrew Newton
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James
- Re: [regext] Extension Prefixes, JSON Values, and… Marc Blanchet
- Re: [regext] Extension Prefixes, JSON Values, and… Jasdip Singh
- Re: [regext] Extension Prefixes, JSON Values, and… Tom Harrison
- Re: [regext] Extension Prefixes, JSON Values, and… Mario Loffredo
- Re: [regext] Extension Prefixes, JSON Values, and… Gould, James