• Desired Living Document (section): Author Compliance

    From Ozz Nixon@1:275/362 to All on Friday, March 22, 2019 17:49:37
    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)
  • From mark lewis@1:3634/12.73 to Ozz Nixon on Saturday, March 23, 2019 11:37:10

    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)
  • From Ozz Nixon@1:275/100 to mark lewis on Friday, April 12, 2019 03:31:25
    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)
  • From Rob Swindell to Ozz Nixon on Friday, April 12, 2019 01:54:21
    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.
  • From mark lewis@1:3634/12.73 to Ozz Nixon on Friday, April 12, 2019 09:18:00

    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)
  • From Maurice Kinal@1:153/7001 to mark lewis on Friday, April 12, 2019 17:27:58
    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)
  • From Maurice Kinal@2:280/464.113 to Maurice Kinal on Friday, April 12, 2019 17:57:58
    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)
  • From mark lewis@1:3634/12.73 to Maurice Kinal on Friday, April 12, 2019 14:28:00

    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)
  • From Sean Dennis@1:18/200 to mark lewis on Friday, April 12, 2019 14:55:16
    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)
  • From Sean Dennis@1:18/200 to Maurice Kinal on Friday, April 12, 2019 14:58:38
    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)
  • From Maurice Kinal@2:280/464.113 to Sean Dennis on Friday, April 12, 2019 19:28:54
    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)
  • From Sean Dennis@1:18/200 to Maurice Kinal on Friday, April 12, 2019 15:47:11
    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)
  • From Kees van Eeten@2:280/5003.4 to Maurice Kinal on Friday, April 12, 2019 23:57:48
    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)
  • From Kees van Eeten@2:280/5003.4 to Maurice Kinal on Saturday, April 13, 2019 00:02:40
    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)
  • From Maurice Kinal@2:280/464.113 to Kees van Eeten on Friday, April 12, 2019 22:27:51
    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)
  • From Maurice Kinal@2:280/464.113 to Kees van Eeten on Friday, April 12, 2019 22:35:06
    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)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Friday, April 12, 2019 18:50:50

    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)
  • From Sean Dennis@1:18/200 to Kees van Eeten on Friday, April 12, 2019 23:21:22
    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)
  • From Sean Dennis@1:18/200 to Maurice Kinal on Friday, April 12, 2019 23:23:27
    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)
  • From Maurice Kinal@2:280/464.113 to Sean Dennis on Saturday, April 13, 2019 03:53:35
    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)
  • From Andrew Leary@1:320/219 to Maurice Kinal on Saturday, April 13, 2019 03:03:09
    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)
  • From Maurice Kinal@2:280/464.113 to Andrew Leary on Saturday, April 13, 2019 11:09:27
    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)
  • From Rob Swindell to mark lewis on Sunday, April 14, 2019 01:32:21
    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.
  • From mark lewis@1:3634/12.73 to Rob Swindell on Sunday, April 14, 2019 09:10:24

    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)
  • From Sean Dennis@1:18/200 to mark lewis on Sunday, April 14, 2019 19:54:55
    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)
  • From Rob Swindell to mark lewis on Monday, April 15, 2019 02:45:11
    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.
  • From Kees van Eeten@2:280/5003.4 to Rob Swindell on Monday, April 15, 2019 12:34:10
    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)
  • From Rob Swindell to Kees van Eeten on Monday, April 15, 2019 03:49:59
    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"?
  • From Alexey Vissarionov@2:5020/545 to Rob Swindell on Monday, April 15, 2019 14:14:14
    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)
  • From Kees van Eeten@2:280/5003.4 to Rob Swindell on Monday, April 15, 2019 13:11:38
    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)
  • From Michiel van der Vlist@2:280/5555 to Rob Swindell on Monday, April 15, 2019 11:49:08
    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)
  • From mark lewis@1:3634/12.73 to Sean Dennis on Monday, April 15, 2019 13:05:38

    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)
  • From Sean Dennis@1:18/200 to Rob Swindell on Monday, April 15, 2019 16:46:54
    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)
  • From Sean Dennis@1:18/200 to mark lewis on Monday, April 15, 2019 16:48:04
    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)
  • From OZZ NIXON@1:123/140 to ROB SWINDELL on Thursday, April 18, 2019 11:21:06
    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)
  • From OZZ NIXON@1:123/140 to KEES VAN EETEN on Thursday, April 18, 2019 11:30:36
    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)
  • From Wilfred van Velzen@2:280/464 to OZZ NIXON on Thursday, April 18, 2019 17:48:37
    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)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Thursday, April 18, 2019 12:38:10

    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)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Friday, April 19, 2019 18:10:26
    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)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Friday, April 19, 2019 12:29:04


    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)
  • From Björn Felten@2:203/2 to mark lewis on Friday, April 19, 2019 19:18:59
    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)
  • From Björn Felten@2:203/2 to mark lewis on Friday, April 19, 2019 19:28:18
    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)
  • From mark lewis@1:3634/12.73 to Björn Felten on Friday, April 19, 2019 13:59:12

    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)
  • From mark lewis@1:3634/12.73 to Björn Felten on Friday, April 19, 2019 14:03:06

    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)
  • From Björn Felten@2:203/2 to mark lewis on Friday, April 19, 2019 20:20:30
    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)
  • From Björn Felten@2:203/2 to mark lewis on Friday, April 19, 2019 20:23:34
    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)
  • From mark lewis@1:3634/12.73 to Björn Felten on Friday, April 19, 2019 14:52:16

    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)
  • From mark lewis@1:3634/12.73 to Björn Felten on Friday, April 19, 2019 15:16:30

    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)
  • From Björn Felten@2:203/2 to mark lewis on Friday, April 19, 2019 21:50:45
    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)
  • From Wilfred van Velzen@2:280/464 to mark lewis on Friday, April 19, 2019 22:04:25
    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)
  • From Andrew Leary@1:320/219 to mark lewis on Saturday, April 20, 2019 03:55:10
    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)
  • From Tommi Koivula@2:221/360 to Andrew Leary on Saturday, April 20, 2019 14:58:03

    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)
  • From Andrew Leary@1:320/219 to Tommi Koivula on Saturday, April 20, 2019 08:17:10
    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)