fsc-0077

Section D., I quote... Tear Line: This sub-field contains a
tearline (not to exceed 35 characters including the
leading "---" characters. This line is required on all
echomail messages.

I have seen some 60+ character tear lines, for example:
"--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125"

--
.. Ozz Nixon
... Author ExchangeBBS (suite)
.... Since 1983 BBS Developer

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)

On 2019 Mar 22 17:49:36, you wrote to All:

fsc-0077

Section D., I quote... Tear Line: This sub-field contains a
tearline (not to exceed 35 characters including the
leading "---" characters. This line is required on all
echomail messages.

that's an old FSC that was never standardized... tearlines are not even required in fidonet by the standard that is in place...

I have seen some 60+ character tear lines, for example:
"--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125"

tearlines and origin lines and even message body lines have artificial limits placed on them because folks got used to 80x25 terminals... they look very funny when viewed on terminals with larger widths...

trivia: do you know how/why tearlines got their name and what they were used for?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I believe in Traditional Values ! The earth is flat.
---
* Origin: (1:3634/12.73)

Re: Desired Living Document (section): Author Compliance
By: mark lewis to Ozz Nixon on Sat Mar 23 2019 11:37 am

tearlines and origin lines and even message body lines have artificial limits placed on them because folks got used to 80x25 terminals... they look very funny when viewed on terminals with larger widths...

*SBBS* has a bug, I just noticed the last two emails I have "quoted" it is putting the incorrect initials ... VC should be ML... :-/

Anyway, would it be worth implementing a Kludge for flowed - when found 0d is ignored and paragraphs get formatted by the reader? This is how JAMNNTPd works - in my NNTP server code I dropped flowed since it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can handle >80 columns.

That would make ^aCOLS: 80^m make a little more sence ;)
Ozz
--- SBBSecho 2.12-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Desired Living Document (section): Author Compliance
By: Ozz Nixon to mark lewis on Fri Apr 12 2019 03:31 am

Re: Desired Living Document (section): Author Compliance
By: mark lewis to Ozz Nixon on Sat Mar 23 2019 11:37 am

tearlines and origin lines and even message body lines have

artificial
limits placed on them because folks got used to 80x25 terminals... they look very funny when viewed on terminals with larger widths...

*SBBS* has a bug, I just noticed the last two emails I have "quoted" it

is
putting the incorrect initials ... VC should be ML... :-/

1. You posted this using an 8-year old version of *SBBS*:
X-FTN-PID Synchronet 3.15b-Win32 Oct 17 2011 MSC 1200

2. It's possible the message editor you're using created the quotes, not *SBBS*.

Anyway, would it be worth implementing a Kludge for flowed - when found 0d is ignored

From FTS-1:
A 'hard' carriage return, 0DH, marks the end of a paragraph, and must
be preserved.

I hope there's no FTS software that is ignoring "0d".

and paragraphs get formatted by the reader? This is how JAMNNTPd
works - in my NNTP server code I dropped flowed since it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can handle >80 columns.

That would make ^aCOLS: 80^m make a little more sence ;)

I'm not really clear what you're proposing. The writer (the entity that adds control paragraphs to messages) doesn't know what the reader can or cannot do. If you want to send messages over FidoNet with 3000 character lines, you should be able do that without any special control lines. It's up to the consumer/viewer to try to beautify the messages for display (or not). The COLS value just assists with re-word-wrapping, if necessary or desired, for the nice display of message text.
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Apr 12 03:31:24, you wrote to me:

tearlines and origin lines and even message body lines have
artificial limits placed on them because folks got used to 80x25
terminals... they look very funny when viewed on terminals with
larger widths...

*SBBS* has a bug, I just noticed the last two emails I have "quoted"
it is putting the incorrect initials ... VC should be ML... :-/

nope... that bug is in the editor that xxcarol has in place... she was told about the bug and the fix years ago... she still hasn't taken care of it by installing the updated/fixed editor :shrug:

Anyway, would it be worth implementing a Kludge for flowed - when
found 0d is ignored and paragraphs get formatted by the reader? This
is how JAMNNTPd works - in my NNTP server code I dropped flowed since
it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can
handle >80 columns.

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used for but why do i want to display a message artifically restricted to 80cols on my 125 character wide terminal? why can't it just be displayed out to 125 instead of squashed to the left? that's like in one of the mailing lists i/we read, someone is apparently using a mobile device at times because their posts are all squashed left into 40cols or less... that's just rediculous... i don't care
if they only have 40cols to read/write but don't force that shite on me and my terminal...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You know, just like real life.
---
* Origin: (1:3634/12.73)

Hey mark!

i don't care if they only have
40cols to read/write but don't
force that shite on me and my
terminal...

Amen. BTW the paragraph I quoted the
above from is 562 characters wide and
splits into 4 lines on a 160 character
wide screen. Just for fun this is what
my reply would look like if replying on
a crippled mobile device with shoddy
software that imposes the device's
physical limitations on an entire
network.

Looks like crap from this angle.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hallo Maurice!

Looks like crap from this angle.

Consider this confirmation.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

On 2019 Apr 12 17:27:58, you wrote to me:

i don't care if they only have
40cols to read/write but don't
force that shite on me and my
terminal...

Amen. BTW the paragraph I quoted the
above from is 562 characters wide and
splits into 4 lines on a 160 character
wide screen. Just for fun this is what
my reply would look like if replying on
a crippled mobile device with shoddy
software that imposes the device's
physical limitations on an entire
network.

Looks like crap from this angle.

looks like crap here, too :lol:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Any idiot can use the Internet-and many do!
---
* Origin: (1:3634/12.73)

Hello mark,

12 Apr 19 09:18 at you wrote to Ozz Nixon:

i don't know... i understand it for what it is intended to be used for
but why do i want to display a message artifically restricted to
80cols on my 125 character wide terminal? why can't it just be
displayed out to 125 instead of squashed to the left? that's like in
one of the mailing lists i/we read, someone is apparently using a
mobile device at times because their posts are all squashed left into 40cols or less... that's just rediculous... i don't care if they only
have 40cols to read/write but don't force that shite on me and my terminal...

I don't know about you but I don't think a Fidonet message should be telling my message reader how to behave when it comes to my display. Like you, I have a wide display (I'm logged into a regular console window). I prefer having a smaller font to fit more on the screen...well, as long as I have my reading glasses on. :)

Methinks people are overcomplicating things.

Later,
Sean

... A sysop and his money are soon parted.
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hello Maurice,

12 Apr 19 17:27 at you wrote to mark lewis:

Looks like crap from this angle.

I agree. Not all of us are teathered to cell phones.

Later,
Sean

... When all else fails, read the instructions.
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hallo Sean!

I agree. Not all of us are teathered to cell phones.

Speaking of MBSE, I did manage to login via ssh into the BBS the other day and noticed that the display is cp437 instead of utf8. I went into the user configuration menu to make sure it was set to utf8 and it was/is. I haven't actually done anything there beyond reading messages so I don't know what will happen if I actually post a message with real utf8 characters.

Should I check or should I post a message to a local area there and see how that works out?

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice,

12 Apr 19 19:28 at you wrote to me:

Should I check or should I post a message to a local area there and
see how that works out?

Go right ahead. It is set to CP437 but I believe you can change your own codepage. I've not done it myself.

Later,
Sean

... Hockey is a game played by six good players and the home team.
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hallo Kees!

I rather like it, it saves a lot of energy on eye movement.

I have a 4 line x 20 character serial lcd (white text on blue background) that doesn't require any eye movement at all, either up/down or sideways. Great for
users with tunnel vision I would think but only 80 characters total on a full screen. Even a fully bloated tweet cannot be viewed in one go.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hallo Kees!

When I found out that UTF8 was supported, I did a minor trial.

I am thinking I might give that a try on the raspberry pi 3+ running the CanadARM. It also has native utf8 support built into everything that matters.
It should be a good testing platform methinks.

Also toying with the idea of replacing joe with nano on there. Do you know if that is easily doable?

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice!

12 Apr 19 17:27, you wrote to mark lewis:

Amen. BTW the paragraph I quoted the
above from is 562 characters wide and
splits into 4 lines on a 160 character
wide screen. Just for fun this is what
my reply would look like if replying on
a crippled mobile device with shoddy
software that imposes the device's
physical limitations on an entire
network.

Looks like crap from this angle.

I rather like it, it saves a lot of energy on
eye movement. ;))

