Subject: Re: A modest proposal

From: William Jordan <[email-masked]>
Date: Tue, 22 Jan 2013 05:11:09 -0500

In response to Melinda's first reply, the reason I specifically requested
an implementation in C is because I think its the language that a developer
is the least likely to hang himself with.  I've seen plenty of examples of
bad code and I think c gives the least opportunity for a developer to make
an unreadable mess.  It also is a language that is in line with my general
idea of coding, i.e. KISS (keep it simple stupid).

Continuing my discussion about how badly SIP is designed, I'm gonna talk
about the via line.  First of all each via line can be expressed as via: OR
v: OR you can have multiple via entries on the same line separated by a
comma where random whitespaces are allowed.  Additionally, I can't
understand why each line is terminated with <CR><LF>, why use two
characters when one will do.  I could also go into a design argument about
how the same specification is used for udp as for tcp and why the idea for
a stateless SIP proxy wasn't thrown out completely when writing the draft,
but I'll wait on those.

Bill

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Jan 2013 22:16:20 -0600

On Tue, Jan 22, 2013 at 4:11 AM, William Jordan <[email-masked]> wrote:

> comma where random whitespaces are allowed.

Hey, we stole that stuff from HTTP. We're not smart enough to invent
something that broken. I think HTTP stole it from RFC 822.

> Additionally, I can't
> understand why each line is terminated with <CR><LF>, why use two characters
> when one will do.

Microsoft-OS text editors. Seriously. People wanted to be able to
write correct SIP messages using text editors, and there were more
Microsoft users than Linux users on the list. And we agreed because
that's the way it works in HTTP, which got it from RFC 822 (there's a
reference in the spec, so we KNOW where that came from!)

> I could also go into a design argument about how the same
> specification is used for udp as for tcp and why the idea for a stateless
> SIP proxy wasn't thrown out completely when writing the draft, but I'll wait
> on those.

Yeah, keeping both UDP and TCP was stupid. We should've just specified
TLS, but there were all these 8-bit processors out there ... and
countries where TLS was illegal. In fact, we couldn't export a TLS
stack from the US at the time without special paperwork. So, allowing
for both protocols got us "exportable" product, and "passing the IESG
security police" at the same time.

Stateless proxies were seen as key performance enablers. Our high-end
super-performant proxy running on a $40,000 quad-core Sun box could
only get like 8 transactions a second, so every CPU optimization was
sacred.

But hey, live and learn ...

---

From: Melinda Shore <[email-masked]>
Date: Tue, 22 Jan 2013 19:45:00 -0900

On 1/22/13 7:16 PM, Dean Willis wrote:
> Microsoft users than Linux users on the list. 

Oh, c'mon.  MS products and MacOS at the time used CRLF for newlines
generally, not just in Word.  The fact that it was specified that way
in HTTP, SMTP, FTP, and others matters a bit, as well.

Melinda

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2013 06:15:54 -0000

>> Additionally, I can't understand why each line is terminated with
>> <CR><LF>, why use two characters when one will do.
>
>Microsoft-OS text editors. Seriously.

My, what a bunch of parvenus.  SIP got it from SMTP, SMTP got it from
Telnet.  Back in the 1960s we all used <CR><LF> because on a
mechanical model 33 or 35 Teletype, CR really returned the carriage,
LF really advanced the platen, and you needed both.  I first ran into
CR/LF on a PDP-6 in about 1968, but I know it wasn't new then.

A single LF to start a new line arrived with the model 37 Teletype,
and Unix was, as far as I know, the first system to use just \n as the
line terminator starting in the early 1970s.  But by then the Arpanet
protocols were designed, and the hassle of changing wasn't (and still
isn't) worth it.

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jan 2013 17:40:06 +0000

> CR/LF on a PDP-6 in about 1968, but I know it wasn't new then.

Dates back to 1930s teleprinters, I think.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jan 2013 13:13:52 -0500

>>>>> "Tony" == Tony Finch <[email-masked]> writes:

    Tony> Dates back to 1930s teleprinters, I think.

Since they were "tele"-printers, it seems obvious why *SIP* must retain
it for "tele"-phony :-)

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 Jan 2013 13:45:14 -0500

> in HTTP, SMTP, FTP, and others matters a bit, as well.

Yup, and Unix users have the ability to choose line endings:
Emacs -
M-x set-buffer-file-coding-system RET undecided-dos

VI - 
: Set fileformat = dos : W 

If you are using anything else, a: don't or b: 

