[tsvwg] Re: New Version Notification for draft-trammell-tsvwg-443-is-enough-00.txt

["Brian Trammell (IETF)" <[e-mail]>]

hi Joe,

Good question. While the language in 7605 is concise, I’m not sure it’s adequate on this point for the present moment.

The primary reason I’m spending time on this is what I perceive (but have not yet rigorously measured) as a sharp uptick in the number of requests to the port experts for port assignments for what are basically REST APIs. An informal analysis of a sample of these requests suggests that we’re seeing way more inclusion of LLM-based coding tools in the protocol design process, which drives the cost of applying for a port down, and where here the model itself may see the wiggle room in the 7605 language as an invitation to try.

I aim to achieve two things with this draft:

(1) measure and document IETF consensus (or non-consensus, through non-publication) of the proposition that port assignments for substantially HTTP applications should be a rare exception

(2) provide additional signal to models asked to specify a protocol that they do not need to bother with a port assignment in this case.

Cheers,

Brian

> On 24 Jul 2026, at 17:30, Joe Touch <[e-mail]> wrote:
> 
> On Jul 24, 2026, at 12:09 AM, Brian Trammell (IETF) <[e-mail]> wrote:
>> 
>> Greetings, all,
>> 
>> After some hallway discussion in Vienna, I’d like to bring this work to TSVWG for further discussion and development. This revision moves the draft into the -tsvwg namespace, and incorporates some changes from Christian’s comments (thanks again!)
>> 
>> I’d like to do this relatively quickly (ask for adoption at 127 or before, ask for WGLC shortly thereafter) as it’s a relatively simple proposition: augment 7605 to make it clearer when a port is warranted for applications over HTTP, and provide some commentary for application developers about why.
> 
> RFC7605 states that:
> 
> 1) HTTP is both a layer and an alias for the entire stack up to a web browser:
> 
>    As a concept, a service is the combination of ISO Layers 5-7 that
>    represents an application-protocol capability.  For example, www
>    (port number 80) is a service that uses HTTP as an application
>    protocol and provides access to a web server [RFC7230 <https://datatracker.ietf.org/doc/html/rfc7230>].  However, it
>    is possible to use HTTP for other purposes, such as command and
>    control.  This is why some current services (HTTP, e.g.) are a bit
>    overloaded -- they describe not only the application protocol, but a
>    particular service.
> 
> 2) there are mechanisms inside HTTP to demux, such that an additional port for some copies may not be needed:
> 
>       Copies of some existing services can be differentiated using in-
>       band information (e.g., URIs in the HTTP Host field and TLS Server
>       Name Indication extension) [RFC7230 <https://datatracker.ietf.org/doc/html/rfc7230>] [RFC6066 <https://datatracker.ietf.org/doc/html/rfc6066>].
> 
> 3) that such copies don’t warrant new ports, providing an objective metric for making that decision:
> 
>       Additional assigned port numbers are not intended to replicate an
>       existing service.  For example, if a device is configured to use a
>       typical web browser, then the port number used for that service is
>       a copy of the http service that is already assigned to port number
>       80 and does not warrant a new assignment.  However, an automated
>       system that happens to use HTTP framing -- but is not primarily
>       accessed by a browser -- might be a new service.  A good way to
>       tell is to ask, "Can an unmodified client of the existing service
>       interact with the proposed service?".  If so, that service would
>       be a copy of an existing service and would not merit a new
>       assignment.
> 
> Can you explain, specifically, what issue needs to be made more clear?
> 
> Joe