[Uri-review] Permanent Registration Request for New URI Schemes: teapot and teapots

Karwan <admin@karwan.dev> Tue, 10 December 2024 11:20 UTC

Return-Path: <admin@karwan.dev>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD3C151083 for <uri-review@ietfa.amsl.com>; Tue, 10 Dec 2024 03:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=karwan.dev
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjP1Zipla-Ya for <uri-review@ietfa.amsl.com>; Tue, 10 Dec 2024 03:20:24 -0800 (PST)
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (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 ietfa.amsl.com (Postfix) with ESMTPS id A9CE5C151068 for <uri-review@ietf.org>; Tue, 10 Dec 2024 03:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karwan.dev; s=protonmail; t=1733829620; x=1734088820; bh=IIGr93Qpu/PbbAnCjP923092eOIn8sTs/oLS86XH/wA=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=cce/FKcNtgHlVcJ4PNRA7nroh3egWAblzXLcNFIs39vWQZCRKDsDjAFq6Hrvb4oJD tKYa6Vuox6H6B+e4ex1Uq7DpOT2flALhmpUg8vsUYgyjTfokqPdAdxrTMbLvfsh2G9 5XZJZf96t7/I/324uF/5r1LLS6JFuwMb0Lb3HvhN3zDFg4k5g8MBVT1amLLJZ3TTyu A6mRDeCwhaZHVtX0hr5JkKccJze4JUFfcCIDqB+fqf1WWxENvEewSx9KVDJxlpD0qu UN/Vz3ZIEPO67SxCIlodzfTWXoYyV72LXJCXnB58+nasZ26u81Ccs4hckLePhEDHep ufTKLEqZvr7lA==
Date: Tue, 10 Dec 2024 11:20:15 +0000
To: "iana@iana.org" <iana@iana.org>
From: Karwan <admin@karwan.dev>
Message-ID: <RZSMIABmyQaW7TwNGgwbxAWnHglwK3S9KVtZbQiBS1_sjP6Ec9PiQlZs46iQv4fgpe_kBuLOCF8yY0tCEADfEale3MgCkE1vP-8gI1AEz2A=@karwan.dev>
Feedback-ID: 113172566:user:proton
X-Pm-Message-ID: f8d1c280d3b1c1bd5072e3de1a27f9966dfa484d
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1=_QTjxMsz3kFws8qJQj214BRrTw77sDhwufF9PEiFchM"
X-MailFrom: admin@karwan.dev
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-uri-review.ietf.org-0
Message-ID-Hash: MEZP5QJFN5CU4366XCJOHRDX7Q6KG4M2
X-Message-ID-Hash: MEZP5QJFN5CU4366XCJOHRDX7Q6KG4M2
X-Mailman-Approved-At: Tue, 10 Dec 2024 07:02:43 -0800
CC: "uri-review@ietf.org" <uri-review@ietf.org>, "base@teapotprotocol.com" <base@teapotprotocol.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Uri-review] Permanent Registration Request for New URI Schemes: teapot and teapots
List-Id: Proposed URI Schemes <uri-review.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/Pb7jLm3xMabPgjilspWAxSCRMnE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Owner: <mailto:uri-review-owner@ietf.org>
List-Post: <mailto:uri-review@ietf.org>
List-Subscribe: <mailto:uri-review-join@ietf.org>
List-Unsubscribe: <mailto:uri-review-leave@ietf.org>

Dear IANA,

On behalf of the Teapot Protocol (me being the owner of https://teapotprotocol.com/) I respectfully request the permanent registration of two new URI schemes: teapot and teapots.

Overview:
The Teapot Protocol is a forward-compatible, secure, and extensible evolution of HTTP/HTTPS semantics. It introduces enhanced negotiation mechanisms, stringent security requirements, and specialized operational features, all while maintaining a familiar foundation aligned with existing web standards. The teapot and teapots schemes function similarly to http and https, offering both clear-text and encrypted variants, respectively.

URI Schemes:

- teapot: for clear-text interactions
- teapots: for secure, TLS-encrypted interactions

These schemes conform to RFC 3986 and RFC 7595. The teapots scheme mandates TLS 1.3 or higher, ensuring robust confidentiality and integrity.

Intended Applications: The Teapot Protocol is designed for a wide range of advanced web applications, services, and infrastructures. By extending well-understood HTTP paradigms, it provides a stable and future-proof platform for next-generation services that require enhanced security, flexible negotiation, and more granular control over resource interactions.

Contact Information:

- Name: Karwan Stark
- Email: admin@karwan.dev
- Organization: Teapot Protocol
- Domain: [https://teapotprotocol.com](https://teapotprotocol.com/)

Change Controller: Karwan Stark (admin@karwan.dev) on behalf of Teapot Protocol. Any future change control will adhere to RFC 7595 procedures.

Reference: A preliminary draft of the Teapot Protocol Specification is available at:
[https://specification.teapotprotocol.com](https://specification.teapotprotocol.com/)
(This document is intended to be published as an Internet-Draft and eventually as an RFC.)

Semantics and Operations:

- teapot: URIs map to resources accessible via a clear-text protocol.
- teapots: URIs provide equivalent functionality but require TLS, ensuring secure interactions.
- Standard methods (GET, POST, PUT, DELETE, etc.) apply, with optional advanced capabilities enabled through a Teapot-Capabilities header.
- HTTP status code 418 ("I'm a teapot") is reserved as a standardized code for signaling unique resource conditions.

Unique Requirements:

-

Strict TLS Mandate for teapots:
All teapots: URIs MUST be served over TLS 1.3 or higher, using modern cipher suites.

-

Capability Negotiation:
Servers can advertise supported features via Teapot-Capabilities. Clients adapt dynamically to available functionality.

-

Internationalization and Canonicalization:
Full support for IRIs (RFC 3987) ensures global interoperability. Non-ASCII characters must be UTF-8 encoded and percent-encoded as needed.

-

Authentication and Authorization:
Certain operations require valid credentials. A TP-Auth header and OAuth2.0-based flows are recommended to ensure secure operations.

-

Long-Term Utility and Versioning:
Teapot-Version enables version negotiation, allowing the protocol to evolve gracefully while maintaining backward compatibility.

Interoperability and Deployment: The teapot and teapots schemes integrate seamlessly with existing URI parsing logic, simplifying adoption. Gateways and proxies may bridge between these and traditional HTTP/HTTPS services, ensuring gradual and scalable deployment. Clear guidance on feature negotiation supports smooth interoperability as the protocol matures.

Demonstrable, Long-Lived Utility: By blending familiarity with forward-looking enhancements, the Teapot Protocol ensures stable, long-term applicability. Its secure, extensible nature supports evolving standards and infrastructure, meriting the request for permanent registration.

---------------------------------------------------------------

We respectfully request IANA's review and approval for the permanent addition of the teapot and teapots URI schemes. Please contact me if additional information or clarification is required.

Thank you for your consideration.

Submitted by: Karwan Stark
Teapot Protocol
admin@karwan.dev
Date: 2024-12-10