Hi, Phillipe (et al.),
I'm not aware of a recommended approach, but I tend to follow that of
TCP (RFC793), e.g., define as follows:
- the upper layer API in *abstract* terms (not as a Unix socket
interface)
-- this includes both events initiated by the "user" above as
well as events initiated by this service
- the internal states
- the messages and their formats (e.g., headers, etc.)
- the lower layer API expected by this service, e.g., a set of
requirements for L6 (or L4if there are no L6 or L5)
- a state transition matrix, e.g., mapping:
[internal state, input event] -> [new internal state, output
event(s)]
where input events can be receipt of a message from L6, an
action of the upper layer (user), and/or a timer expires
and output events can be sending a message to L6, signalling the
upper layer (user), and/or setting a timer
Some of the items you mention below are part of this description, e.g.,
transport (UDP/TCP) would be part of the L6 or L4 description, sequence
control is the state transition matrix, and some of the other issues are
part of the API.
I'm wondering if this sort of "what defines a protocol" description
would be useful - if so, I can prepare it in more detail.
Joe
On 12/28/2016 1:57 AM, Philippe Duke wrote:
Hello, dear IETF community. I would like to develop L7 protocol for my
application and public documentation about it. Good protocol development
is quite difficult stage, but not a problem. But at the same time, I
don't have any experience writing protocol documentations (RFC's).
What guidelines do you have?
Is the RFC 4253 (SSH) good example of document design? Should I follow
same principle?
Please give me some examples how to make it correct. Even examples of
very simple protocols.
What I need as requirements:
TCP/UDP transport
Authentication
Encryption
Sequence control
My protocol would carry small status messages like (10-20 bytes with
timestamps and some sort of sequence synchronization).
Thank you very much for your answers. Sorry for posting into the general
list.