Hi Lars, > On Dec 12, 2023, at 10:42 AM, Lars Eggert <[email protected]> wrote: > > Hi, > > On Dec 12, 2023, at 19:48, Tommy Pauly <[email protected]> wrote: >>>>> ### Section 6.1.3, paragraph 6 >>>>> ``` >>>>> In order to scope an alias to a specific transport protocol, an >>>>> Endpoint can specify a protocol identifier. >>>>> >>>>> AlternateRemoteSpecifier.WithProtocol(QUIC) >>>>> ``` >>>>> This is the first and only time protocol identifiers are used. What >>>>> are they defined to be? >>>>> >>>>> >>>>> ### Section 6.1.3, paragraph 9 >>>>> ``` >>>>> The following example shows a case where example.com has a server >>>>> running on port 443, with an alternate port of 8443 for QUIC. >>>>> >>>>> RemoteSpecifier := NewRemoteEndpoint() >>>>> RemoteSpecifier.WithHostname("example.com") >>>>> RemoteSpecifier.WithPort(443) >>>>> >>>>> QUICRemoteSpecifier := NewRemoteEndpoint() >>>>> QUICRemoteSpecifier.WithHostname("example.com") >>>>> QUICRemoteSpecifier.WithPort(8443) >>>>> QUICRemoteSpecifier.WithProtocol(QUIC) >>>>> >>>>> RemoteSpecifier.AddAlias(QUICRemoteSpecifier) >>>>> ``` >>>>> Why does the `RemoteSpecifier` definition not contain a `WithProtocol` >>>>> clause for TCP/TLS? And what would that look like, given that TCP/TLS >>>>> is a protocol combination? >>>> >>>> These comments around protocol-specific endpoints are addressed with >>>> https://github.com/ietf-tapswg/api-drafts/pull/1408 and >>>> https://github.com/ietf-tapswg/api-drafts/pull/1451 >>>> >>>> The text now clarifies that the values for the protocol scoping here are >>>> implementation-provided enumerations. >>>> >>>> "To scope an Endpoint to apply conditionally to a specific transport >>>> protocol (such as defining an alternate port to use when QUIC >>>> is selected, as opposed to TCP), an Endpoint can be >>>> associated with a protocol identifier. Protocol identifiers are >>>> objects or enumeration values provided by the Transport >>>> Services API, which will vary based on which protocols are >>>> implemented in a particular system." >>>> >>>> The reason to show one protocol being specified with an override is to >>>> show how there’s a default endpoint that the connection should use, and it >>>> should conditionally load an alternate when using a particular protocol. >>>> This then doesn’t constrain the protocol stacks being used, but only >>>> customizes the endpoint in case a particular protocol is loaded. >>> >>> 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. > >>> I'd argue that "safer" is in the eye of the beholder. I'll certainly agree >>> that TAPS is trying to provide a more principled and more abstract >>> interface to transport functions (also also that the socket API's >>> platform-dependendness is terrible), but at least a developer with >>> sufficient motivation can concretely implement their desired behavior. I >>> remain unconvinced that an abstraction like TAPS will lead to a stable >>> developer experience esp. over time and across platforms. >> >> It’s certainly fair to have a different opinion on how the usefulness and >> stableness of various transport/socket options will play out over time. >> >> Personally, I think the best philosophy for setting options on a connection >> / socket should be to set the minimum set required, so as to not >> unnecessarily constrain the behavior of the stack. If an application sets >> many options that can eventually only be satisfied by a set of existing >> protocols, and not some future as-yet-undesigned protocols, then indeed the >> connections will be constrained to use the existing protocols that work. But >> apps that only set the options they strictly need will allow for more >> variation. >> >> Are there specific changes you are thinking of for the document? > > I don't, and that was a comment (i.e., not part of the discuss), so I don't > expect changes. Understood, thanks. Tommy > > Thanks, > Lars > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
