The Teapot Protocol Specification (Draft)

**Version:** 0.2 (Draft) **Date:** 2024-12-11 1. Introduction The Teapot Protocol is envisioned as a conceptual extension or experimental variant of HTTP and HTTPS. Its primary goal is to explore enhanced negotiation mechanisms, stricter security requirements, and specialized operational features that may not be present in current HTTP implementations. At this stage, the protocol is registered as a *Provisional* URI scheme with IANA under the names teapot (clear-text) and teapots (TLS-encrypted). This provisional registration allows us to avoid name collisions and further refine the specification over time. 2. URI Schemes The protocol defines two URI schemes: - teapot: for clear-text interactions - teapots: for encrypted interactions (TLS required) Both schemes align with RFC 3986 and RFC 7595. Over time, they may serve as a framework for advanced web services that require more flexible resource interactions and custom semantics beyond what current HTTP provides. 3. Capability Negotiation Servers implementing the Teapot Protocol may include a Teapot-Capabilities header in responses, enumerating supported protocol features, extensions, and capabilities. Clients can use these hints to adapt their requests and behavior accordingly. Example: Teapot-Capabilities: features=ext-auth,enhanced-caching,custom-methods 4. Security & Authentication All teapots: interactions MUST occur over TLS 1.3 or higher, using modern cipher suites to ensure confidentiality and integrity. Sensitive operations should be authenticated and authorized via a TP-Auth header or equivalent method. The exact mechanisms are still under consideration as this is an evolving, exploratory specification. 5. Status Code 418 The protocol acknowledges HTTP status code 418 ("I'm a teapot") as a unique signal, but at this stage, its usage and semantics may diverge from the original HTTP easter egg. The future direction of this code will depend on community feedback and the eventual goals of the protocol. 6. Internationalization All textual identifiers MUST be UTF-8 encoded. URIs referencing non-ASCII characters MUST be converted to IRIs per RFC 3987 and percent-encoded as needed, ensuring global interoperability and consistent resource identification. 7. Versioning & Extensibility The protocol aims to support version negotiation and extensibility. A Teapot-Version header may be used in the future to facilitate smooth evolution of the protocol. As this specification matures, these features will be defined more concretely. 8. Next Steps Since this is a provisional registration, the Teapot Protocol specification is not yet finalized or standardized. Feedback from the community will guide the refinement of these ideas, and subsequent drafts will add detail, clarify behavior, and provide more rigorous security considerations. For more information and updates, see: [https://specification.teapotprotocol.com](https://specification.teapotprotocol.com) **Contact Information:** - Name: Karwan Stark - Email: [email protected] - Organization: Teapot Protocol - Domain: [https://teapotprotocol.com](https://teapotprotocol.com)