Kees

--- GoldED-NSF/LNX 1.1.5-b20100318
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Maurice!

12 Apr 19 19:28, you wrote to Sean Dennis:

Speaking of MBSE, I did manage to login via ssh into the BBS the other day and noticed that the display is cp437 instead of utf8. I went into the user configuration menu to make sure it was set to utf8 and it was/is. I haven't actually done anything there beyond reading messages so I don't know what will happen if I actually post a message with real utf8 characters.

Should I check or should I post a message to a local area there and see how that works out?

I ran MBSE on a Raspberry for some time. When I found out that UTF8 was
supported, I did a minor trial. My impression was that Michiel Broek did
a good job, but lacking users/testers still had some debugging to do.

I do not know when he implemented utf8 and ipv6, but to me they were like
easter eggs. When I enabled ipv6 on system , only expecting ipv6 connections
with Wilfred, I noticed that I connection to Michiel Broek were also made
using Ipv6. Later, long after Michie had left Fidonet, I found that there
was also support for Utf8. Due to his knowledge from day job, he was far
ahead of all of us.

Kees

--- GoldED-NSF/LNX 1.1.5-b20100318
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

On 2019 Apr 12 23:57:48, you wrote to Maurice Kinal:

Amen. BTW the paragraph I quoted the above from is 562 characters
wide and splits into 4 lines on a 160 character wide screen. Just
for fun this is what my reply would look like if replying on a
crippled mobile device with shoddy software that imposes the device's
physical limitations on an entire network.

Looks like crap from this angle.

I rather like it, it saves a lot of energy on eye movement. ;))

wait! you move your eyes when reading? is that like moving your lips when reading? <gd&r>

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... A politician is a fellow who will lay down your life for his country.
---
* Origin: (1:3634/12.73)

Hello Kees,

13 Apr 19 00:02 at you wrote to Maurice Kinal:

I found that there was also support for Utf8. Due to his knowledge
from day job, he was far ahead of all of us.

There is a lot of undocumented features hiding out in MBSE like MBDiesel, his scripting language, and a lot of features that never were discussed. I don't know C very well but I'm learning. There's a lot of bugs to be sure but slowly we're working on it.

Later,
Sean

... Whenever I think, I make a mistake. - Roger Stevens
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hello Maurice,

12 Apr 19 22:35 at you wrote to Kees van Eeten:

Also toying with the idea of replacing joe with nano on there. Do you know if that is easily doable?

Yeah, just modify jpico, joe's emulator of pico. ;)

Later,
Sean

... WinErr 001: Windows loaded - System in danger
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hallo Sean!

Yeah, just modify jpico, joe's emulator of pico. ;)

That would be too easy. Besides that isn't what I asked, but now that you bring it up I get the impression that it is my system that has to supply a working version of joe in the first place. If that is so then it seems to me that somewhere there is a configuration for it somewhere in mbse that might be open to replacement of joe with nano which I know for a fact can handle utf8 characters. I am not too sure about joe but I suppose I can easily find out if
indeed I must supply the working copy that mbse will then use.

Are my above assumtions valid? In the meantime I'll have a looksee at joe to see if there are any utf8 issues no matter which emulation. I already know that I'll be sticking with vim for everything I do that requires an editor. Nothing beats it.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice!

13 Apr 19 03:53, you wrote to Sean Dennis:

That would be too easy. Besides that isn't what I asked, but now that
you bring it up I get the impression that it is my system that has to supply a working version of joe in the first place. If that is so
then it seems to me that somewhere there is a configuration for it somewhere in mbse that might be open to replacement of joe with nano
which I know for a fact can handle utf8 characters. I am not too sure about joe but I suppose I can easily find out if indeed I must supply
the working copy that mbse will then use.

MBSE uses the joe already installed on the system. I've never tried it, but it should be possible to use nano. However, nano may not support some of the features of joe that led Michiel Broek (the original author of MBSE) to select it as the default full screen editor for use with MBSE.

Are my above assumtions valid? In the meantime I'll have a looksee at
joe to see if there are any utf8 issues no matter which emulation. I already know that I'll be sticking with vim for everything I do that requires an editor. Nothing beats it.

