Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

[Tommy Pauly <[e-mail]>]

> On Dec 14, 2023, at 6:27 AM, Lars Eggert <[e-mail]> wrote:
> 
> Hi,
> 
> On Dec 14, 2023, at 16:13, Tommy Pauly <tpauly=[e-mail]> 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
>