Folks,
\
In terms of working group process, one line of criticism demands re-opening
(and, apparently, reversing) the work of the Update (RFC 5672). I haven't seen
any working group consensus to do this nor any industry feedback indicating
this
is necessary. Consequently, attempts to pursue the content of that work is
entirely out of scope for the current working group effort.
There are two continuing threads of other, technical dissatisfaction being
expressed that are based on fundamental misunderstandings of protocol design
concepts. The discussion on Wikipedia looks pretty good, for background:
<http://en.wikipedia.org/wiki/Network_protocol#A_basis_for_protocol_design>
The easy misunderstanding is about the basic difference between software design
and protocol design. When a discussion is about a protocol specification,
reference to the vagaries of software implementers' choices means that the
discussion is no longer about the protocol.
A protocol is a contract between two or more sides of an exchange. The
contract
needs to be extremely precise so that all sides know exactly what is required
and what is meant. This includes semantics, syntax, and rules of exchange.
Semantics means all of the meaning, not just the meaning of individual fields.
And it means inputs and outputs.
That an implementer might choose to use fields creatively is their choice --
and
might even be useful -- but it goes beyond the protocol specification.
Implmenters can choose to combine specifications, implement only parts of
specification, or create additional functionality. This is all well and good,
but it is an entirely separate exercise from the details a specific protocol.
As for protocol layering, this is merely the standard construct of design
"divide and conquor" with attendant information hiding outside of a layer.
That
software might have access to information hidden from a particular layern is
sometimes useful, but it means that the software is going beyond the
specification of that layer.
Apparently the distinction between "payload" versus "overhead" is proving
challenging for some folk. The logical extension of the view that the
recipient
at one layer has access to the information below its layer means that a MIME
module must automatically and always has access to the IP and ethernet headers
of the data that contained the MIME. In terms of formal protocol
specification,
it doesn't.
Payload is what's handed to the next layer up. Everything else is overhead for
getting work done at the current layer. This distinction is basic to the
concept of design layering and the attendant information hiding. Without it,
there is no information discipline in the design of protocols. Spaghetti
protocol design is even worse than spaghetti software.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html