That's certainly your privilege to do so. If it works for you, there's no reason to change.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hallo Andrew!

MBSE uses the joe already installed on the system.

That is what I thought but confirmation is always good. I already have looked at joe-4.6 and have confirmed it can properly handle utf8 characters, or at least the ones I threw at it. I forgot to check word wrapping and whether or not it adds unwanted linefeeds on long lines. I did with nano-4.0 as it has switches that can be used to control such things.

the default full screen editor for use with MBSE

On Sean's BBS full screen is only 80 characters. On the local joe I compiled yesterday it is the same as whatever terminal I used and for my default one (linux) it is 160 characters and counts multibyte characters as one character.
That wasn't what I saw on Sean's BBS. If I do install MBSE I will then see if that indeed is a limitation. As for utf8 characters it looks like it should work but might be limited to 80 characters. Hopefully MBSE counts characters correctly unlike some web servers I've seen in action.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Re: Desired Living Document (section): Author Compliance
By: mark lewis to Ozz Nixon on Fri Apr 12 2019 09:18 am

On 2019 Apr 12 03:31:24, you wrote to me:

tearlines and origin lines and even message body lines have
artificial limits placed on them because folks got used to 80x25
terminals... they look very funny when viewed on terminals with
larger widths...

*SBBS* has a bug, I just noticed the last two emails I have "quoted"
it is putting the incorrect initials ... VC should be ML... :-/

nope... that bug is in the editor that xxcarol has in place... she was told about the bug and the fix years ago... she still hasn't taken care of it by installing the updated/fixed editor :shrug:

Anyway, would it be worth implementing a Kludge for flowed - when
found 0d is ignored and paragraphs get formatted by the reader? This
is how JAMNNTPd works - in my NNTP server code I dropped flowed since it was really messing up BBS_ADS and a couple other echos. I thinking adding ^aFORMAT: flowed^m would help in the cases that people can handle >80 columns.

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used for but why do i want to display a message artifically restricted to 80cols on my 125 character wide terminal?

Sorry, but you don't understand the intention of those control line then. I'd be happy to discuss it.
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Apr 14 01:32:20, you wrote to me:

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used
for but why do i want to display a message artifically restricted to
80cols on my 125 character wide terminal?

Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.

maybe i don't fully understand it, then... why would i or my terminal care about the width of the original writer's screen if we're not going to use that value on our end some how?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... My bacon's not gonna kill me.
---
* Origin: (1:3634/12.73)

mark lewis wrote to Rob Swindell <=-

maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen if we're not going
to use that value on our end some how?

Perhaps for formatting reasons such as a table or somesuch? I don't really know either. I'd never heard of the COLS kludge until this conversation.

Later,
Sean


... Sattinger's Law: It works better if you plug it in.
--- MultiMail/Win
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Re: Desired Living Document (section): Author Compliance
By: mark lewis to Rob Swindell on Sun Apr 14 2019 09:10 am

On 2019 Apr 14 01:32:20, you wrote to me:

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used
for but why do i want to display a message artifically restricted to
80cols on my 125 character wide terminal?

Sorry, but you don't understand the intention of those control line then. I'd be happy to discuss it.

maybe i don't fully understand it, then... why would i or my terminal care

about the width of the original writer's screen i

we're not going to use that value on our end some how?

It has nothing to do with artificially restricting anything. It allows an intelligent message viewer (e.g. Synchronet) to re-wrap
messages for nice display by knowing the difference between a 39 character line
of text that was:
a. that length because of the result of a word-wrapping due to being written with a 40 column terminal, or
b. that length because the author intended for the line to be short (e.g. drawing a table)

It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the formatting
originally intended (hopefully) by the message's author.
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob!

15 Apr 19 02:45, you wrote to mark lewis:

@COLS: 132
Re: Desired Living Document (section): Author Compliance
By: mark lewis to Rob Swindell on Sun Apr 14 2019 09:10 am

On 2019 Apr 14 01:32:20, you wrote to me:

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used
for but why do i want to display a message artifically restricted

to

80cols on my 125 character wide terminal?

Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.

maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen i we're not going
to use that value on our end some how?