tr -d '\r' < input.file > output.file

or 

perl -pi -e 's/\r\n/\n/g' input.file

or 

sed 's/$'"/`echo \\\r`/" input.txt > output.txt

or…. 

W

--
The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.

    -- (Terry Pratchett, Wyrd Sisters)

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jan 2013 14:56:23 -0500

--On Wednesday, January 23, 2013 06:15 +0000 John Levine
<[email-masked]> wrote:

>>> Additionally, I can't understand why each line is terminated
>>> with <CR><LF>, why use two characters when one will do.
>> 
> My, what a bunch of parvenus.  SIP got it from SMTP, SMTP got
> it from Telnet.  Back in the 1960s we all used <CR><LF>
> because on a mechanical model 33 or 35 Teletype, CR really
> returned the carriage, LF really advanced the platen, and you
> needed both.  I first ran into CR/LF on a PDP-6 in about 1968,
> but I know it wasn't new then.
>...

Right.  And the relationships between the standards and the
equipment was a little obscure (at least to me) in terms of what
came first.  But having CR as an unambiguous "return to first
character position on line" was important for overstriking
(especially underlining) on a number of devices including line
printers as well as TTY equipment.   A number of systems of the
mid-1960s even had device drivers that would canonicalize lines
with non-destructive backspaces into lines with CR or vice
versa, depending on the needs of the particular device.

The first version of ASCII was very specific that CR was "move
to first character position on current line" and LF was a
vertical index function.  Then the confusion began with some
company (where I was at the time, the finger was pointed at
Digital Equipment, but I have no first hand information or
documentation) who started using CR as "new line".  That left us
with systems in the wild that used LF (only) internally, ones
that used CR (only), ones that used CRLF (always the safe choice
because it worked whether LF was an index function or a new line
one), and equipment that often required the latter.  Subsequent
versions of ASCII solved the incompatibility the same way the
FORTRAN standard (this was a bit before _that_ standards
committee decided the language was named "Fortran") solved
zero-iteration loops -- by fuzzy language that made both
one-traversal and zero-traversal valid in the FORTRAN case and
that made either interpretation of LF valid.

> A single LF to start a new line arrived with the model 37
> Teletype, and Unix was, as far as I know, the first system to
> use just \n as the line terminator starting in the early
> 1970s.

IIR, Multics from several years earlier.  I'd have to dig
through old manuals to remember what CTSS did, but that system
(and the IBM Model 1050 and 2741 devices often used as terminals
with it) were somewhat pre-ASCII (and long before ECMA-48/ ANSI
X3.64 and the VT100 and friends)  and, IIR, sent and received
shift and rotate codes rather than what we would normally
consider character codes today.  The character codes were just
input to device drivers that dealt with device characteristics

>  But by then the Arpanet protocols were designed, and
> the hassle of changing wasn't (and still isn't) worth it.

Again, the key useful property of CRLF on the wire is that the
combination is fairly insensitive to the various interpretations
of CR and LF.

    john

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jan 2013 20:08:19 +0000

Melinda Shore <[email-masked]> wrote:
> generally, not just in Word.

Classic Mac OS used bare CR for newlines, as did a number of 8 bit micros.

Tony.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 23 Jan 2013 16:35:55 -0500

There was a mechancal reason for both and not just an EOL (End of Line) concept. As you point out, it was the original way to get an emulation of BOLD characters on print devices.  You control the print head and when this emulation moved to 80x25 screens, the cursor was the carriage head.  Some "Smart" terminals had a 132 columns mode to help with the emulation of Punch Cards which has 132 columns.

But to me, overall, it would of been difficult to design the interactive I/O spftware and both modem and internet hosting protocols, overall telecommunications applications without the proper translations of CR/LF simply for proper visual operations.  It was either hardware or software driven.  For example, hitting the Carriage Return key <CR>, either the device was set to also send the <LF> or the receiver did the translation and with an echo back of <LF>, the sender (now the receiver) will react to the control character.  All to make sure the visual (or print) was correct.

I'm sure with SIP the same interactive I/O translation, telecomputing, full versus half duples issues are present.  It would be been very difficult for SIP developers to do all this (text based Command/Response protocol ) in the blind and in an <LF> EOL world - something would have to be doing the translation, the device, the sender and/or receiver simply visual/print effects.

--
HLS

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jan 2013 17:18:18 -0500

> M-x set-buffer-file-coding-system RET undecided-dos

