Keith Moore writes:
Since nothing limits the semantics of header fields, adding a header
field can cause an arbitrary modification to the protocol.
No. Extensions are not arbitrary modifications. Extensions are designed
so that extended software interoperates with unextended software. X-Loop
software, for example, talks to non-X-Loop software without trouble,
because the non-X-Loop software simply ignores X-Loop.
It's a much more serious matter when you modify a protocol in a way that
breaks interoperability. But this has nothing to do with how you use
_new_ header fields. The issue is that you aren't using the _old_ header
fields according to the existing protocol.
If, for example, someone says ``Put the sender information into this new
Sender-Information field, and omit the From field,'' then there will be
interoperability problems. Those problems come from the omission of the
From field. They do _not_ come from the addition of the new field.
TCP and UDP ports are just a demultiplexing mechanism.
False. Thousands of ports have special meanings. Port 22, for example,
is assigned to ssh. This assignment extended the Internet protocol
suite. It allowed Tatu Ylonen to define part of the format of the data
communicated through the Internet---and to do so without ``consensus''
from control freaks like you.
They don't change the semantics of IP,
New header fields don't change the RFC 822 Appendix B parsing mechanism.
Your naive notion of ``protocol'' as ``port'' is inadequate to explain
FTP, TCPMUX, the World Wide Web, tunnels, etc. Do you really have this
much trouble seeing the entire Internet data flow as a single object?
Yes, there's a difference in scale between a typical new port and a
typical new header field, but the same extension principles apply.
You might notice that it's considerably more difficult to get approval
for new IP and TCP options than it is to get a port assignment.
Evidence? I've never asked for a new IP option, but a glance at the
IP-options list reveals several assignments to protocol extensions that
aren't documented in RFCs.
Anyway, I can understand setting a barrier for a namespace that has a
small set of possible values. But header fields don't have that problem.
---Dan