It has nothing to do with artificially restricting anything. It allows an intelligent message viewer (e.g. Synchronet) to re-wrap messages for nice display by knowing the difference between a 39 character line of text that was: a. that length because of the result of a word-wrapping due to being written with a 40 column terminal, or b. that length because the author intended for the line to be short (e.g. drawing a table)

It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the formatting originally intended (hopefully) by the message's author.

Is not that, why Fidonet makes a distict between a hard and a soft return
0d versus 8d

Kees

--- GoldED-NSF/LNX 1.1.5-b20100318
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Re: Desired Living Document (section): Author Compliance
By: Kees van Eeten to Rob Swindell on Mon Apr 15 2019 12:34 pm

Hello Rob!

15 Apr 19 02:45, you wrote to mark lewis:

@COLS: 132
Re: Desired Living Document (section): Author Compliance
By: mark lewis to Rob Swindell on Sun Apr 14 2019 09:10 am

On 2019 Apr 14 01:32:20, you wrote to me:

That would make ^aCOLS: 80^m make a little more sence ;)

i don't know... i understand it for what it is intended to be used
for but why do i want to display a message artifically restricted

to

80cols on my 125 character wide terminal?

Sorry, but you don't understand the intention of those control line
then. I'd be happy to discuss it.

maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen i we're not going
to use that value on our end some how?

It has nothing to do with artificially restricting anything. It allows

an intelligent message viewer (e.g. Synchronet) t

re-wrap messages for nice display by knowing the difference between a

39 character line of text that was: a. that length

because of the result of a word-wrapping due to being written with a 40

column terminal, or b. that length because the

author intended for the line to be short (e.g. drawing a table)

It allows an intelligent viewer to make *more* use of the available

columns to display messages while retaining the

formatting originally intended (hopefully) by the message's author.

Is not that, why Fidonet makes a distict between a hard and a soft return
0d versus 8d

That's a good question. I haven't see any BBS message editors that insert a so-called "soft CR" and FTS-1 says they (character
0x8d) should be ignored when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall
send/receive "soft CRs"?
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Good ${greeting_time}, Rob!

15 Apr 2019 03:49:58, you wrote to Kees van Eeten:

That's a good question. I haven't see any BBS message editors that
insert a so-called "soft CR" and FTS-1 says they (character 0x8d)
should be ignored

s/ignored/treated as all other printable characters like 0x8C or 0x8E/

when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall send/receive "soft CRs"?

No.

Also, in the half of Fidonet any special processing of this character is considered technical AB.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Hello Rob!

15 Apr 19 03:49, you wrote to me:

Is not that, why Fidonet makes a distict between a hard and a soft
return
0d versus 8d

That's a good question. I haven't see any BBS message editors that insert a so-called "soft CR" and FTS-1 says they (character 0x8d) should be ignored when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall send/receive "soft CRs"?

My impression has always been, that the soft CR's will be interted where
the author wants to have line breaks and the hard RC is the end of a
paragraph. When you want paragraphs formatted to your own screen width, you
can ignore the soft CR's.

If your screen width allows for it, you can follow the intent of the author
by following the soft RC's.

If the author want to present tables, he should end every line with a hard CR.
In that case the line will be folded, if the author uses line lengths above
your screen width.

When viewers follow your @cols kludge, I could imagine that lines, wider
that the viewers screen, can be concatenated and possibly the screen can be
be shifted left and right, to keep the layout integrity of the message.

I am not aware of editor inserting of CR's but Tom Jennings editor certainly
did. There must be others as well. For personal use I made several message
viewers, where I had reason to converted soft CR's to hard CR's.
In these quickies, that usually saved me from having to parse paragraph
long lines.

As for acceptance for system specific kludges. If you think they are
usefull, intoduce them. If other developers follow, great. If many do, it
is time to write a FTS document.

As for semingly useless kludges, many usenet and e-mail gateways preserve all
or many RFC header line in kludges. Nobody complains there.

Kees

--- GoldED-NSF/LNX 1.1.5-b20100318
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hello Rob Swindell!

15 Apr 19 03:49:59, Rob Swindell wrote to Kees van Eeten:

0x8d) should be ignored when importing packets, so that whole concept just

seems to be an anachronism. Does anyone actually send/receive "soft CRs"?