Not exactly.  Depending on the particular version/
implementation, most version of Emacs (which, unlike VI, are
distinctly not limited to Unix and were actually around before
Unix was) keep the lines in a buffer as an threaded list.  That
makes certain operations, like moving a region from one buffer
to another or inserting text in a buffer, really fast because
they don't require moving the rest of the file up or down.  How
a buffer is written to an external medium then becomes another
issue, with emacs internally being indifferent to CR, LF, CRLF,
strings delimited in other ways such as by record markers,
length-delimited lines or records, and so on.

It does make Emacs and its clones pretty convenient as a format
converter, but...

best,
   john

---

From: John Day <[email-masked]>
Date: Wed, 23 Jan 2013 17:16:30 -0500

>input to device drivers that dealt with device characteristics

Multics was based on EBCDIC which had a New Line (NL) character but 
no CR or LF.  The ARPANET went with the ASCII standard.  But I never 
forgave the ANSI committee for taking left arrow out of the character 
set (as a replacement operator).

Then there was the day that BBN loaded ASCII to EBCDIC tables into 
the TIPs that would not generate the line delete or character delete 
characters for Multics.  They said it was an accident.  ;-)

Take care,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Jan 2013 23:29:32 +0100

On Jan 23, 2013, at 20:56, John C Klensin <[email-masked]> wrote:

> But having CR as an unambiguous "return to first
> printers as well as TTY equipment.

But John, on a TTY, you have to send CR NUL, or the first character will smudge.
The carriage is still in flight when the next byte after it is processed, so it better not be a printing character.

(This is actually the real reason for CR LF:
CR needs 200 ms to execute because it takes time to move the carriage, so you have to fill in a character to waste 100 ms.
So you might as well separate the CR and LF function, which is what happened.
Multiple newlines are sent as CR LF LF LF to a real TTY because LF *does* execute in 100 ms -- moving the paper is quicker.)

Now the reason I'm writing this:

SIP has CRLF because TTY carriages smudged.  

Really.

Please let that sink in a minute.

I think in protocol evolution (as well as computer system evolution in general) we are missing triggers to get rid of vestigial features.

CRLF was quite reasonable for Telnet, as this really was about TTYs.
FTP grew out of Telnet, so keeping it there was maybe justifiable.
For SMTP, CRLF already was vestigial; this should have been fixed when SMTP became separate from FTP, but maybe the separation was too gradual (it was too late to fix it 20 years later in 282x).
Keeping CRLF for HTTP was a travesty (enjoy RFC 2616 section 19.3 para 3 for added pleasure).
Keeping it in SIP was unspeakable.

Grüße, Carsten

---

From: David Morris <[email-masked]>
Date: Wed, 23 Jan 2013 14:45:49 -0800 (PST)

On Wed, 23 Jan 2013, John Day wrote:

> Multics was based on EBCDIC which had a New Line (NL) character but no CR or
> LF.  The ARPANET went with the ASCII standard.  But I never forgave the ANSI
> committee for taking left arrow out of the character set (as a replacement
> operator).

EBCDIC has NL (new line), LF and CR characters (hex 0x15, 0x25 and 0x0d
respectively). EBCDIC was an 8 bit code easy to translate in hardware
logic from punch card codes to the 8 bit code. Earlier IBM systems
used BCD (sometimes called BCDIC) which was a 6 bit code which did
not have CR or LF but had a subset of the EBCDIC style mapping from
punched cards to computer code. IBM systems all implemented a
record based file organization rather than the character stream
of UNIX. So the BCD generation systems had a record mark charcter
(and word mark) in the pre-S/360 days with BCD and file system
level record tracking in S/360.

IBM terminal devices (e.g., 2740, 2741, 1050, etc.) of the pre VDT era
used a different character coding on the wire (not BCD). Might have
been inspired by tilt/rotate, I don't know and never worried about more
than getting the translate table right. Hardware communications
controllers and later programmable controllers recoginzed the NL
character and signaled end of line/record to the host computer.

IBM lineprinters of the era were record/line oriented devices which
printed about 132 characters per line and advanced to new like, page,
etc. based on device specific commands and not data interpretation.
ANSI line controls or IBM internal codes could be used in the first
character of the line to pre/post space 0 or more lines for each
print record.

VDTs with long lines might have been inspired by line printers or
just the idea that long lines were better. No experience there,
but I'm pretty certain there were no 132 column punch cards in
common use which would have influnced comody VDT designers. 80
and I believe 96 in S/3 days.

Dave Morris

