[ih] IEN's as txt

[Joe Touch]

Hi, Dave,


On 2/10/2017 5:28 PM, Dave Crocker wrote:
> On 2/10/2017 3:31 PM, Joe Touch wrote:
>> A protocol consists of a FSM specification:
>>     - those messages that are exchanged (sent or received) "on the wire"
>>     - state
>>     - events sent/received to the next layer up
>>     - time events
>>     - the relationship between the above events and states (a transition
>> table)
>
>
> Actually, the constraint to the comms channel perspective has
> historically been extremely helpful in getting people to focus on
> machine-independent interoperability rather than to fall back on
> defining things in terms of APIs, as has become increasingly common.
A protocol that transmits RFC793-compatible segments but does not
support the equivalent of open() and close() calls is not TCP.

I'm speaking of the abstract API, as is described in RFC793, not the
details of how that's rendered in Unix as socket calls.

> Issues of 'state' derive from the rules about what PDUs are allowed
> when and what they must/may contain.

State is context for those rules. E.g., the same PDU can cause different
events depending on the state. I can't see how they could be "derived".

> However the point about provider and consumer interfaces -- that is,
> interacting with the layers below and aove -- for an engine
> implementing the protocol is a different matter and frequently gets
> inadequate attention.  
That's what I call the APIs (there are two - one above, and one below -
for TCP, these include open() and close() above as well as send() and
receive() segments below).

> The concept of protocol 'payload' often provides helpful assistance in
> getting folk to distinguish between information that is 'within' the
> protocol mechanism versus information that is external to it.

I'm not sure I understand that. The payload describes the messages
between the endpoints. There are other messages - e.g., from the user,
from other protocols (e.g., ICMP) and from timers that also affect the
protocol mechanism. The rules for how all of those are handled are part
of the protocol - IMO, the specification of the parameters of the
accept() or connect() calls is as much part of TCP as the segment layout
description.

Joe