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

Pawel Kowalik <kowalik@denic.de> Mon, 16 March 2026 12:59 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 0755CCB50809 for <rpp@mail2.ietf.org>; Mon, 16 Mar 2026 05:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
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, 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 cyAt36M26ugt for <rpp@mail2.ietf.org>; Mon, 16 Mar 2026 05:59:58 -0700 (PDT)
Received: from mout-b-107.mailbox.org (mout-b-107.mailbox.org [IPv6:2001:67c:2050:102:465::107]) (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 82858CB507FF for <rpp@ietf.org>; Mon, 16 Mar 2026 05:59:58 -0700 (PDT)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (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-107.mailbox.org (Postfix) with ESMTPS id 4fZFYH5LyjzDrx2; Mon, 16 Mar 2026 13:59:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1773665987; 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=VF1IIQrikjLfwH8LWNQaFM/LRGs7z0qVjmqtkCSra9I=; b=qfNwYE5E79A/YsNy27nIU34EoGbxtGm/C+tozj6qqcpwebeW/SwywKnO6G4lrjTflCBtSv DtxNu8s4nUbbQEBEPWdvrf+hOcHd5mqjcIP2UyVVfbVBSmIf8H/CQ1owY52ldPA3hmpSW5 0TVfYmseD7noarE4fi+inq9qK6OWkTiEnw8d9EwVTNEgtStghhEttJG4FKvNB5Vrrb9DR0 HfoNcNSq9a7baJq5Q/54mLbEIhW6w/vjaiB1WV0swyBi/lFsK5u0U0whc4qWZ+LdxhhUzA jPFRhdniLIz+fmrIaMFSuR1hor/0LPdda9cmTNli7hQd4f6KcliMDMzvid1eIA==
Message-ID: <f5727327-9e13-498e-9178-e95828d96915@denic.de>
Date: Mon, 16 Mar 2026 13:59:45 +0100
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: Stephane Bortzmeyer <bortzmeyer=40nic.fr@dmarc.ietf.org>, Pawel Kowalik <kowalik=40denic.de@dmarc.ietf.org>
References: <abYT-eacTk_XBcp9@nic.fr> <479a9158-34bc-46a4-ba94-5c5971bbecf6@denic.de> <abfpLjWva5nbf3oL@ietf.bortzmeyer.fr>
Content-Language: en-GB, de-DE
In-Reply-To: <abfpLjWva5nbf3oL@ietf.bortzmeyer.fr>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms040801040509020104090108"
X-MBO-RS-META: kwwppsbj9ch4t7o9dytonh8udkz9qxyf
X-MBO-RS-ID: d8363c923cf63d9382b
Message-ID-Hash: D2KYZLUUHGRK525V25TQIQTO6RIVT3ZB
X-Message-ID-Hash: D2KYZLUUHGRK525V25TQIQTO6RIVT3ZB
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: rpp@ietf.org
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/tkGdMOLeackN3AOA_0c5k13D3bI>
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 Stephane,

On 16.03.26 12:27, Stephane Bortzmeyer wrote:
> On Mon, Mar 16, 2026 at 09:29:49AM +0100, Pawel Kowalik wrote:
>
> [...]
>
>> what is not fitting domain registration data model defined in EPP.
> The model of RFC 5733 is more correct but it can be represented in
> JSContact with the "full" property (RFC 9553, section 2.2.1.1). So,
> instead of:
>
> "name": {"components": [{"kind": "given","value": "Li"},
> 			 {"kind": "surname","value": "Ping"}
>
> use:
>
> "name": {"full": "Li Ping"}

[PK]

Exactly, this would be the part to define a profile. RDAP JSContact 
profile is more lax however, which is maybe ok for a read only protocol, 
but it won't make both instances of JSContact compatible with each other.

Kind Regards,
Pawel