---

From: John Day <[email-masked]>
Date: Wed, 23 Jan 2013 17:55:00 -0500

What was your source for this information?  Or 
did you just make it up? Because it is faulty.

FTP did not "grow out of Telnet."  The decision 
to use Telnet was quite conscious for both FTP 
and SMTP so that a human at a terminal on a TIP 
could be FTP or SMTP user process and was hardly 
vestigial in either case.  Crude, yes.  But 
served a very distinct purpose.

John Day

At 11:29 PM +0100 1/23/13, Carsten Bormann wrote:
>The carriage is still in flight when the next 
>byte after it is processed, so it better not be 
>a printing character.
>
>CR needs 200 ms to execute because it takes time 
>to move the carriage, so you have to fill in a 
>character to waste 100 ms.
>Multiple newlines are sent as CR LF LF LF to a 
>real TTY because LF *does* execute in 100 ms -- 
>moving the paper is quicker.)
>
>I think in protocol evolution (as well as 
>computer system evolution in general) we are 
>missing triggers to get rid of vestigial 
>features.
>
>For SMTP, CRLF already was vestigial; this 
>should have been fixed when SMTP became separate 
>from FTP, but maybe the separation was too 
>gradual (it was too late to fix it 20 years 
>later in 282x).
>Keeping CRLF for HTTP was a travesty (enjoy RFC 
>2616 section 19.3 para 3 for added pleasure).

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 23 Jan 2013 17:58:02 -0500 (EST)

> From: John Day <[email-masked]>
> 

Which suggests that the reason Unix used LF as newline was because
Unix was consciously based on Multics, and Multics had a newline but
no carriage return or line feed.

Dale

---

From: John Day <[email-masked]>
Date: Wed, 23 Jan 2013 18:05:01 -0500

Then what am I mis-remembering? ;-)  Was it that Multics didn't use 
CRLF and only NL?  I remember this as quite a point of discussion 
when we were defining Telnet and FTP.

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jan 2013 19:08:38 -0500

--On Wednesday, January 23, 2013 18:05 -0500 John Day
<[email-masked]> wrote:

> Then what am I mis-remembering? ;-)  Was it that Multics
> didn't use CRLF and only NL?  I remember this as quite a point
> of discussion when we were defining Telnet and FTP.
> 
>>>  > through old manuals to remember what CTSS did, but that
>>>  > system (and the IBM Model 1050 and 2741 devices often
>>>  > used as terminals with it) were somewhat pre-ASCII (and
>>>  > long before ECMA-48/ ANSI X3.64 and the VT100 and
>>>  > friends)  and, IIR, sent and received shift and rotate
>>>  > codes rather than what we would normally consider
>>>  > character codes today.  The character codes were just
>>>  Multics was based on EBCDIC which had a New Line (NL)
>>>  character but no CR or LF.  The ARPANET went with the ASCII
>>>  standard.  But I never forgave the ANSI committee for
>>>  taking left arrow out of the character set (as a replacement
>>>  operator).

Interesting theory, but Multics was definitely not EBCDIC-based.
The various IBM mainframes, including most importantly the UCLA
one, presumably were but Multics used a GE 645 base with (7 bit)
ASCII right justified in a 9-bit byte, four characters per 36
bit word.  That contrasted with Tenex and later TOPS-20, which
also used ASCII but as five characters in the 36 bit word with
the sign bit ignored for character purposes.

>> EBCDIC has NL (new line), LF and CR characters (hex 0x15,
>> 0x25 and 0x0d respectively). EBCDIC was an 8 bit code easy to
>> translate in hardware logic from punch card codes to the 8
>> bit code. Earlier IBM systems used BCD (sometimes called
>> BCDIC) which was a 6 bit code which did not have CR or LF but
>> had a subset of the EBCDIC style mapping from punched cards
>> to computer code. IBM systems all implemented a record based
>> file organization rather than the character stream of UNIX.
>> So the BCD generation systems had a record mark charcter (and
>> word mark) in the pre-S/360 days with BCD and file system

IIR, parts of this aren't quite right either because the
CP/67-CMS architecture (which evolved into VM/CMS) was partially
based on CTSS and didn't follow a number of "traditional" IBM
conventions.  The S/360 mainframes also supported ASCII, but in
an odd encoding in which the spare bit was in the middle of the
byte and used, again IIR, for parity rather than being always
zero.

