Hi, thanks for the replies. I'll trim my response to only those items where I still have questions.
On Nov 14, 2023, at 19:17, Tommy Pauly <[email protected]> wrote: >> On Sep 7, 2023, at 3:59 AM, Lars Eggert via Datatracker <[email protected]> >> wrote: >> ### Section 4.1, paragraph 8 >> ``` >> * For IETF protocols, the name of a Protocol-specific Property >> SHOULD be specified in an IETF document published in the RFC >> Series. >> ``` >> For IETF protocols, i.e., protocols published on the IETF RFC stream, >> those names must IMO be also specified in IETF-stream RFCs. I see no >> reason to let other RFC streams make definitions for IETF protocols. > > This now reads: "For IETF protocols, the name of a Protocol-specific Property > SHOULD be specified in an IETF document published in the RFC Series after > IETF review.” why is this not a MUST, i.e., when would it be appropriate to not specify this in an IETF-stream RFC? >> ### 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? >> ### Section 6.2, paragraph 0 >> ``` >> 6.2. Specifying Transport Properties >> ``` >> This section defines a boatload of different properties, many of which >> are interacting with each other due to how our current transport >> protocols are implemented. Future interactions, due to future >> transport protocols potentially becoming available, are undefined. I >> question how a potential programmer is supposed to make informed >> choices here without needing to be aware of all of this >> background/baggage? > > Please see comments on https://github.com/ietf-tapswg/api-drafts/issues/1334 > > "Complex interactions may exist between socket options in the existing BSD > sockets API. > There are also implementations of TAPS systems available, at least one of > which is fairly comprehensive. > Future interactions of properties of future protocols are also unclear in the > BSD sockets API. > > In a sense, we offer a safer set of options than BSD sockets, as we have > constrained the generic ones to the set of properties that do not constrain > selection amongst existing protocols. Everything that is protocol-specific > goes in its own protocol namespace and only applies when this protocol is > selected. The intent is for future protocol-specific options to also be > categorized that way. We cannot guarantee that no future transport protocol > will somehow be constrained by our generic properties, but the analysis in > our prior RFCs (specifically the minset RFC) leads us to believe that we have > chosen a workable subset." 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. Thanks, Lars _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