The Rusians do when they write in CP 866. 0x8D is the Cyrilic character ''. (Looks like 'H' and is pronounced as 'N'). 0x8D allso appears in some well formed UTF-8 sequences.
Modern decent software ignores the archaic use of the soft return and treats 0x8D as a printable character or as part of a multi byte printable character. Or at least has an option to do so. Today the majority of Fidonet messages is written in Cyrillic and the users of that language get very annoyed at softare treating 0x8D the archaic way.


Michiel


--- goAtEd-windows/386 1.0.5-154-a1826692
* Origin: (2:280/5555)

On 2019 Apr 14 19:54:54, you wrote to me:

maybe i don't fully understand it, then... why would i or my terminal
care about the width of the original writer's screen if we're not
going to use that value on our end some how?

Perhaps for formatting reasons such as a table or somesuch? I don't really know either. I'd never heard of the COLS kludge until this conversation.

it is brand new ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Watch your step when you immediately know the one way to do anything.
---
* Origin: (1:3634/12.73)

Hello Rob,

15 Apr 19 02:45 at you wrote to mark lewis:

It allows an intelligent viewer to make *more* use of the available columns to display messages while retaining the formatting originally intended (hopefully) by the message's author.

So my guess was right. Well, you learn something new every day. :)

Later,
Sean

... Never program and drink beer at the same time.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hello mark,

15 Apr 19 13:05 at you wrote to me:

it is brand new ;)

I was gonna say that's something I'd not heard of before. While I'm no expert programmer, I try to have a semi-decent knowledge of the archaic ways of Fidonet message kludges...

Later,
Sean

... Clones are people two.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

That's a good question. I haven't see any BBS message editors that insert a so-called "soft CR" and FTS-1 says they (character
0x8d) should be ignored when importing packets, so that whole concept just seems to be an anachronism. Does anyone actuall
send/receive "soft CRs"?

FWIW,

Actually PCBoard has *always* supported Soft_CR, QuickBBS v1.0 and all
the descending clones have supported Soft_CR - mainly due to Adam's
design of the message base - it really needed it as everything is stored
as 255 char strings.

A few existing systems do, as I had to reformat when storing into my
newsgroup server software (final destination).

Ozz
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: Fido Since 1991 | QWK by Web | BBS.FIDOSYSOP.ORG (1:123/140)

As for semingly useless kludges, many usenet and e-mail gateways preserve a

or many RFC header line in kludges. Nobody complains there.

