]>

ietf@trammell.ch

Web and Internet Transport (WIT) HTTP port allocation IANA service registration provides guidance on the use of port numbers and the criteria for new port assignments, including a test for whether a proposed service is distinct from an existing service. It gives the example that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service." It also might not. This document clarifies the application of the distinct-protocol test in Section 7.1 to services built on HTTP as a substrate, in light of HTTP's evolution since its publication, and provides guidance to applicants and reviewers on when an HTTP-based service qualifies for a new port assignment and when it does not. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction provides guidance on when a new port assignment is warranted, including a distinctness test in Section 7.1: a new service merits an assignment only if an unmodified client of an existing service cannot interact with it. In the decade since that document was published in 2015, HTTP has become an overwhelming popular de facto substrate for application protocol design -- a development that both documents and embraces. Section 7.1's observation that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service" was intended to leave room for novel cases. The evolution of and investment in the HTTP ecosystem since then has only made the use of HTTP and the ecosystem surrounding it as a substrate more attractive. One practical consequence of this development has been some confusion about whether new protocols over HTTP are new protocols in the sense of "requiring a port assignment". This document clarifies how the Section 7.1 distinctness test applies to HTTP-based services, and provides guidance to applicants and reviewers on when it is and is not satisfied.

HTTP as an Application Transport Substrate HTTP has evolved since its origins as the basis of the World Wide Web. HTTP/2 redesigned HTTP's wire format around multiplexed binary framing with non-browser use as an explicit design goal; HTTP/3 continues this evolution over QUIC . provides detailed guidance on building new protocols beyond the web atop HTTP. The benefits of this approach are substantial: HTTP-based services can leverage existing infrastructure including reverse proxies, load balancers, content delivery networks, and firewalls; they interoperate naturally with web clients; and they inherit well-established security properties including TLS certificate management and authentication frameworks. The HTTP ecosystem also provides a rich set of mechanisms for service differentiation and discovery that do not require dedicated port assignments, such as Application-Layer Protocol Negotiation (ALPN) and Well-Known URIs supporting service discovery at different points in the protocol handshake. A service that requires a new ALPN identifier should register it in the IANA TLS ALPN Protocol IDs registry, not seek a new port assignment.

Evaluating HTTP-Based Protocols for Distinctness Section 7.1 of establishes one useful test for whether a proposed service warrants a new port assignment: can an unmodified client of an existing service interact with the proposed service? Interoperability implies non-distinctness, and a non-distinct protocol does not merit a new assignment. For HTTP-based services, this test is easy to implement: can an unmodified generic HTTP client tool such as curl issue requests to and receive valid responses from the proposed service? Service differentiation achieved through URL path structure, HTTP header values, Content-Type negotiation, payload schema, or authentication scheme does not constitute wire-level distinctness; these are application-layer conventions carried within HTTP, not independent protocols. This does not mean that all HTTP-based protocols are indistinct. Examples that might warrant an assignment include: a REST API running over the same TLS connection as a protocol with a different wire format, using a protocol-specific multiplexing scheme; or a protocol running on UDP or SCTP that uses a REST API over TCP as a control or management plane. The former would not interoperate with an unmodified client, and the latter has incomplete semantics when used as such.

Security Considerations The intended effect of the guidance given by this document is effectively to reduce port assignments for HTTP-based services, directing these services to use port 443 rather than dedicated port assignments. This has implications for overall network security: traffic from non-Web HTTP applications running on port 443 is less distinguishable from other traffic in the face of metadata examination. TLS deployment is more likely to be properly configured when services share the standard HTTPS port and its associated certificate management infrastructure, and network operators can apply consistent security policy across all services on that port. Section 4.4.3 notes that deploying an HTTP-based application on a non-default port carries privacy implications because the protocol becomes distinguishable from other traffic; the guidance in this document is consistent with minimizing that distinguishability.

IANA Considerations This document has no IANA actions. It is intended as guidance for IANA Transport Port Expert Reviewers.

References Normative References This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. Informative References This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK]

Disclosure LLM-based tools (Claude Code, Sonnet 4.6) were used in the workflow management, reference and archival research, initial draft generation, and editorial review of this document.