>...
>> VDTs with long lines might have been inspired by line
>> printers or just the idea that long lines were better. No
>> experience there, but I'm pretty certain there were no 132
>> column punch cards in common use which would have influnced
>> comody VDT designers. 80 and I believe 96 in S/3 days.

That is correct.  80, 96 (with an oddly-shaped card), and the
Univac round-holed one (don't remember how many columns it ended
up with).  The bigger VDT issue was that they tended to use
character cell architectures and made a non-destructive
backspace and composed/overstruck characters (not just simulated
boldface) impossible.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jan 2013 20:20:54 -0500

--On Wednesday, January 23, 2013 23:29 +0100 Carsten Bormann
<[email-masked]> wrote:

> But John, on a TTY, you have to send CR NUL, or the first
> character will smudge. The carriage is still in flight when
> the next byte after it is processed, so it better not be a
> printing character.

Oh, my.  This is getting to be interesting.  I had no direct
interaction with or insight into the ASA (later ANSI) committee
that did ASCII so, while I heard some stories, I can't do more
than speculate on why they made some of the decisions they did.
But both Multics and CTSS supported a variety of terminal
devices -- hardcopy and CRTs (storage tube and actively
refreshed), wide and narrow, character and line-oriented, and so
on.  Between the mid-60s and the mid-70s, the devices on or next
to my various MIT desks went from 1050, to 2741, to TTY 37, to
Imlac PDS-1D, with some sort of storage tube "glass TTY" in
between.  The various hardcopy devices all had timing
idiosyncrasies until they started acquiring significant local
buffering.  The Imlac was high enough resolution (2000 points
square) that I could put it into 132 character mode, but the
characters, while sharp, got pretty small.  Those devices ran at
transmission speeds from about 10cps up to 19.2kpbs and above.
It is probably also relevant that CTSS and Multics both
preferred "half-duplex" (really non-echoplex) operation in which
there was no expectation that the remote host (or controller)
would echo back the characters that the user typed and that a
few of the relevant devices transmitted line-at-a-time rather
than character-at-a-time.

All of this led, very early, to the realization that one better
have standard coding on the system so that programs that didn't
have to be specialized to the output device for some other
reason (hard to display 2000x2000 point dynamic vector graphics
on a Teletype) operated in a device-independent way with device
drivers that adapted between the standard coding to the
particular terminal.  So, yes, some TTY units needed padding
characters or other delays and sometimes it varied depending on
the relationship between current carriage position and intended
one.  But that was a device driver problem (and lots of the
device drivers ran on peripheral controllers, not the
mainframe)-- no CTSS or Multics program that used the system
device drivers ever had a NUL or character timing as part of its
application-level data stream.  Those device drivers also did a
lot of string canonicalization, eliminating problems with string
comparison that we've reinvented with Unicode (see, e.g., the
PRECIS WG for more discussion).   If the device transmitted
NULs, they would disappear before being delivered to the
application.

> CR needs 200 ms to execute because it takes time to move the
> carriage, so you have to fill in a character to waste 100 ms.
> So you might as well separate the CR and LF function, which is
> what happened. Multiple newlines are sent as CR LF LF LF to a
> real TTY because LF *does* execute in 100 ms -- moving the
> paper is quicker.)

As I said, I wasn't part of the committee that did ASCII.   I do
know that CR was extensively used, in both our terminal
environment and in a number of ones involving line printers
without LF as a way to arrange overstriking (for bold,
underlining, and composed characters) on line-oriented devices
that couldn't handle backspacing.   Again, that was mostly in
the device drivers: an application program would see
   xxxo<BS>'yyy 
whether that was transmitted or 
   xxxoyyy<CR>   ' 
or, as mentioned earlier, whatever the first-character-of-line
printer control sequence was that would yield the same result.

I don't know the history, but have always assumed that the
experience above was one of the inputs to the development of NVT
and other terminal abstractions on the ARPANET rather that using
an "every machine needs to know the properties of every
terminal" model.  Sadly, we lost both of the people who would
have been most likely to know last year.

> SIP has CRLF because TTY carriages smudged. 

SIP has CRLF because every single application protocol we have
that uses character-oriented commands is modeled on NVT, and NVT
uses CRLF.  You can theorize all you like about how NVT got that
way (and might be right although given what I know of the way
things unfolded, I'd be a little surprised).  But it is NVT that
is the issue. 

>...
> CRLF was quite reasonable for Telnet, as this really was about
> TTYs. FTP grew out of Telnet, so keeping it there was maybe
>...

Others have commented on the above statement, but the culprit is
NVT and the decisions were very explicit, not accidents of "we
did it that way the last time so should do it again without
thinking", _especially_ after Unix became dominant on the
network.

   john

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Jan 2013 18:21:29 -0800

Hi -

> To: "Carsten Bormann" <[email-masked]>
> Cc: "John Levine" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 23, 2013 5:20 PM
> Subject: Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))
...
> So, yes, some TTY units needed padding
> application-level data stream.

