IETF Logo Mail Archive

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

Pawel Kowalik <kowalik@denic.de> Tue, 17 March 2026 15:18 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 8CB19CC4C967 for <rpp@mail2.ietf.org>; Tue, 17 Mar 2026 08:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 ivoQNDDx_Uej for <rpp@mail2.ietf.org>; Tue, 17 Mar 2026 08:18:58 -0700 (PDT)
Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [IPv6:2001:67c:2050:102:465::112]) (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 101D3CC4C95F for <rpp@ietf.org>; Tue, 17 Mar 2026 08:18:58 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (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-112.mailbox.org (Postfix) with ESMTPS id 4fZwbD6Y1gzDvB2; Tue, 17 Mar 2026 16:18:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1773760728; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=azWusuPX5/Gs8Of1oqBgIHpFHIKbftDMP/h/U/UuftQ=; b=WQ4tbgnw3LoGLq5nZXKlUPysY6p1+tk2c7R+wBrNpfj26Iuyg7QoQPubk4V8MqIe+OPX5f e1E8pUdPSK3xTP3x+qx0ngxw+fHlTDDqZICQFAgdec7NNUIkMze3sZjhFf3ISlybWZyZPH b/IeRAmvccZ4+rxqrR3IJGZlylnNQwLTGXcM9I7HPGLdhNa9gX4c89P8Vvx3u6TmYnG4Vy smv+DK/4z7dSnBxoyCAu9oyzKOrl5Iz37inrsEXEgCzrk8qArdmqUwgUXPVQFysvOZoSoT a33xACSw9DjA4toaXL2qU0dZMn09AVVsNWubCvcAedc1uA62dREc5k6hJNm2jA==
Message-ID: <f8495bcc-287a-4cea-8aeb-e46bf61d5808@denic.de>
Date: Tue, 17 Mar 2026 16:18:46 +0100
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: Mario Loffredo <mario.loffredo=40iit.cnr.it@dmarc.ietf.org>, Pawel Kowalik <kowalik=40denic.de@dmarc.ietf.org>, 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> <6ff16be0-0db1-46eb-900f-efc1c0dc2f07@denic.de> <52629a5c-c868-4a72-b5c9-ea8b5180dfd4@iit.cnr.it>
Content-Language: en-GB, de-DE
In-Reply-To: <52629a5c-c868-4a72-b5c9-ea8b5180dfd4@iit.cnr.it>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms010402050507010106060607"
X-MBO-RS-META: 6jqxsbmqtanaomr34izhxu3reh9cfcyf
X-MBO-RS-ID: 34fa88695005aa54670
Message-ID-Hash: 4XH4E3URNNVFMSMZ6CSLLTJGCFZ7MBCX
X-Message-ID-Hash: 4XH4E3URNNVFMSMZ6CSLLTJGCFZ7MBCX
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
CC: Robert Stepanek <rsto@fastmailteam.com>
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/i8oWXmLTZtprq5g8Sl_agobCihM>
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 Mario,

On 17.03.26 15:45, Mario Loffredo wrote:
> Hi Pawel,
>
> Il 17/03/2026 09:10, Pawel Kowalik ha scritto:
>> 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.
>
> [ML] Aside from the fact that it's possible to register a new 
> RPP-specific profile that introduces additional restrictions beyond 
> those defined in the "rdap" JSContact profile,I would like to know if 
> you mean that there are other types of restrictions missing from the 
> current version of draft-ietf-calext-jscontact-profiles.
>
[PK] As far as I can tell for now draft-ietf-calext-jscontact-profiles 
shall be sufficient to define a profile for RPP. We are quite early in 
the evaluation though.
> The JSContact profile for RDAP was defined to ensure compatibility 
> with the current output of RDAP servers. Of course, it can be modified 
> with WG consensus.

[PK] I know. My point was that JSContact != JSContact if the profiles 
are different. Both WGs would need to find consensus to avoid this. 
Let's see how it goes.

Kind Regards,
Pawel

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