On Jan 24, 2013, at 04:41, worley(_at_)ariadne(_dot_)com (Dale R. Worley)
wrote:
From: Carsten Bormann <cabo(_at_)tzi(_dot_)org>
I think in protocol evolution (as well as computer system evolution
in general) we are missing triggers to get rid of vestigial
features.
That's quite true. Let us start by rationalizing the spelling and
punctuation of written English (which is the coding system for *this
entire discussion*). Once we've cleaned up that idiocy, we can start
in on SIP.
I see I didn't make myself clear.
I'm not suggesting we clean up vestigials in existing spec[ie]s, such as HTTP
or SIP.
(We might even do that, see HTTPbis, but only very carefully.)
My point was about the case when we clone new stuff off existing protocols.
(SIP was cloned off HTTP which was cloned off SMTP which was cloned off FTP
which at least has had strong kinship with Telnet, hence all these use NVT.)
Actually, in regards to NVT, there's something of a break in HTTP: text
material is *not* required to use CRLF as a line terminator. Any of LF, CR, or
CRLF is permissible.
I really don't want to get into the history of this choice or for that matter
the results it has produced. Suffice it to say it has had some advantages and
some disadvantages.
Staying in your analogy: when you design a new language based on English,
please do fix some of this stuff.
(Maybe the analogy isn't that useful after all.)
Actually, we haven't been that bad about this.
E.g., we have been pretty good about getting rid of the madness of historic
character coding by focusing on UTF-8 for new designs.
But a vital part of that choice is that it is backwards compatible with
US-ASCII.
What I'm asking for: Apart from these big reformation projects, we also
should occasionally fix little things.
Or not. How about instead of viewing these sorts past choices as things to be
fixed, we instead view them as what they were: Choices. And then decide, based
on the actual requirements of whatever we're doing, whether or not it makes
sense to make a change.
Sure, we can design some new format with LFs or CRs or maybe even line or page
separators as line breaks instead of CRLFs. And maybe that makes sense in some
cases. Or not: Such choices can have serious consequences if any degree of
backwards compatibility with exiting transfer services is desired. And constant
transcoding of stuff to make it work in various places is not necessarily a
winning approach.
When "inventing" new stuff by drawing analogies off of old specs.
I really don't think unthinking copying from past specifications is the issue
here, your asssertions to the contrary notwithstanding.
Ned