It was messier than that in other environments.  Yes, device drivers,
peripheral processors, or front ends commonly dealt with whether a
particular device needed CR, LF, NL, CRLF, or something else, and
how many NULs had to be sent in order to deal with device limitations
in processing those control codes.  But the more "sophisticated"
controls, such as VT, FF, and so on, also required delays on some
devices.  (I remember one device where VT would cause it to suck
paper back into the printer in order to return to the top of the current
page.)  Sequences for line insert, line delete, and region clears / fills
on some CRTs also required padding delays.  Some got seriously
confused if the padding was omitted.  However, dealing with this
issue was put painfully close to the user application in Unix-land.
Look for "padding" in the documentation for termcap and terminfo
for a glimpse into how convoluted things became.

 ....
> printer control sequence was that would yield the same result.

In our CDC shop, security was critically dependent on this.
Since the teletypes echoed everything typed locally, there needed
to be a way to prevent even a partially-typed password from
being visible.  This was accomplished by sending a sequence
that was something like:
Password:<cr><lf>[[[[[[[[<cr>]]]]]]]]<cr>########<cr>XXXXXXXX<cr> 

Randy

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 23 Jan 2013 22:41:24 -0500 (EST)

> From: Carsten Bormann <[email-masked]>
> 
> 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.

Dale

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Jan 2013 21:50:40 -0600

On 1/23/13 4:45 PM, David Morris wrote:
> just the idea that long lines were better.

Definitely inspired by printers. I remember when we upgraded our ancient 
VT100 terminals (which didn't have wide mode) to VT220 terminals and you 
could display your output spool file (which was 132 column wide) on the 
screen without stupid wrapping and without having to print it out on the 
green and white bar paper. Ah, the things that excited us back then.

> No experience there,

Yup, cards were 80 column and printouts were 132. And of course if you 
left your VT220 in 132 column mode while you were writing code and 
accidentally went over the 80 column limit on a line or two, when you 
sent your job off to VM/CMS, you'd get back an error that your job 
failed due to "Card reader jam". Gotta love it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Jan 2013 08:15:25 +0000

> entire discussion*).  Once we've cleaned up that idiocy, we can start

Noah Webster tried that once, it turns out to lead to serious interop
problems with transatlantic communications.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jan 2013 10:22:16 +0100

> entire discussion*).  Once we've cleaned up that idiocy, we can start

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.)

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.
What I'm asking for: Apart from these big reformation projects, we also should occasionally fix little things.
When "inventing" new stuff by drawing analogies off of old specs.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Jan 2013 10:37:29 +0100

This is my last comment on the CRLF issue, which I just used as the
(for me) obvious example for what I was trying to say.

On Jan 24, 2013, at 02:20, John C Klensin <[email-masked]> wrote:

> that did ASCII 

You are off by about six decades.

CR and LF were invented around 1901 by Donald Murray and became part
of "International Telegraph Alphabet No. 2" (ITA2, now CCITT S.1),
which was originally standardized in 1932.  (That is the 5-bit code
usually (incorrectly) called "Baudot code".)  This was, of course, the
state of the art from which the standardization of ASCII started six
decades later.

I think any further discussion of these details would be off-topic,
but it does amuse me that the vestigial we are talking about is about
111 years old.

Grüße, Carsten

---

From: [email-masked]
Date: Thu, 24 Jan 2013 13:12:16 -0800 (PST)

> (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.

> 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.

> 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

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Jan 2013 00:05:36 +0100 (CET)

> entire discussion*).  Once we've cleaned up that idiocy, we can start

You mean some along the line of:

  http://everything2.com/user/m_turner/writeups/A+Plan+for+the+Improvement+of+English+Spelling

I don't think the IETF is the right forum for such a project,
and my personal feeling is that it is infeasible anyway.

While it would have probably much easier to teach everyone english
(and use ASCII), the opposite approach was taken and every piece
of technology was spoiled with I18N, L10N and Unicode, reinforcing
the communication barriers that exist throughout this world,
among machines/devices and among human beings.

-Martin