Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
...
>> If you're asking to extend the TCP API to include access to a 
>> TCP timer for this purpose - and thus to make that standard 
>> (which is what an API extension would require), I think the 
>> consensus has been that lazy application design is not a 
>> motivation for unnecessarily overcomplicating the TCP API.
> 
> Not sure what you mean above. RFC Compliance applies to protocol, not to
> API. 

Please see RFC793. It specifies an API. Although the IETF avoided APIs
for a while, my understanding is that they are again considered relevant
standards work.

> API is a local thing. One implementation can use sockets, whereas
> other can using something totally different, what matters is what is
> sent on the wire and the response which is received. 

A protocol is defined by:

	- formats of packets sent on the wire
	- state at the endpoints
	- events that cause state transitions, packet emissions,
	  and signals to the application, triggered by:
		- packets arriving
		- upper layer commands (i.e., "application" events)
		- time

RFC793 is a good example of this set.

The upper layer commmands and signals to the upper layer constitute the
API, and it is as much a part of the protocol as packets on the wire.
Although there are a variety of ways to implement a SEND, RECEIVE, OPEN,
CLOSE, STATUS, or ABORT, all TCP implementations must include them in
their API, and they and their basic arguments are specified in RFC793.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm