As a note, we just pushed draft-ietf-taps-interface-24 to address the SHOULD->MUST.
Thanks, Tommy > On Dec 14, 2023, at 8:22 AM, Tommy Pauly <[email protected]> > wrote: > > > > >> 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
