harald.alvestrand@elab-runit.sintef.no (01/21/91)
In article <9101150218.AA10632@polya.Eng.Sun.COM>, pv@eng.sun.COM (Peter Vanderbilt) writes (as an example of what not to do): |> |> Requiring the use of one of CRLF or LF as line delimiters (rather |> than allowing both). |> Just to be sure that nobody will think that both are allowed now: I fought a digging-through-the-standards action last week, and the standard referenced by X.400 (IA5) plainly states that the LF alone "moves the printing position to the same position on the next line". It has been unchanged at least since 1980. So it is perfectly legal to write your messages with LFs only, but the formatting is required to look like this when you print it. (BTW, RFC-821/822 requires CRLF.......) Harald Tveit Alvestrand Harald.Alvestrand@elab-runit.sintef.no C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald +47 7 59 70 94
pv@eng.sun.COM (Peter Vanderbilt) (01/23/91)
> In article <9101150218.AA10632@polya.Eng.Sun.COM>, pv@eng.sun.COM (Peter > Vanderbilt) writes (as an example of what not to do): > > |> > |> Requiring the use of one of CRLF or LF as line delimiters (rather > |> than allowing both). > |> > Just to be sure that nobody will think that both are allowed now: > > I fought a digging-through-the-standards action last week, and the > standard referenced by X.400 (IA5) plainly states that the LF alone > "moves the printing position to the same position on the next line". > It has been unchanged at least since 1980. [...] Harald (Alvestrand) is correct about this as far as the IA5 body part is concerned -- CRLFs are the right thing to use. But as far as the to-be-defined external body parts, I'd recommend allowing lines to be delimited by either LF or CRLF. The reason for this is to allow the mail system to move application data transparently from user to user, in particular between a user on an operating system that uses LF and a user on one that uses CRLF. If the mail system is required to muck with the data, it will complicate implementations and configuration, and thus slow deployment of 88 X.400. It does mean that applications need to be tolerant of the other line delimiting form. Are there standard applications (spreadsheets, etc.) for which this would be a problem? I've heard that most applications are already tolerant because of file sharing between dissimilar OSs. Is this correct? Pete
kenw@noah.arc.ab.ca (Ken Wallewein) (01/23/91)
> But as far as the to-be-defined external body parts, I'd recommend >allowing lines to be delimited by either LF or CRLF. Better allow bare CRs, too; that's what Macintoshes use. And LF<NUL>CRs and similar combinations, probably; I've seen them used elsewhere. In an 'pure ASCII' environment, any number of CRs and NULs, so long as adjacent to a single LF, appear to be the same thing, and should be probably considered a single line terminator. /kenw
GRZ027%DBNGMD21.BITNET@cunyvm.cuny.edu (Peter Sylvester +33 1 69823973) (01/23/91)
I found some old mail where I cited from Cen/Cenelec ENV 41 201:
The control characters that may be used with guranteed effect are a
subset consisting of the format effectors 0/10 (LF) and 0/13 (CR)
provided they are used in one of the following combinations:
CR LF to start a new line
LF ... LF to show empty lines (always after one of the preceding
combinations
Peter Sylvester EARN Association, ParisOSmith@acorn.co.UK (Owen Smith) (01/24/91)
In article <9101222001.AA17316@polya.Eng.Sun.COM> pv@eng.sun.COM (Peter Vanderbilt) writes: >But as far as the to-be-defined external body parts, I'd recommend >allowing lines to be delimited by either LF or CRLF. The reason for >this is to allow the mail system to move application data transparently >from user to user, in particular between a user on an operating system >that uses LF and a user on one that uses CRLF. I'd rather see each line encoded as a seperate ASN.1 string, with no delimiters in ie. implicit delimiter at the end of each string. Thus the target system can put whatever delimiters it needs in, and doesn't have to hunt for them. There are some systems that like just CR and nothing else, so your CRLF or LF scheme falls flat and the software would have to hunt for all occurences of LF or CRLF. It can be done, but having each line as a seperate ASN.1 string makes things a lot easier. Also, having seperate strings makes memory-efficient processing easier. You can pull one of the strings into memory, process it, and write the results back out to disk before getting the next string. You CAN do this when faced with a single 25 MegaByte ASN.1 primitive string for the whole document, but it is easier with lots of smaller strings. Also, I'm a bit worried about this trend towards "just carry the whole thing as binary data" approach. What if the "whole thing" contains integers for formatting information as well as text? And what if those integers are stored in an ambiguous byte ordering? ASN.1 was invented to help us do this sort of thing, so why not use it instead of inventing our own weird and wonderful schemes. Owen. The views expressed are my own and are not necessarily those of Acorn.
enag@ifi.uio.no (Erik Naggum) (01/24/91)
In article <10469*kenw@noah.arc.ab.ca>, Ken Wallewein writes: > But as far as the to-be-defined external body parts, I'd recommend >allowing lines to be delimited by either LF or CRLF. Better allow bare CRs, too; that's what Macintoshes use. And LF<NUL>CRs and similar combinations, probably; I've seen them used elsewhere. In an 'pure ASCII' environment, any number of CRs and NULs, so long as adjacent to a single LF, appear to be the same thing, and should be probably considered a single line terminator. /kenw Arguments like this one is the reason that CRLF is the Right Thing. -- [Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no> My opinions. Wail: +47-2-836-863 Another int'l standards dude.
Stef@ICS.UCI.EDU (Einar Stefferud) (01/24/91)
Come on now you guys! Cut that out! IA% is defined to be an external transfer format, and it is not ambiguous as to what it means in every case, as I read what hs een quot4ed from various standards, including RFC822 and RFC821. Now, if we start mucking it up with verious internatl conventions, and mix them together, we weil simply destroy the whole concept of an external format! It seems all to obvious to me that when you decode the ASN.1 trhat contains IA5, that you can easily make all teh right translations between the external format and your specific internal conventions in each instance. So, lets just go back to using IA% and ASN.1 and RFC822 as they were written, without mucking them up! Onward! Cheers...\Stef
pv@eng.sun.COM (Peter Vanderbilt) (01/26/91)
> > But as far as the to-be-defined external body parts, I'd recommend > >allowing lines to be delimited by either LF or CRLF. > > Better allow bare CRs, too; that's what Macintoshes use. And > LF<NUL>CRs and [...] > Arguments like this one is the reason that CRLF is the Right Thing. Since recommending that lines be terminated by either LF or CRLF, I've come 180 degrees and now agree that CRLF is the right thing for all text body parts. Owen's proposal > I'd rather see each line encoded as a seperate ASN.1 string, with no > delimiters in ie. implicit delimiter at the end of each string. [...] is OK also but you might need to add elements that correspond to the other control characters (like form-feed). Pete