Specifying the service interface a protocol provides (and what it
requires from other protocols) is often very useful. And is something
we have done in many cases.
Writing a set of subroutine definitions in some specific language is, in
my experience, usually far less useful.
As a related note, a program is not a protocol spec, and a protocol spec
is not an implementation design document. They serve different purposes
and should not be conflated.
Yours,
Joel
On 3/30/2011 7:02 AM, Joe Touch wrote:
...
RFC793 is a great example that a protocol provides a service, and that
service needs to be explained - and that explaining it does NOT need to
be done in a specific language.
...
And yes, it is still one of the great RFC; is that because it describes
something that became rather popular or is it because it describes
something so well that popularity was inevitable?
I think the latter; it understood that a protocol is:
A- format on the wire of messages that arrive and depart
B- state within participating parties
C- events from/to the upper layer
D- rules that relate the three above
The "API" as we commonly call it is "C" above. I've seen quite a few
IETF "protocols" that focus only on "A".
IMO it takes all four to be complete.
Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf