Subject: line terminator

From: Tim Showalter <[email-masked]>
Date: Tue, 20 May 1997 23:15:00 -0400 (EDT)

You have your choice of two reasonable choices:

LF|CRLF|CR: This works with any OS that purports to save files in ASCII
text.

CRLF: This is what a standard does normally.

If it's LF|CRLF|CR, you can assume that it'll be saved that way on the file
system and the mail server can just read this file.

If it's CRLF, Unix and Mac users won't be able to just drop in a new
filter; they'll have to run a conversion program.  (So it's a syntax
checker too; this isn't necessarily a bad decision.)

What's in the draft, as I had intended it (not that I've read the draft
recently, not that it's without error) is that a newline is any of the
three and an implementation is required to turn them into a CRLF when
printing out a message for servers.  This is what made *me* happy; it is by
no means the right solution.

I feel like a skunk for arguing this and not just conceding that
all-the-world-is-either-CRLF-or-should-be, but I'm going to anyway.

-- 
                                           Tim Showalter [email-masked]

---

From: Rob Earhart <[email-masked]>
Date: Tue, 20 May 1997 23:47:16 -0400 (EDT)

> CRLF: This is what a standard does normally.

  The only problem with LF|CRLF|CR is that it *doesn't* work with any
OS - you can't read files that were created on another platform.

  We could just let it be LF|CRLF|CR, and leave it up to the transfer
mechanism / editors to do the translation... (this is the approach
HTML takes, although I'm not sure whether that's an argument for or
against :-)

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Fri, 23 May 1997 16:52:49 -0700 (PDT)

> CRLF: This is what a standard does normally.

I find LF|CRLF|CR completely unacceptable.

A format needs to have a *single canonical* form.  I don't care if you map
that canonical form to your local system newline conventions as long as it
is crystal clear that it has to be mapped back to canonical form before
sending to another system.

Case study 1: Postscript
On different systems postscript ends up with different newline
conventions.  If you map the newline conventions it can break the
postscript document since there can be embedded binary.  So postscript
files on some systems don't work on other systems.

Case study 2: TIFF
The TIFF file format allows either big-endian or little-endian encoding
(it's very clear in the spec).  But many implementations only support one
of the two encodings, so many implementations now have options to generate
one or the other in order to interoperate.  Ever seen a "Mac Tiff" or "PC
Tiff" checkbox?  I have.

Let's not repeat the mistakes of the past.  If there's only one format,
there's only one way to do a parser which seems to work, and it will work
with everything.  If there's multiple formats, there's multiple ways to do
a parser which seems to work, and so it won't work with everything.

---

From: Thomas Down <[email-masked]>
Date: Mon, 26 May 1997 15:25:22 +0100 (BST)

> a parser which seems to work, and so it won't work with everything.

This runs into _big_ problems for users who want to edit their sieves
by simply dropping them into a text editor on the machine the sieve will
run on perhaps their UNIX box, or, as in my case, my Risc PC. I admit this
objection may not be valid for users who are storing their sieves with ACAP
or something, but these will be in a minority to start with. It is not
viable to rely on people being able to edit files with your chosen line
terminator easily on a given system.

Whatever the decision, I _will_ accept LF as a line terminator in my
implementation, even if I immediately deprecate this... It will be 
sufficiently useful to me and my alpha test group that it would be 
stupid not to accept this. 

If we specify that the line terminator is CR|CRLF|LF (any of these
acceptable) then there will NOT be a compatibility problem. _All_
compliant implementations MUST accept all three.

Regarding the PostScript case, I doubt we'll see binary inlined into
sieves. The only place it is meaningful is in an autoreply, and it 
probably ought to be BASE64-encoded there anyway. To be quite honest,
I hope I don't live to see the day when people add binary attachments
to autoreply messages anyway...

Thomas
-- 
Interalia design - purveyors of fine mailers since 1998 (maybe)

---

From: Steve Hole <[email-masked]>
Date: Mon, 26 May 1997 10:11:40 -0600 (MDT)

> CRLF: This is what a standard does normally.

I would make the text canonical and always use CRLF.   Most 
mail applications already have canonical->local line translators in them 
to support saving RFC822 text to local files.   In the worst case, a Mac 
or UNIX editor will just show the extra line end character.   The other 
way around, you end up with lines all running together.    

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6

---

From: Tim Showalter <[email-masked]>
Date: Tue, 27 May 1997 00:38:01 -0400 (EDT)

I believe concensus is for CRLF and have put that in the draft.