> On Dec 14, 2023, at 6:27 AM, Lars Eggert <[email protected]> wrote:
>
> Hi,
>
> On Dec 14, 2023, at 16:13, Tommy Pauly <[email protected]>
> wrote:
>>>>>
>>>>> How would a developer know what the default endpoint was?
>>>>
>>>> The “default” endpoint is the one that the application developer
>>>> themselves provided that didn’t include a protocol-specific binding. In
>>>> the example above, that’s the port 443 endpoint, while there’s a
>>>> protocol-bound endpoint that uses port 8443.
>>>
>>> OK, but where in the example does it set that the default it TCP/TLS? The
>>> only thing specified for the "default" is port 443 - is something inferring
>>> TCP/TLS based on the port?
>>
>> The default isn’t explicitly set to TCP/TLS there—it’s the endpoint
>> address/host/port details that are set as default. So it’s saying “use this
>> default endpoint for any protocol that’s used, except if quic is chosen
>> because I know it uses a different port”. Theoretically if the stack could
>> choose TLS/TCP, QUIC, and something else like SCTP, that default would apply
>> to everything other than QUIC.
>
> so *any* protocol other than QUIC would be OK on port 443? SCTP, DCCP, TCP
> with TLS and without?
Of the protocols that could be automatically selected, yes. However, there
would not be a case where you’d be using TCP with and without TLS for one
connection — the requirements for a transport security protocol aren’t optional
or added or removed like that.
The most common case here is that there isn’t any protocol override, and you’re
accessing the same endpoint that might be over TLS+TCP or QUIC. Note that the
stack itself can learn about different ports from SVCB records, etc, as it
discovers alternative transports/ALPNs as well. This is exactly what we’ve been
doing in our Network.framework and it has not been a problem for developers in
practice.
Thanks,
Tommy
>
> This exchange - which we don't need to continue, I think we're beyond the
> point where progress is being made - reinforces my belief that either I don't
> understand something fundamental about TAPS, or it's simply not really making
> the developer experience clearer or easier.
>
> Thanks,
> Lars
>
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
