> On Apr 5, 2017, at 9:55 PM, Joe Touch <[email protected]> wrote: > > > > On 4/5/2017 12:46 PM, Michael Welzl wrote: >> There isn’t much; Nagle is an example - RFC 1122 just says that the >> functionality to enable / disable must be there, without specifying via >> which primitive that would happen. >> So, my draft says, in pass 2: >> >> o DISABLE_NAGLE.TCP: >> Pass 1 primitive / event: not specified >> >> Seems like I should do the same for set_auth and get_auth. > Set_auth and get_auth are either in the STATUS (as per my previous > message) or SEND/RECEIVE.
What’s the problem with defining new primitives for these things? It’s just an abstract API anyway. I actually removed STATUS in my draft because of the following reasoning (quoting my own draft): *** The 'status' primitive was not included because [RFC0793] describes this primitive as "implementation dependent" and states that it "could be excluded without adverse effect”. Moreover, while a data block containing specific information is described, it is also stated that not all of this information may always be available. *** Because a TAPS system should be able to rely on things that are available pretty much everywhere, this draft doesn’t include things that are optional for an underlying transport to implement. > There may be other signals that need to be specified. E.g., RFC1122 has > a few items that need to be indicated, but isn't clear about them being > only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4). Exactly my point - disabling Nagle is one of these things. So I gave them names and call them primitives under “CONNECTION.MAINTENANCE”. Shouldn’t matter, as long as the functionality is there? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
