Hi Brian, Hi Joel,
the point of my mail was not to start a discussion about the examples I
provided but to note that the suggested let's reduce complexity by reducing
options is not as easy as it sounds in practice.
In the context of the document Stephen wrote and the proposal that was made
I do not really have time or desire to enter an extended discussion on
this document. It's pretty clear to me we just disagree. But I did
want to be on record as not supporting this document so that silence
wouldn't be taken as agreement or support.
A few specific followups below.
This
On 1/23/13 1:27 AM, Hannes Tschofenig wrote:
Hi Brian, Hi Joel,
the point of my mail was not to start a discussion about the examples I provided but to
note that the suggested let's reduce complexity by reducing options is not as
easy as it sounds in practice.
The prototypical human
John Levine jo...@taugh.com wrote:
My, what a bunch of parvenus. SIP got it from SMTP, SMTP got it from
Telnet. Back in the 1960s we all used CRLF 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
Tony == Tony Finch d...@dotat.at writes:
My, what a bunch of parvenus. SIP got it from SMTP, SMTP got it from
Telnet. Back in the 1960s we all used CRLF because on a
mechanical model 33 or 35 Teletype, CR really returned the carriage,
LF really advanced the platen, and you
On Jan 22, 2013, at 11:45 PM, Melinda Shore melinda.sh...@gmail.com wrote:
On 1/22/13 7:16 PM, Dean Willis wrote:
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.
--On Wednesday, January 23, 2013 06:15 + John Levine
jo...@taugh.com wrote:
Additionally, I can't understand why each line is terminated
with CRLF, why use two characters when one will do.
Microsoft-OS text editors. Seriously.
My, what a bunch of parvenus. SIP got it from SMTP,
Melinda Shore melinda.sh...@gmail.com wrote:
Oh, c'mon. MS products and MacOS at the time used CRLF for newlines
generally, not just in Word.
Classic Mac OS used bare CR for newlines, as did a number of 8 bit micros.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Forties,
Hi,
Regarding http://tools.ietf.org/html/draft-shafranovich-mime-sql-03,
I think the document should be more clear that there are many variants
of the SQL format and the media type is intended as umbrella type for
them all, for instance, the Abstract should refer to, say, variants of
the
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
--On Wednesday, January 23, 2013 13:45 -0500 Warren Kumari
war...@kumari.net wrote:
...
Yup, and Unix users have the ability to choose line endings:
Emacs -
M-x set-buffer-file-coding-system RET undecided-dos
...
Not exactly. Depending on the particular version/
implementation, most
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,
On Jan 23, 2013, at 20:56, John C Klensin john-i...@jck.com wrote:
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.
But John, on a TTY,
On Wed, 23 Jan 2013, John Day wrote:
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/
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
From: John Day jeanj...@comcast.net
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).
Which
A great deal of complexity comes from the fact that standards are
rarely created in a vacuum.
In this case, RFC 3261 SIP had to be upward-compatible from RFC 2543
SIP. And the early design of RFC 2543 SIP was influenced (I am told)
by the idea that SIP messages should be able to go through HTTP
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.
On Wed, 23 Jan 2013, John Day wrote:
IIR, Multics from several years earlier. I'd have to dig
through old
--On Wednesday, January 23, 2013 18:05 -0500 John Day
jeanj...@comcast.net 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.
On Wed, 23 Jan 2013, John Day
Transport Directorate review of
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but
--On Wednesday, January 23, 2013 23:29 +0100 Carsten Bormann
c...@tzi.org wrote:
On Jan 23, 2013, at 20:56, John C Klensin john-i...@jck.com
wrote:
But having CR as an unambiguous return to first
character position on line was important for overstriking
(especially underlining) on a
Hi -
From: John C Klensin john-i...@jck.com
To: Carsten Bormann c...@tzi.org
Cc: John Levine jo...@taugh.com; ietf@ietf.org;
dean.wil...@softarmor.com
Sent: Wednesday, January 23, 2013 5:20 PM
Subject: Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))
...
So, yes, some
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
On 1/23/13 4:45 PM, David Morris wrote:
VDTs with long lines might have been inspired by line printers or
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
Thanks for your comments. My understanding is that the SQL standards
as specified by ISO actually allow for variants and multiple vendor
implementations, all of which are not guaranteed to be compatible.
This is why the ISO standard specified conformance standards and
several levels of
Regarding this issue in particular, the reason why I am saying that
SQL client/server communication is out of scope for this, is because
the ISO specification addresses how that is done in several different
scenarios, including embedded and direct methods. Hypothetically, if
such communication
Hi, Allison,
Thanks so much for your feedback! -- Please find my comments in-line
On 01/23/2013 09:33 PM, Allison Mankin wrote:
It is clearly valuable to call the community's attention to the atomic
fragment in IPv6. This is an IPv6 datagram that is not actually
fragmented, but has a
The IESG has received a request from an individual submitter to consider
the following document:
- 'The application/sql Media Type'
draft-shafranovich-mime-sql-03.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Security Framework'
draft-ietf-mpls-tp-security-framework-07.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
Greetings
The 2012-2013 IETF Nominating Committee (Nomcom) is pleased to
announce the selection of two individuals to serve on the IETF
Administrative Oversight Committee (IAOC).
The Nomcom has selected Chris Griffiths to fill the current vacancy on the
IAOC. (I.e., filling the position last
A new Request for Comments is now available in online RFC libraries.
RFC 6830
Title: The Locator/ID Separation Protocol (LISP)
Author: D. Farinacci, V. Fuller,
D. Meyer, D. Lewis
Status: Experimental
Stream:
A new Request for Comments is now available in online RFC libraries.
RFC 6831
Title: The Locator/ID Separation Protocol (LISP)
for Multicast Environments
Author: D. Farinacci, D. Meyer,
J. Zwiebel, S. Venaas
A new Request for Comments is now available in online RFC libraries.
RFC 6832
Title: Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites
Author: D. Lewis, D. Meyer,
D. Farinacci, V.
A new Request for Comments is now available in online RFC libraries.
RFC 6833
Title: Locator/ID Separation Protocol (LISP) Map-Server
Interface
Author: V. Fuller, D. Farinacci
Status: Experimental
Stream:
A new Request for Comments is now available in online RFC libraries.
RFC 6834
Title: Locator/ID Separation Protocol (LISP) Map-Versioning
Author: L. Iannone, D. Saucez,
O. Bonaventure
Status: Experimental
Stream:
A new Request for Comments is now available in online RFC libraries.
RFC 6835
Title: The Locator/ID Separation Protocol Internet
Groper (LIG)
Author: D. Farinacci, D. Meyer
Status: Informational
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
RFC 6836
Title: Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)
Author: V. Fuller, D. Farinacci,
D. Meyer, D. Lewis
A new Request for Comments is now available in online RFC libraries.
RFC 6837
Title: NERD: A Not-so-novel Endpoint ID
(EID) to Routing Locator (RLOC) Database
Author: E. Lear
Status: Experimental
Stream:
38 matches
Mail list logo
