> On Jan 24, 2013, at 04:41, wor...@ariadne.com (Dale R. Worley) wrote: > >> From: Carsten Bormann <c...@tzi.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