That is what I had to do with my newsgroup server. I actually rewrote
the JAMmb API to accomodate a backbone news feed. In it, I have logic
that is ^aCOLS exists then force the Content-Type to non-flowed. 2nd
piece of logic is (if none of the body has a Hard CR prior to column 60
in what appears to be a paragraph - then I turn on format=flowed,
otherwise I still keep that off.

In weeks of testing, I have found that 99% of the time, that logic is
spot on - allowed newsgroup readers on laptops and mobile devices to
read BBS_ADS correctly, the FILE listings, versus these type of
standard messages. (right now I am on DOCs BBS, as my Fidonet flow is
still dead).
--- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: Fido Since 1991 | QWK by Web | BBS.FIDOSYSOP.ORG (1:123/140)

Hi OZZ,

On 2019-04-18 11:21:06, you wrote to ROB SWINDELL:

That's a good question. I haven't see any BBS message editors that

insert a -> so-called "soft CR" and FTS-1 says they (character ->
0x8d)
should be ignored when importing packets, so that whole concept just -> seems to be an anachronism. Does anyone actuall -> send/receive "soft

CRs"?

This non standard quoting style works terrible, when requoted... :-(

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 2019 Apr 18 17:48:36, you wrote to OZZ NIXON:

That's a good question. I haven't see any BBS message editors that

insert a -> so-called "soft CR" and FTS-1 says they (character ->
0x8d)
should be ignored when importing packets, so that whole concept just

seems to be an anachronism. Does anyone actuall -> send/receive

"soft CRs"?

This non standard quoting style works terrible, when requoted... :-(

agreed but it could be handled easily by an intelligent reader... GoldED needs some love to handle them properly... they are actually standards and have been around since the '80s... IIRC, Wildcat! and PCBoard default to them... others, i'm sure... some are editable so the operator can set the default on their system which may or may not include initials... we used to use braces and ANSI a long time ago... some readers today apply their own coloring because some frown on ANSI enhanced posts ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... When all else fails, spend money!
---
* Origin: (1:3634/12.73)

Hi mark,

On 2019-04-18 12:38:10, you wrote to me:

@TID: hpt/lnx 1.9.0-cur 07-09-15

On 2019 Apr 18 17:48:36, you wrote to OZZ NIXON:

Since we're talking about changing intransit mail in different areas. I noticed
something on this message. It arrived here 6 times. On 4 of those there was an empty line between the last kludge and the first line with text as shown above.
On 2 this empty line wasn't there...

Path lines with the empty line:

@PATH: 3634/12 320/219 280/5555
@PATH: 3634/12 320/219 221/1
@PATH: 3634/12 320/219 310/31
@PATH: 3634/12 320/219 5020/545
@PATH: 3634/12 154/10

Without:

@PATH: 3634/12 320/219 203/0
@PATH: 3634/12 320/219 240/5832

Is this annoying? Don't think so. Just found it remarkable...

Could you reply with 2 empty lines between the last kludge and your first line with text? It would be interesting to see what happens. Will just 1 empty line be removed, or both of them. ;)

Btw: In all of them, your long line was untouched.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 2019 Apr 19 18:10:26, you wrote to me:

Since we're talking about changing intransit mail in different areas. I noticed something on this message. It arrived here 6 times. On 4 of those there was an empty line between the last kludge and the first line with text as shown above. On 2 this empty line wasn't there...

all posts leaving this system from GoldED have one blank line after the last control line... that's because my message body template puts one blank line, the ""salutation"" and then the rest of the message body...

Path lines with the empty line:

@PATH: 3634/12 320/219 280/5555
@PATH: 3634/12 320/219 221/1
@PATH: 3634/12 320/219 310/31
@PATH: 3634/12 320/219 5020/545
@PATH: 3634/12 154/10

these are correct...

Without:

@PATH: 3634/12 320/219 203/0
@PATH: 3634/12 320/219 240/5832

something's wrong there... we know that 320/219 is not doing it since it made it through there with the empty line...

Is this annoying? Don't think so. Just found it remarkable...

no, not annoying but it is against spec... it is also interesting... what tossers are running on those two systems, 203/0 and 240/5832?

Could you reply with 2 empty lines between the last kludge and your
first line with text?

i've added another blank line above...

It would be interesting to see what happens. Will just 1 empty line be removed, or both of them. ;)

do tell :)

Btw: In all of them, your long line was untouched.

that's good :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Confuse People. Quote from the wrong message.
---
* Origin: (1:3634/12.73)

no, not annoying but it is against spec...

What spec?

BTW, 2:203/0 is using SquishMail.






..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

mark lewis -> Wilfred van Velzen skrev 2019-04-19 18:29:

all posts leaving this system from GoldED have one blank line after the last control line...

Any particular reason for this? Just curious...





..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 2019 Apr 19 19:18:58, you wrote to me:

no, not annoying but it is against spec...

What spec?

the one that says that mail passing through a system is not to be modified other than necessary for passing on to the next system... you are/were on the FTSC and you could already have your answer if you have gone and searched... it
is one of the basic things denoted when processing mail ;)

BTW, 2:203/0 is using SquishMail.

ok... what version, please? can you capture packets coming in and those generated after and take a look to see if the message body is being modified by
removal of the (blank) line in question?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Kiss me twice. I'm schizophrenic.
---
* Origin: (1:3634/12.73)

On 2019 Apr 19 19:28:18, you wrote to me:

mark lewis -> Wilfred van Velzen skrev 2019-04-19 18:29:

all posts leaving this system from GoldED have one blank line after
the last control line...

Any particular reason for this? Just curious...

because that's the way they are formatted when they leave here ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Murphy was an optimist.
---
* Origin: (1:3634/12.73)

mark lewis -> Bj”rn Felten skrev 2019-04-19 19:59:

On 2019 Apr 19 19:18:58, you wrote to me:

no, not annoying but it is against spec...

What spec?

the one that says

blah blah blah. FTS number please, after all this is where we are.

ok... what version, please? can you capture packets coming in and those generated after and take a look to see if the message body is being modified by removal of the (blank) line in question?

