IETF Logo Mail Archive

[rpp] Re: HTTP QUERY relevant for RPP ?

"Gould, James" <jgould@verisign.com> Wed, 24 June 2026 15:17 UTC

Return-Path: <jgould@verisign.com>
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 31F9B10688EE6 for <rpp@mail2.ietf.org>; Wed, 24 Jun 2026 08:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782314224; bh=N9wvhHZhI8fWgPNZwMPoTqUxCaT/xycLYl1l4oD0r/w=; h=Subject:From:To:Date:References:In-Reply-To; b=h0DX1GWSGliuswZTX3S1JtnzCP/A/vMs/MbCWujC/7JHp2yYp4Rv+TB4zl6jitEhD 0VLF6r56YGT60EfBnxEIpC/gtTuCSwvDs/JQikRYAA1gYHKUOX+2kEPGsX/swtguut Y5/CvXgPD1iq1ARm/NiIZ/DUoRanMj3beQVFG8wQ=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 ve8Ey7LT3w7f for <rpp@mail2.ietf.org>; Wed, 24 Jun 2026 08:17:03 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) by mail2.ietf.org (Postfix) with ESMTP id DCE9610688CE4 for <rpp@ietf.org>; Wed, 24 Jun 2026 08:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3528; q=dns/txt; s=VRSN; t=1782314163; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=N9wvhHZhI8fWgPNZwMPoTqUxCaT/xycLYl1l4oD0r/w=; b=mfAz61valvDlmgPxNLLQ4QfFdjdbNsTgPCtgUg16zbVhl810S7cutBEk 0R0rdVUCTprlUds/UZ9b5WPnLt9xE+35eoOTpm7hhTc5rDCo9eMna62Sw QJOZ4vH/ZP2i2hEhkr3j/YsCDF8d6es3PgrV0m3Yg8eJSTHyHnY3ooBrR e776GjzM0JkgWhZwVdXNHSg57nAC2Sea7kmHyarwWkkTYz4ypcc6iqBgF Blm0ay/Kp7lzYsXBULL8HnSuCcXtjN8ZDsIDUpclVQ/NG5qsYgQDqxf5h UpphrEOvAdw6ZG77w/Opo97l9DPQdrdEvW7SjScr2KAbbqBNgt/X8Bn07 g==;
X-CSE-ConnectionGUID: YNGV1unFT8iEI7NDWWoqsA==
X-CSE-MsgGUID: SZbnmP4UQ6KPOTaOJmOaQQ==
X-ThreatScanner-Verdict: Negative
IronPort-Data: A9a23:Wfb+7Ksc09K3vR4Fwq26ASA1vufnVChfMUV32f8akzHdYApBsoF/q tZmKWHTPfaCNjb9eYp1PI7k9x5Su5bWzNJqTAQ//yxnEysS9ZOVVN+UEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVqicfHw3HVY6IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bNNwRcawr40Ird7kkz1BjOkGlA5AJmO6oX5Aa2e0Q9V/rzG4ngdxMUfaEJRoZWd 86bpJml82XQ+QsaC9/Nut7Tbk0QT7fOChOFg3xQVrLKqkAqSvsai/tT2FI0MC+7uh3R9zxD4 IwlWa+YEG/FCpbxdNE1CHG0JQklZPEbp+WXSZSImZf7I0XuKxMAyt0wVB1mZdVwFuxfWQmi/ tRAQNwBg4zqa0tbD9tXR8E17vnPIvUHM6sunF5elCzfI8p2QL3iHIPm2uBfxSwZ05Um8fb2P 6L1aBJKTTDvOiJpF2dPUtQgl+Cynj/2f3tGskmT46Ew5gA/ziQoiP63bISTI4HQA58O9qqbj juuE2DRAB4dKdiT4SSI6HO3h+DJ2yj8Xer+EZXkpqA62AXLmQT/DjUtZ1G9pMHlt3fgeOp4F 0Uz2C8JpJELoRnDot7VGkfQTGS/lh0bRNNUEu4S5AyLy6GS7wvxLnIcVhZAZcAo8sgsSlQXO kShmtLtCmVwtrCFESjY7amO9HW3ODNQJ2hEZCsLFE0b+cLl5oo0i3ojU+peLUJ8tfWtcRmY/ txAhHFWa2k75SLT65iGwA==
IronPort-HdrOrdr: A9a23:M2Tsc6EJbAeinu8npLqENceALOsnbusQ8zAXPidKOHlom62j5q KTdZsgtSMc5Ax+ZJhCo7+90cC7KBvhHPVOkOos1NmZPTXOiS+HIIZv9oP+zzClMD2WzIJg/J YlV6RlEtX/ARxZgdaS2mOFOudl5NWc6qiniaPl0nF3QWhRBp1I9QtjFQqBKEFwSTRHAZZRLv Gh2vY=
X-Talos-CUID: 9a23:8ZHLX2wnhz6svrsSabSCBgUlPO8bK2Db4kuAImKZVkBFd4KSUES5rfY=
X-Talos-MUID: 9a23:kYPPdgR81OY3/KhKRXTXtjtkMf803p3wK3gqrZwhmcyjPBVJbmI=
X-IronPort-AV: E=Sophos;i="6.24,222,1774310400"; d="scan'208";a="48680007"
Received: from MILG1WNEX01.vcorp.ad.vrsn.com (10.246.152.21) by MILG1WNEX02.vcorp.ad.vrsn.com (10.246.152.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Wed, 24 Jun 2026 11:16:03 -0400
Received: from MILG1WNEX01.vcorp.ad.vrsn.com ([10.246.152.21]) by MILG1WNEX01.vcorp.ad.vrsn.com ([10.246.152.21]) with mapi id 15.02.2562.043; Wed, 24 Jun 2026 11:16:03 -0400
From: "Gould, James" <jgould@verisign.com>
To: "kowalik@denic.de" <kowalik@denic.de>, "rpp@ietf.org" <rpp@ietf.org>
Thread-Topic: [EXTERNAL] Re: [rpp] HTTP QUERY relevant for RPP ?
Thread-Index: AQHdA+rLSnldpxQpwku0D1wSdY1r2rZN0OYA
Date: Wed, 24 Jun 2026 15:16:03 +0000
Message-ID: <8C6C366C-3487-4A9F-A173-29A355365D00@verisign.com>
References: <f29583bd-3a80-4ad0-9a9c-8d103ccc6a1b@sidn.nl> <df474b23-3494-4717-85fd-b71ad8cbc91c@denic.de>
In-Reply-To: <df474b23-3494-4717-85fd-b71ad8cbc91c@denic.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.109.26053122
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4DFD9C9F0CF6B64E85F2529E8F3D76AC@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: IEFOHUYE4OZEEIZ3SYYQHPZMYKASKYCV
X-Message-ID-Hash: IEFOHUYE4OZEEIZ3SYYQHPZMYKASKYCV
X-MailFrom: jgould@verisign.com
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: HTTP QUERY relevant for RPP ?
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/2TVapruSsxfJGTAPXC-B0FZxAQk>
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>

We had discussed support for draft-ietf-httpbis-safe-method-w-body that is now RFC 10008 to be able to pass extensible JSON payload for the query commands (e.g., check, info, transfer query) in place of other methods (e.g., query parameter, path segment, and HTTP headers). If all requests can use a JSON payload, it would enable the definition of an extensible JSON application packet protocol, like the XML application packet protocol of EPP.  The query extensions can be done in JSON, with the biggest target being the check command extensions, such as the Registry Fee Extension in EPP.  It's nice to know that draft-ietf-httpbis-safe-method-w-body is an RFC.

-- 

JG 



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 6/24/26, 11:04 AM, "Pawel Kowalik" <kowalik@denic.de <mailto:kowalik@denic.de>> wrote:


If we face a situation of excessive query size then yes.


Jim Gould had a case of an extension with such potential, but we haven't 
studied it yet to the depth of knowing whether it exceeds capabilities 
of GET or not.


Kind Regards,
Pawel


On 24.06.26 15:44, Marco Davids (IETF IMAP) wrote:
> I was wondering, could RFC10008 be relevant to the work of this WG?
>
> https://secure-web.cisco.com/19K8GZnyXfa45tZfa5MMdC_wr-I6_e2nuxTR6IerYhDJWw2aPH6Qsu_Ay9aEYuy_5ZB3yoWRdZFHGhFsdMv6zRv6Q1xBO3-ZVLYUNKnruziZRog6DoVnJrHUs6CVjhlhqK7DWeqFzrt6W8UDQn9pv5I-MpBrtR8Q6Qd9q6z3XMovEPODrip-FzMTmy_9jqrL9RhJ0Qx_CUqO_XElBVIK5_zLFl_2pL3yBKkulkhGrrfD1glUHuqaeYbc0juiDXfgWSTgIY_djvr6tgCFgxwonIFzVkUUKzyc9KKWEZ07opJg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc10008 <https://secure-web.cisco.com/19K8GZnyXfa45tZfa5MMdC_wr-I6_e2nuxTR6IerYhDJWw2aPH6Qsu_Ay9aEYuy_5ZB3yoWRdZFHGhFsdMv6zRv6Q1xBO3-ZVLYUNKnruziZRog6DoVnJrHUs6CVjhlhqK7DWeqFzrt6W8UDQn9pv5I-MpBrtR8Q6Qd9q6z3XMovEPODrip-FzMTmy_9jqrL9RhJ0Qx_CUqO_XElBVIK5_zLFl_2pL3yBKkulkhGrrfD1glUHuqaeYbc0juiDXfgWSTgIY_djvr6tgCFgxwonIFzVkUUKzyc9KKWEZ07opJg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc10008>
>
> Abstract
>
> This specification defines the QUERY method for HTTP. A QUERY requests 
> that the request target process the enclosed content in a safe and 
> idempotent manner and then respond with the result of that processing. 
> This is similar to POST requests, but QUERY requests can be 
> automatically repeated or restarted without concern for partial state 
> changes.
>

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