[rpp] Why the limit to RMM level 2?
Pierre Thierry <pierre@nothos.net> Tue, 24 February 2026 13:07 UTC
Return-Path: <pierre@nothos.net>
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 CD24CBD10DD2 for <rpp@mail2.ietf.org>; Tue, 24 Feb 2026 05:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=nothos.net
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 UEEn4xYRkq0t for <rpp@mail2.ietf.org>; Tue, 24 Feb 2026 05:07:03 -0800 (PST)
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::227]) (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 DC920BD10DC4 for <rpp@ietf.org>; Tue, 24 Feb 2026 05:07:02 -0800 (PST)
Received: by mail.gandi.net (Postfix) with ESMTPSA id C6870441F2 for <rpp@ietf.org>; Tue, 24 Feb 2026 13:06:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nothos.net; s=gm1; t=1771938414; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt; bh=7hm8vfQnRnDuaIreRJz38BXmDenhW5nrOW1QC/ufycs=; b=Ul8h9JxVV5SB9z9zPRtXmbKiWZ4w0p/XkA+vywMcMYD70QYUKT6DV14exgN1zNPw5pSezB hc7Kf2NhruUZD5n1A6UXF5N861U0pnAZpxKTMUj4lCL2x1p+vZw+XbQdGJpAQSr8pXBmGL Lfc7zX0dBOCNbpdIuWGBvH0TDNbmabn25UNCD5ri59tul72d4buzPfKYffJWpF8xQe3mte yAn+eS64xJ88nlvjSPsklUDouRPkfUOwuKGltLxey7fCXO+GbXOvlO6KBYj7ZtZRHRqYgU XbAlk+rUpKRL01D1jSbhrvyeWIJpfru3bgRK6ylXRSMmYf8xxt7DZo5duEHT4A==
Message-ID: <5835bb17-790d-4606-83fa-e8eacadf0ac3@nothos.net>
Date: Tue, 24 Feb 2026 14:06:53 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: rpp@ietf.org
From: Pierre Thierry <pierre@nothos.net>
Autocrypt: addr=pierre@nothos.net; keydata= xsDiBDpdpWURBAD7tpWMwPQf1iVbB26rlD+ftX6OJA8qtSV3wCb7vNq6vm8BCqsKCQKHEoW1 VfgKSJeTSL7ylPI19uGzCMfRf94rxYXfknVkYG3DBDW+kHwCwlr2qESaMMaPWSiF893XPvze h9XwQOhsLGACBVqqgMhof8nOMf6PkfjFXDpNBO3N3QCg/74fliY5Zm0SDsT1U5GiJZtkd/ED /3Xe9sLRprbsuV5ADn1pLmX4rIRU/LFbiYzADnLiRPL9t2ZTRAmOX/GLETAY04G9zc4woG3K HcmvZ/mwPSFdRV2tcXLhmGCUWxeWWuH6HzwkURWljSdynQ3/IwaYIzxsLLbte09WQJJVmjPv d/SYYwsYdpJa1RXx2BWagIR9wnx4A/9rPEnm5uts/MWgASChGx5lOQbEGk+1tVawZCAASE/2 50NHm7fCbzWYoadvPID+Mm9EgPJu9gGzyHW2mh5UeN+uES1RXVb7zlz2IGd1XzdjfLr+yii3 Yh5nnWMFnmM9KDAhY1G9rgo7vnIKAzQyng0VbFtxDfJFCrcLFAa+bojHMs0iUGllcnJlIFRo aWVycnkgPHBpZXJyZUBub3Rob3MubmV0PsJiBBMRAgAiBQJMARknAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDF7Xcg2dUNim2dAJ9j6k+6vaXXZhVcyAOZdQc1Glq9VgCg9FY5 noTt2GYpbV70H9ZKuWs58XrOwU0EOl2lZRAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65 Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFX klnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J 280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs 3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2J SyIZJrqrol7DVekyCzsAAgIH/Rkt2nb5qf4DMsLjKaTVORP5LlmqU/mD67DbGrMFRG0EV/Wu XfioJsko2/EUlQVVcwtXQ8k2PDsgWK9t4H5Q83oV8gxbNTIOdAVUlP4aKVBCEjjrBmrWv/hy o90kpslvX85ocRPGL7TYg835VXRMjODa2FDUL/NDVFaBF9uzNNFnz/PDXpKqAfcq/IR3YOGx aemKDXovpFscmkn4ygxA0kBV+2au4/WepOtCAaW/N3RWEwghd9rV1oIEK7DsAT9YKkXKTrTd AVfHmmOmA7joT0w3xW0v+iuLNVpk0AvVDDmoE8AQLIjPzaIVvolggQ/XTX2kIjUyW6WT4Zi+ 4ZESTHvCTgQYEQIABgUCOl2lZQASCRDF7Xcg2dUNigdlR1BHAAEB6FkAn0mpzJCtUoM9LXdF doBL8pZxXwheAKDo458J9C9Jte8LLrwVhmCktc3AmA==
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------Gd0WWJFmX2WWWJIc0GMLk0Gq"
X-GND-Sasl: pierre@nothos.net
X-GND-State: clean
X-GND-Score: 0
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvgedtvdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfvffhufgtsehgtderredtvdejnecuhfhrohhmpefrihgvrhhrvgcuvfhhihgvrhhrhicuoehpihgvrhhrvgesnhhothhhohhsrdhnvghtqeenucggtffrrghtthgvrhhnpeejueetgfeigeejvdeiieeutdegieffkeettdeugeethffhhfekvefggffgieduffenucfkphepvdgrtddumegvtdgrmedukedtmeegfegrtdemtgeifhdumeeivgelsgemgedutdgvmeeffhdvvgenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvrgdtudemvgdtrgemudektdemgeefrgdtmegtiehfudemiegvlegsmeeguddtvgemfehfvdgvpdhhvghloheplgfkrfggieemvdgrtddumegvtdgrmedukedtmeegfegrtdemtgeifhdumeeivgelsgemgedutdgvmeeffhdvvggnpdhmrghilhhfrhhomhepphhivghrrhgvsehnohhthhhoshdrnhgvthdpqhhiugepveeikeejtdeggeduhfdvpdhmohguvgepshhmthhpohhuthdpnhgspghrtghpthhtohepuddprhgtphhtthhopehrphhpsehivghtfhdrohhrgh
Message-ID-Hash: BTFISU5U34VGD64ZMYLUV5QBCEW735TI
X-Message-ID-Hash: BTFISU5U34VGD64ZMYLUV5QBCEW735TI
X-MailFrom: pierre@nothos.net
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] Why the limit to RMM level 2?
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/Erd9jKc6NrnLQPCFEwhnaoPXmkw>
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,
I started reading the RPP RFCs and as there already is a good level of
discoverability in the requirements, I was wondering why the level 2 of
the Richardson Maturity Model was set as a requirement instead of fully
adhering to REST and using State Transfers in Representations?
As a concrete example, in RPP Core, message deletion goes through the
hard-coded but relative URI of "/messages/{id}", but the response
message for message polling could as well contain a "deletion" link.
Section 3.2 from RFC 9205 lists a few advantages of that approach.
I'll note that fully using REST would also accomodate some exisiting
requirements better than stopping at RMM L2:
* R9.11/R10.1: representational state transfers make it possible for
the RPP server to present links to attenuated facets of the
provisioning objects
o a read-only view (that needs authenticated access or not,
depending on the use case)
o a link to a provisioning process that has single-use
confirm/abort links
* R10.1/R10.2: when collections and object operations are provided as
representational state transfers, a generic RPP UI can present new
data elements, new object types and even some new operations to some
extent, even without prior knowledge
Curiously,
Pierre Thierry
--
pierre@nothos.net
0xD9D50D8A
- [rpp] Why the limit to RMM level 2? Pierre Thierry
- [rpp] Re: Why the limit to RMM level 2? Pierre Thierry
- [rpp] Re: Why the limit to RMM level 2? Pawel Kowalik
- [rpp] Re: Why the limit to RMM level 2? Maarten Wullink
- [rpp] Re: Why the limit to RMM level 2? Pierre Thierry
- [rpp] Re: Why the limit to RMM level 2? Pawel Kowalik
- [rpp] Re: Why the limit to RMM level 2? Pierre Thierry