[rpp] Re: Partial Updates

Pawel Kowalik <kowalik@denic.de> Thu, 13 August 2026 10:33 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 9DB5812912E11 for <rpp@mail2.ietf.org>; Thu, 13 Aug 2026 03:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786617231; bh=nFzlzL5jGMzFzgGYsidzVqJAHdvVFJ6Xlf1YAevQuxw=; h=Date:From:Subject:To:References:In-Reply-To; b=jl6w8KvyRoITEZv6FYJKJInIR2ofJ33wKvjt30qrwGg87q6w3mSDDeZh4amNiUlLC Umq0TjaYGH9/Fbo8V5DtUr9Z4tqT/nrTU2TgitV37bno192D+/LTfsnUohGBJDimvx nDfgWfXesi86x+Q3lbzOrtx5MvHrSOpQbvSBO/Z0=
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=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 dk4SJbnpfxmQ for <rpp@mail2.ietf.org>; Thu, 13 Aug 2026 03:33:51 -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 0EEB812912E02 for <rpp@ietf.org>; Thu, 13 Aug 2026 03:33:50 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.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-107.mailbox.org (Postfix) with ESMTPS id 4hLMCT5vBvz3yDp for <rpp@ietf.org>; Thu, 13 Aug 2026 12:33:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1786617221; 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:autocrypt:autocrypt; bh=nFzlzL5jGMzFzgGYsidzVqJAHdvVFJ6Xlf1YAevQuxw=; b=jlUpHiEUueed/dUEJjhIHn8JVSmDj/dtRx/jiKN6GV+Geb6maFSnx4fB8gX65V4p7lP8F2 sKMX9CC0PLI4aj2K9l17ruWNPvbr4ouoncMbm0LgNy5840xZDVd8IBTqAarQyXzbWvrAmn prfx0wrqIufbrIJ/38hYu6RCQP2ZBQZfCF39hwHDo7Y8Iz53LOem9U2e0GOG5n7qB1XDyb OUV79PWiR3gld1akV1covtBHJuVG69RNGUSdaBx1m8LdOpQc+3EDdOJD+0NwOUiOCcjTII Yh9qedNpEErdY1QH3mfslHPhxnXKTi7w4cm6rHA/GDW1XlpJE8EkV6bwvuxWCQ==
Message-ID: <7d64d8f3-365c-4537-9438-0b1a3eb51d8d@denic.de>
Date: Thu, 13 Aug 2026 12:33:40 +0200
MIME-Version: 1.0
From: Pawel Kowalik <kowalik@denic.de>
To: rpp@ietf.org
References: <64441C24-5894-40FF-A3C6-B76234F287DD@sidn.nl> <a7ee2b82-2a92-4471-8b8c-a4c44f5e7275@iit.cnr.it> <426b550c-94d9-479a-80f1-807db4a2821b@denic.de> <d40f742d-4d9d-442e-9451-b151ad6b878b@iit.cnr.it>
Content-Language: en-GB, de-DE
Autocrypt: addr=kowalik@denic.de; keydata= xjMEamCU8BYJKwYBBAHaRw8BAQdA5dc3skskyGV7KuAVZW2P9zRKhHIybZS9E3TaKieMHirN IFBhd2VsIEtvd2FsaWsgPGtvd2FsaWtAZGVuaWMuZGU+wokEExYIADEWIQShScYqTWt88Pdo pXJGlG3fGAsVTQUCamCU8AIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEEaUbd8YCxVNNbkA/17Y 1IzoCMMeUiSMZ424CjQHARFQcF1D5QSYMRNGumISAP9pQfYwGbjKXC3R4JS//mBuWrWwNgNE 6367eT/Szgq0AM44BGpglPESCisGAQQBl1UBBQEBB0BDekCxSiG5GnNaXO7e1uqhZEveJd1e bdPAHD2i0wvSaAMBCAfCeAQYFggAIBYhBKFJxipNa3zw92ilckaUbd8YCxVNBQJqYJTxAhsM AAoJEEaUbd8YCxVNjz8A/iPfom/5aDp2tmtUiRFkCDn6ipAfSjrlcd3ywcCp+qkQAPwNsEgQ 8cFBXpGBw9pPyGDQOzsr8AO2YJpDp1PMXDhUCg==
In-Reply-To: <d40f742d-4d9d-442e-9451-b151ad6b878b@iit.cnr.it>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------dugSb0z6vVpyjh2GTZxbftSd"
X-MBO-RS-META: grhj5wzxz3pp3fr1ucjxk6rpr5asy6k5
X-MBO-RS-ID: c28826aefa350619772
Message-ID-Hash: IPOJFDGXQMUNGQR3H7OJDBEJL3ORIIAL
X-Message-ID-Hash: IPOJFDGXQMUNGQR3H7OJDBEJL3ORIIAL
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: Partial Updates
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/dz2U9r8hCTq0Va7z8QG0kHtfQPA>
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 27.07.26 18:19, Mario Loffredo wrote:
> Hi Pawel,
>
> In my opinion, the RDAP context is quite different from the RPP context.
> The use of JSONPatch in RDAP is limited to JSContact localizations, 
> and the problem of having stable mapping keys is expected to be 
> limited to those (hopefully rare) cases where contacts have multiple 
> items in the collections used in the JSContact profile.

PK> Even if out-of-topic for this WG I have a different perspective on 
stable mapping keys. Also RDAP clients would be at minimum "confused" 
receiving different keys with each response or different data under the 
same key.

> In RPP, information about the order of items in a collection should be 
> stored in the registry database for each 1-N relationship.
PK> This is then the other topic brought up as a question to the WG. 
Shall RPP require that the order is always same and assured? "Stored in 
registry database" is likely not fulfilled by many registry systems. 
therefore would make deployments of RPP more difficult.
> Wouldn't it be simpler to use the value of the match property as a map 
> key?

PK> JSON allows only for a single string to be a map key. Match object 
may be more complex - for example: remove handle id "XXX" with role 
"adminc". We could come up with JSON representation which would define 
such unique combination as a sting, but I think the solution proposed by 
Maarten is more flexible and maybe even a valuable generic addition to 
the JSON Patch.

Kind Regards,
Pawel