draft-ietf-regext-epp-https-02 early Httpdir review

Mark Nottingham via Datatracker <noreply@ietf.org> Sun, 30 November 2025 22:42 UTC

Received: by mail2.ietf.org (Postfix) id 668DD92D1DC5; Sun, 30 Nov 2025 14:42:36 -0800 (PST)
Delivered-To: ietfarch-httpbisa-archive-bis2juki@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 655D592D1DC4 for <ietfarch-httpbisa-archive-bis2Juki@mail2.ietf.org>; Sun, 30 Nov 2025 14:42:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -5.284
X-Spam-Level:
X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.017, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="j7irHJKR"; dkim=pass (2048-bit key) header.d=w3.org header.b="YqjLzn0y"
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 kEsU7dlaRkx9 for <ietfarch-httpbisa-archive-bis2Juki@mail2.ietf.org>; Sun, 30 Nov 2025 14:42:36 -0800 (PST)
Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2236892D1DBF for <httpbisa-archive-bis2Juki@ietf.org>; Sun, 30 Nov 2025 14:42:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Date:Reply-To:Message-ID:Cc:To:From:Content-Type:MIME-Version :In-Reply-To:References; bh=U5jA9ABPZvNyylQ++hyeVluO+sfq7XMEw2vwi1kmVYM=; b=j 7irHJKRQPb6Uo0ERKQwceZDLTFQmV3wm0GfJYg7sY06Sh1P0RbdVfq0tevsuaCszzjnuU2p5leVow gKBmmxc8DNBwDZtkiIRluanz6qjw1Yk+QEzgOCC1bjbyN0HnNJgibgoEBlw9ier9o2o3iNbD1pWup COTId5u4mxzHoNVY7mD8V2aCFbU9fY57qMTNn0Yv9+6Pu8EA1pKutP9El0Kckds6Xi0th+YKdfFpg li8YfpbGabz2P87jNmvbefojMS3jIajGtBrGPibPqbouP+DKy/sCCpTzuhNrkKStJBCn6Lc0py9no 35C7QRo3Lh6Zn6iBGQTBEZG54iF6qpinQ==;
Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1vPq6s-00C8Nl-2d for ietf-http-wg-dist@listhub.w3.org; Sun, 30 Nov 2025 22:41:38 +0000
Resent-Date: Sun, 30 Nov 2025 22:41:38 +0000
Resent-Message-Id: <E1vPq6s-00C8Nl-2d@mab.w3.org>
Received: from ip-10-0-0-224.ec2.internal ([10.0.0.224] helo=puck.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <noreply@ietf.org>) id 1vPq6p-00C8Mk-0r for ietf-http-wg@listhub.w3.internal; Sun, 30 Nov 2025 22:41:35 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Date:Reply-To:Message-ID:Subject:Cc:To:From:Content-Type:MIME-Version :In-Reply-To:References; bh=U5jA9ABPZvNyylQ++hyeVluO+sfq7XMEw2vwi1kmVYM=; t=1764542495; x=1765406495; b=YqjLzn0yYKnuDwN6a4hMIrOniS56vQyw+OLXNorDVNepPT6 4BOMnmJI2rDJW92njd0t11Mw6EJuI0Wx6WgAkxYJIaje8CynCxjSNtBcPShazU44UvRAJnGD8P5re c/OyRtUoDRdUBanXyBx5OpSr+GFcYEmPtlLPnK849LuZYXcO0LFF4XtLjEtQ0CNDXMCKlaT3y1Gb2 DZwU44HwhkX1Ga5a1NfK3BO9G3yIaqm683S6d7oRh9ZsUi1NjiYPK5GOoMUToHUJT94xjPl1u3nCK CvCFeKUzmgVS05RroAxSNadAlrfTCk6lOJ5jlK6ti042HX+NNEdvkIZKyZyuVtMg==;
Received-SPF: pass (puck.w3.org: domain of ietf.org designates 166.84.6.31 as permitted sender) client-ip=166.84.6.31; envelope-from=noreply@ietf.org; helo=mail2.ietf.org;
Received: from mail2.ietf.org ([166.84.6.31]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <noreply@ietf.org>) id 1vPq6o-003736-2C for ietf-http-wg@w3.org; Sun, 30 Nov 2025 22:41:35 +0000
Received: from [10.244.8.105] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 748F092D16A4; Sun, 30 Nov 2025 14:41:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mark Nottingham via Datatracker <noreply@ietf.org>
To: ietf-http-wg@w3.org
Cc: draft-ietf-regext-epp-https.all@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.54.0
Auto-Submitted: auto-generated
Message-ID: <176454249136.3548121.4346033076650919385@dt-datatracker-5bd94c585b-wk4l4>
Reply-To: Mark Nottingham <mnot@mnot.net>
Date: Sun, 30 Nov 2025 14:41:31 -0800
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_PASS=-0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: puck.w3.org 1vPq6o-003736-2C 31fce2c7cf0ee447cee57b2d929d8d2d
X-Original-To: ietf-http-wg@w3.org
Subject: draft-ietf-regext-epp-https-02 early Httpdir review
Archived-At: <https://www.w3.org/mid/176454249136.3548121.4346033076650919385@dt-datatracker-5bd94c585b-wk4l4>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/53578
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Document: draft-ietf-regext-epp-https
Title: Extensible Provisioning Protocol (EPP) Transport over HTTPS
Reviewer: Mark Nottingham
Review result: Not Ready

This draft violates many aspects of BCP56, and needs substantial revision to
address that.

That's because it's tunnelling a protocol over HTTP semantics (primarily POST).
Doing so prevents many benefits of using HTTP from being realised and may cause
deployment issues.

I would recommend mapping the semantics of EPP more faithfully to HTTP -- e.g.,
<create> to PUT, <delete> to DELETE. This would be a substantially new version
of EPP but would be much more integrated into the HTTP ecosystem. We can look
for volunteers from the HTTP community to help with this direction if there's
interest.

Failing that, if the authors wish to tunnel, they should do so using CONNECT
rather than over HTTP semantics (such as POST).

The draft has other issues (including interoperability concerns) that I won't
list here as the decision above needs to be made first.