Negatory. That's the beauty of my system. I have absolutely no means to intercept any message on passthru here. Most importantly -- and far less importantly echomail -- netmail. I take real pride in that and have done it this way for a quarter of a century. YMMV.




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Any particular reason for this? Just curious...

because that's the way they are formatted when they leave here ;)

So, you decide what's kosher?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 2019 Apr 19 20:20:30, you wrote to me:

no, not annoying but it is against spec...

What spec?

the one that says

blah blah blah. FTS number please, after all this is where we are.

who is this "we" you speak of? are both of you that lazy? ;)

ok... what version, please? can you capture packets coming in and
those generated after and take a look to see if the message body is
being modified by removal of the (blank) line in question?

Negatory. That's the beauty of my system. I have absolutely no means to intercept any message on passthru here. Most importantly -- and far less importantly echomail -- netmail. I take real pride in that and have done

it

this way for a quarter of a century. YMMV.

oh good grief... all that's being asked for is to capture the PKT with these echomail messages so they can be studied... other than a packet level password that should be X'd out, a hex dump of the PKT would be just fine... this is for
the smooth operation of the network, ya know...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Anger makes dull men witty, but it keeps them poor. -Francis Bacon
---
* Origin: (1:3634/12.73)

On 2019 Apr 19 20:23:34, you wrote to me:

Any particular reason for this? Just curious...

because that's the way they are formatted when they leave here ;)

So, you decide what's kosher?

i decide what leavs my systems and what format they are in... if that's ""kosher"" then sobeit...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I smell smoke. I think my brain's about to go.
---
* Origin: (1:3634/12.73)

mark lewis -> Bj”rn Felten skrev 2019-04-19 21:16:

i decide what leavs my systems and what format they are in... if that's ""kosher"" then sobeit...

No. You've just decided what format it must have when it reaches the receiving system -- according to your, still to be revealed, "spec".



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hi mark,

On 2019-04-19 12:29:04, you wrote to me:

@TID: hpt/lnx 1.9.0-cur 07-09-15

On 2019 Apr 19 18:10:26, you wrote to me:

it is also interesting... what tossers are running on those two
systems, 203/0 and 240/5832?

Bjorn told us. Torsten I don't know exactly. His messages don't contain a TID:,
his areafix answers as 'sqafix'. Maybe that's a clue.

Could you reply with 2 empty lines between the last kludge and your
first line with text?

i've added another blank line above...

Only 2 copies of this message reached me this time, and both had the double blank line.

It would be interesting to see what happens. Will just 1 empty line
be removed, or both of them. ;)

do tell :)

Inconclusive. We need more data... ;)


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello mark!

19 Apr 19 12:29, you wrote to Wilfred van Velzen:

no, not annoying but it is against spec... it is also interesting...
what tossers are running on those two systems, 203/0 and 240/5832?

203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is using at 240/5832.

Could you reply with 2 empty lines between the last kludge and
your first line with text?

i've added another blank line above...

I can confirm that your message arrived here with 2 blank lines before your salutation line.

It would be interesting to see what happens. Will just 1 empty
line be removed, or both of them. ;)

do tell :)

We shall see...

Btw: In all of them, your long line was untouched.

that's good :)

Indeed.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Saturday April 20 2019 03:55, Andrew Leary wrote to mark lewis:

no, not annoying but it is against spec... it is also interesting...
what tossers are running on those two systems, 203/0 and 240/5832?

203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is using at 240/5832.

=== Begin Clipboard ===

Tossing CBAF77EC.PKT from 2:240/5832 to 2:221/360
+-(Squish 1.11, Type 2+) (2 kB, 20-Apr-19 12:42:06)

=== End Clipboard ===

'Tommi

---
* Origin: ---------------------------------->> (2:221/360)

Hello Tommi!

20 Apr 19 14:58, you wrote to me:

203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is
using at 240/5832.

=== Begin Clipboard ===

Tossing CBAF77EC.PKT from 2:240/5832 to 2:221/360
+-(Squish 1.11, Type 2+) (2 kB, 20-Apr-19 12:42:06)

=== End Clipboard ===

That makes sense, then. Both 203/0 and 240/5832 are using Squish. This could be a previously unrecognized bug in Squish.

Andrew


--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)