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? >> 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. Thanks, Lars _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
