IETF Logo Mail Archive

[rpp] Re: An implementation of JSContact in JSON Schema

Pawel Kowalik <kowalik@denic.de> Tue, 17 March 2026 08:11 UTC

Return-Path: <kowalik@denic.de>
X-Original-To: rpp@mail2.ietf.org
Delivered-To: rpp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8031ACC0B7D2 for <rpp@mail2.ietf.org>; Tue, 17 Mar 2026 01:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJz0go5UDGLt for <rpp@mail2.ietf.org>; Tue, 17 Mar 2026 01:10:57 -0700 (PDT)
Received: from mout-b-110.mailbox.org (mout-b-110.mailbox.org [195.10.208.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0D1A5CC0B6FD for <rpp@ietf.org>; Tue, 17 Mar 2026 01:10:57 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-110.mailbox.org (Postfix) with ESMTPS id 4fZl5L5hs8z9xmP; Tue, 17 Mar 2026 09:10:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1773735046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8cBzBuHY5RksuDAhxU8avXQ35S/8HPnBeg/9ik/ErBs=; b=Js2VUXtyzsDFx64jhBoBefKVpHtPPpr0dx1WpjSuR2VxXcDQZqQTkafl8iz2wSorfb4kIW 0ssWrAC4rR7TqM3B3Ras+ZEm63tpQhxgl0JYNChmHssIYFtSZDGNi239KThSpsrf8P7UP1 BHY3oV+B71pTl/SycI5h34gq39pp8tnqUKRl4haVn+Bbtm/qMlorAc3af0UVmi6568gBc3 f5mr6IuAlK54RzAJDvXE9tHO7fgcyoYa2PnQw0QPSLHqlhLpECZsVdfaOHrV5dwVk9UoCp DXhHmE3rGAh/FXR33GGDuFUEw1P1ftVD6aYcqAWb7124BOC/EIRkn7D/P6i6wg==
Message-ID: <6ff16be0-0db1-46eb-900f-efc1c0dc2f07@denic.de>
Date: Tue, 17 Mar 2026 09:10:44 +0100
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: Andy Newton <andy@hxr.us>, Jasdip Singh <jasdips@arin.net>, "rpp@ietf.org" <rpp@ietf.org>
References: <abYT-eacTk_XBcp9@nic.fr> <479a9158-34bc-46a4-ba94-5c5971bbecf6@denic.de> <abfpLjWva5nbf3oL@ietf.bortzmeyer.fr> <2883529d-04cb-4b67-ae2f-4c262c90fb1c@iit.cnr.it> <137566c1-114f-4635-b59f-e3cc24a9be36@denic.de> <PH7PR15MB6084A51151DA91CA7F0BBDF5C940A@PH7PR15MB6084.namprd15.prod.outlook.com> <4cd4431e-65fe-4031-9159-cc52c2c20138@hxr.us>
Content-Language: en-GB, de-DE
In-Reply-To: <4cd4431e-65fe-4031-9159-cc52c2c20138@hxr.us>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020005040209050600030206"
X-MBO-RS-ID: 6830c9c09d598918af7
X-MBO-RS-META: i7gb63kgw43aywuya7ewwyd6p9pstck4
Message-ID-Hash: SMKOHNI5XWPR4ZTV65PXQCCDXIYCYVGW
X-Message-ID-Hash: SMKOHNI5XWPR4ZTV65PXQCCDXIYCYVGW
X-MailFrom: kowalik@denic.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rpp] Re: An implementation of JSContact in JSON Schema
List-Id: "This list discusses a provisioning protocol based on RESTful principles and corresponding data representations using JSON." <rpp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rpp/gVz_zhy_FLiU7WIsqpNKOWUopXQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rpp>
List-Help: <mailto:rpp-request@ietf.org?subject=help>
List-Owner: <mailto:rpp-owner@ietf.org>
List-Post: <mailto:rpp@ietf.org>
List-Subscribe: <mailto:rpp-join@ietf.org>
List-Unsubscribe: <mailto:rpp-leave@ietf.org>

Hi Andy,

On 17.03.26 02:15, Andy Newton wrote:
> Agreed, especially considering other tech is being built upon JSContact.

You mean RDAP or sth else?

My point about RDAP was that its current profile for JSContact is not 
appropriate for provisioning. Lax processing is not favoured in RPP, 
therefore in order to have JSContact compatibility between the two not 
just on paper, the profiles shall be aligned, meaning RDAP profile being 
more strict.

>
> RPP needs to be more than EPP-in-JSON, otherwise it will be an 
> annoyance instead of a game-changer.
>
> This is also why discovery is important.

Agree.

Jim keeps mentioning Registry Mapping for EPP, which somehow did not 
fly. We have to learn from this.

[1] 
https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html

Kind Regards,
Pawel

v2.46.0 | Report a Bug | By Email | System Status