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

["Anantha Ramaiah (ananth)" <[e-mail]>]

 
> > 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.

I don't think so. The API's specified by 793 needs to treated as
illustrational purposes only, they are not supposed to be interpreted as
standards. Like you noted above : "It specifies an API" not "the API".
Now RFC 793 doesn't talk about sockets, it doesn't talk about SO_LINGER
and SO_KEEPALIVE for example, does it mean that any stack which
implements API's not mentioned by RFC 793, isn't compliant? Nope.  

Again for example Keepalive option is very common in all TCP stacks, now
RFC doesn't mention about TCP keepalives, 
does it make a particular TCP stack which implements Keepalive
non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would
become non-compliant :-)

So, the point in short is if I have an socket API, which tells TCP,
abort this connection after a stipulated time in persist state, the TCP
implementation can start a timer (a new timer OR overload an unused
timer) the moment the connection enters persist state, and can tear down
the connection after the timer expiry. This action would be treated as
compliant to 1122 as would the OS running a timer in it's own context
and killing the TCP connection. The key point is that resulting action
is the same no matter which method you chose to exercise a particular
protocol action.

> 
> > 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

True but protocol (TCP) is one thing, upper (application) and lower
layer (IP) interfaces is another. The protocol compliance is measured by
"if I send something, what do you I get in response" "If I send
something in state X, is the behaviour as defined by the standard?".
Upper layer and lower interface are simply local and they tend to evolve
and that is benefit of a generic design of a particular protocol layer.

> 
> 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.

Right, but these are the basic API's. The API's tend to expand and
evolve and as long as their evolution doesn't "disturb" the standard,
then we are golden.

-Anantha


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