• Fidonet Reference Library(FSC's)

    From Martin Foster@2:310/31.3 to All on Wednesday, December 30, 2020 12:57:00
    Greetings All!

    Under the first heading of "Fidonet Reference Library" on ftsc.org, I
    see numerous FSC's listed. I would be obliged if someone could tell me
    if these documents are standards, proposals or what, thanks.

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Michiel van der Vlist@2:280/5555 to Martin Foster on Wednesday, December 30, 2020 15:03:25
    Hello Martin,

    On Wednesday December 30 2020 12:57, you wrote to All:

    Under the first heading of "Fidonet Reference Library" on ftsc.org, I
    see numerous FSC's listed. I would be obliged if someone could tell
    me if these documents are standards, proposals or what, thanks.

    They are proposals that for one reason or another did not make it into a standard.

    So: rejected proposals.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.org (2:280/5555)
  • From Oli@2:280/464.47 to Michiel van der Vlist on Wednesday, December 30, 2020 16:03:29
    Michiel wrote (2020-12-30):

    MvdV> Hello Martin,

    MvdV> On Wednesday December 30 2020 12:57, you wrote to All:

    Under the first heading of "Fidonet Reference Library" on ftsc.org,
    I see numerous FSC's listed. I would be obliged if someone could
    tell me if these documents are standards, proposals or what,
    thanks.

    MvdV> They are proposals that for one reason or another did not make it into a
    MvdV> standard.

    MvdV> So: rejected proposals.

    Like fsc-0039.004 with the description "fsc-0039.004"? ;)

    ---
    * Origin: (2:280/464.47)
  • From Martin Foster@2:310/31.3 to Michiel van der Vlist on Thursday, December 31, 2020 11:41:00
    Hello Michiel!

    *** Wednesday 30.12.20 at 15:03, Michiel van der Vlist wrote to Martin Foster:

    Under the first heading of "Fidonet Reference Library" on ftsc.org, I
    see numerous FSC's listed. I would be obliged if someone could tell
    me if these documents are standards, proposals or what, thanks.

    MvdV> They are proposals that for one reason or another did not make it into
    MvdV> a standard.

    MvdV> So: rejected proposals.

    Thank you very much for clarifying that.

    I have questions :)

    [1]Is there any record anywhere of the reason(s) why these proposals
    were rejected?

    [2]Is a software developer permitted to implement any of these
    rejected proposals in his/her software?

    [3]Am I correct in assuming that the FSP's are proposals awaiting
    either acceptance or rejection by the FTSC?

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Carol Shenkenberger@1:275/100 to Michiel van der Vlist on Friday, January 01, 2021 12:07:52
    Re: Fidonet Reference Library(FSC's)
    By: Michiel van der Vlist to Martin Foster on Wed Dec 30 2020 03:03 pm

    Hello Martin,

    On Wednesday December 30 2020 12:57, you wrote to All:

    Under the first heading of "Fidonet Reference Library" on ftsc.org, I
    see numerous FSC's listed. I would be obliged if someone could tell
    me if these documents are standards, proposals or what, thanks.

    They are proposals that for one reason or another did not make it into a standard.

    So: rejected proposals.


    Cheers, Michiel


    Close. If we have some new ones, they merely may be still in proposal stage.

    We get a proposal. It becomes a proposal. If later it shows as a standard, it becomes a standard.

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)
  • From Carol Shenkenberger@1:275/100 to Martin Foster on Friday, January 01, 2021 12:16:11
    Re: Fidonet Reference Library(FSC's)
    By: Martin Foster to Michiel van der Vlist on Thu Dec 31 2020 11:41 am

    Hello Michiel!

    *** Wednesday 30.12.20 at 15:03, Michiel van der Vlist wrote to Martin Foste

    Under the first heading of "Fidonet Reference Library" on ftsc.org, I
    see numerous FSC's listed. I would be obliged if someone could tell
    me if these documents are standards, proposals or what, thanks.

    MvdV> They are proposals that for one reason or another did not make it int
    MvdV> a standard.

    MvdV> So: rejected proposals.

    Thank you very much for clarifying that.

    I have questions :)

    [1]Is there any record anywhere of the reason(s) why these proposals
    were rejected?

    [2]Is a software developer permitted to implement any of these
    rejected proposals in his/her software?

    [3]Am I correct in assuming that the FSP's are proposals awaiting
    either acceptance or rejection by the FTSC?

    Regards,
    Martin


    3 is correct. Many of them are NEVER picked up so never become a standard.
    2 is also correct. Any developer can chose to run with them but they may find if not compatible with others (and is something that has to be), then it doesn't work.
    1 is a 'no'. There is no tracking on just why something someone proposed, never made standard.

    The FTSC doesn't 'reject proposals'. They vote on existing ones that are in use by enough to be a standard.

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)
  • From Oli@2:280/464.47 to Martin Foster on Friday, January 01, 2021 19:44:44
    Martin wrote (2020-12-31):

    I have questions :)

    [1]Is there any record anywhere of the reason(s) why these proposals
    were rejected?

    In some FRLs you find the reasons, but not in FSCs.

    [2]Is a software developer permitted to implement any of these
    rejected proposals in his/her software?

    If you want to write a tosser, you have too implement some proposal that hasn't made it to a standard (like FSC-0039). You can implement whatever proposals you like, but most are just proposals and are rarely supported by any software.

    Do we have a list of FSCs that are relevant?

    [3]Am I correct in assuming that the FSP's are proposals awaiting
    either acceptance or rejection by the FTSC?

    The FTSC is practically dead, nothing will be accepted or rejected anymore.

    ---
    * Origin: (2:280/464.47)
  • From Martin Foster@2:310/31.3 to Carol Shenkenberger on Saturday, January 02, 2021 12:59:00
    Hello Carol!

    *** Friday 01.01.21 at 12:16, Carol Shenkenberger wrote to Martin Foster:

    [snip]
    [1]Is there any record anywhere of the reason(s) why these proposals
    were rejected?

    [2]Is a software developer permitted to implement any of these
    rejected proposals in his/her software?

    [3]Am I correct in assuming that the FSP's are proposals awaiting
    either acceptance or rejection by the FTSC?

    3 is correct. Many of them are NEVER picked up so never become a standard.

    OK, fine.

    2 is also correct. Any developer can chose to run with them
    but they may find if not compatible with others (and is something that
    has to be), then it doesn't work.

    OK, fine.

    I have another question :)

    If a developer chooses to implement one of the FSC's, is it then at
    the discretion of other software developers to provide support(or not)
    for the implementation in their own software?

    1 is a 'no'. There is no tracking on just why something someone
    proposed, never made standard.

    OK, fine.

    The FTSC doesn't 'reject proposals'. They vote on existing ones that are in use by enough to be a standard.

    Ah, by "enough", do you mean in widespread use or what?

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Martin Foster@2:310/31.3 to Oli on Sunday, January 03, 2021 10:50:00
    Hello Oli!

    *** Friday 01.01.21 at 19:44, Oli wrote to Martin Foster:

    [snip]
    Do we have a list of FSCs that are relevant?

    No I don't but others may have :)

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/1.58 to Carol Shenkenberger on Sunday, January 03, 2021 09:58:00
    Hello Carol!

    ** On Friday 01.01.21 - 12:16, Carol Shenkenberger wrote to Martin Foster:

    1 is a 'no'. There is no tracking on just why something someone
    proposed, never made standard.

    Usually, the why (with examples of usage) is present in the
    preamble of the proposal. No?


    The FTSC doesn't 'reject proposals'. They vote on existing ones that are in use by enough to be a standard.

    Ah.. so, should the day arrive when only a minimum of 2 systems
    exist, then as long as they agree to implement any proposal, that
    becomes the new standard? :D

    --
    ../|ug

    --- OpenXP 5.0.48
    * Origin: (2:221/1.58)
  • From August Abolins@2:221/1.58 to Carol Shenkenberger on Sunday, January 03, 2021 10:05:00
    ** On Sunday 03.01.21 - 09:58, August Abolins wrote to Carol Shenkenberger:

    Hello Carol!

    ** On Friday 01.01.21 - 12:16, Carol Shenkenberger wrote to Martin
    Foster:

    1 is a 'no'. There is no tracking on just why something someone
    proposed, never made standard.

    Usually, the why (with examples of usage) is present in the
    preamble of the proposal. No?

    Ooops. I misread. "why a proposal never made into" is not the
    same as "why it should be made into". Please forgive.

    --
    ../|ug

    --- OpenXP 5.0.48
    * Origin: (2:221/1.58)
  • From Carol Shenkenberger@1:275/100 to Martin Foster on Wednesday, January 06, 2021 19:09:26
    Re: Fidonet Reference Library(FSC's)
    By: Martin Foster to Carol Shenkenberger on Sat Jan 02 2021 12:59 pm

    Hello Carol!

    *** Friday 01.01.21 at 12:16, Carol Shenkenberger wrote to Martin Foster:

    [snip]
    [1]Is there any record anywhere of the reason(s) why these proposals
    were rejected?

    [2]Is a software developer permitted to implement any of these
    rejected proposals in his/her software?

    [3]Am I correct in assuming that the FSP's are proposals awaiting
    either acceptance or rejection by the FTSC?

    3 is correct. Many of them are NEVER picked up so never become a standard.

    OK, fine.

    2 is also correct. Any developer can chose to run with them
    but they may find if not compatible with others (and is something that has to be), then it doesn't work.

    OK, fine.

    I have another question :)

    If a developer chooses to implement one of the FSC's, is it then at
    the discretion of other software developers to provide support(or not)
    for the implementation in their own software?

    1 is a 'no'. There is no tracking on just why something someone proposed, never made standard.

    OK, fine.

    The FTSC doesn't 'reject proposals'. They vote on existing ones that a in use by enough to be a standard.

    Ah, by "enough", do you mean in widespread use or what?

    Regards,
    Martin


    Sorry for the delay. Long work hours kicking in. If you implement a proposal, then you can hope others will as well. If you make a secondary tool to create a backwards compatible version for use with systems that need it, it's more apt to work.

    Look at PKZIP. Over time, they added extra options for better encryption and packing but left the tools available to deal with the older versions.

    On the standards, that's a bit of a quality call on 'how much is enough'. Some didn't need much at all, others seem to look for 10% or so.

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)
  • From Carol Shenkenberger@1:275/100 to August Abolins on Wednesday, January 06, 2021 19:34:43
    Re: Fidonet Reference Library(FSC's)
    By: August Abolins to Carol Shenkenberger on Sun Jan 03 2021 09:58 am

    Hello Carol!

    ** On Friday 01.01.21 - 12:16, Carol Shenkenberger wrote to Martin Foster:

    1 is a 'no'. There is no tracking on just why something someone proposed, never made standard.

    Usually, the why (with examples of usage) is present in the
    preamble of the proposal. No?


    The FTSC doesn't 'reject proposals'. They vote on existing ones that a in use by enough to be a standard.

    Ah.. so, should the day arrive when only a minimum of 2 systems
    exist, then as long as they agree to implement any proposal, that
    becomes the new standard? :D

    --
    ../|ug


    The proposal just says why it was written. It can't address why it never (or hasn't yet) become a standard.

    'In use enough' means a lot more than 2 systems.

    You and Stas have something unique. There is no reason to not make a proposal on how it operates. Others may follow it with other tools, or potentially add other tools that work with it for the user end based on iOS in use (as an example). In ASIAN_LINK there is a discussion you are in relating to cell phones and SD cards. An example of a 3rd party utility following relevant portions of a 'standard' to inter-operate with TELEGRAM, would be a case of that if it allowed for use of SIM card storage (or pluggin mini-pin external HD?) to store a bigger backlog of messages than their own device could handle.

    Maybe it would automatically archive older messages to alternative storage at a set point, something like that. They'd have to have enough on how the messages are stored and be part of the 'deleting older ones' process to shift it to copy to alternative storage.

    All I really know about TELEGRAM is it works and I have all the same moderator controls as expected. Including to remove a user if they prove problematic (which none have been). To me, it's a unique OLR type setup. Not really different from using Bluewave etc. on the end seen from others. Nice job!
    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)
  • From August Abolins@1:153/757.2 to Carol Shenkenberger on Thursday, January 07, 2021 10:50:41

    'In use enough' means a lot more than 2 systems.

    Yeah. But "what if" there were at most 3 systems/mailers (and the rest users) in the world - one for each main zone? ;)

    Technically, they could implement all the proposals and that would be their standard - and as long those things don't break some of the older systems should a 4th want to come onboard, then who is to say they are not following standards? ;)


    You and Stas have something unique. There is no reason to not make a proposal on how it operates.

    That would probably take place far from now. But currently it is just a tosser project that complies to existing FTN standards. The Telegram "app" is not modified. But maybe in the future someone could build a version that features things like taglines, quoting options, etc..


    ..In ASIAN_LINK there is a discussion you are in
    relating to cell phones and SD cards. An example of a 3rd party utility following relevant portions of a 'standard' to inter-operate with TELEGRAM, would be a case of that if it allowed for use of SIM card storage (or pluggin mini-pin external HD?) to store a bigger backlog of messages than their own device could handle.

    Correct. Better "offline" capability would be interesting. That could break that advantage of portability though. But right now, the build-in S)earch of the current app is pretty good - as long as one is still connected online.


    All I really know about TELEGRAM is it works and I have all the same moderator controls as expected. Including to remove a user if they prove problematic (which none have been). To me, it's a unique OLR type setup. Not really different from using Bluewave etc. on the end seen from others. Nice job!

    Thank for saying that. I am not sure if the developer follows this echo, but I'll forward your sentiments.
    --- SBBSecho 3.12-Linux
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Oli@2:280/464.47 to Carol Shenkenberger on Friday, January 08, 2021 19:54:21
    Oli wrote (2021-01-07):

    Carol wrote (2021-01-06):

    All I really know about TELEGRAM is it works and I have all the same
    moderator controls as expected. Including to remove a user if they
    prove problematic (which none have been). To me, it's a unique OLR
    type setup. Not really different from using Bluewave etc. on the end
    seen from others.

    and it's also completely different from an offline reader, which doesn't involve big commercial third party messaging services with a privacy policy that the user hasn't agreed to.

    ---
    * Origin: (2:280/464.47)
  • From Carol Shenkenberger@1:275/100 to August Abolins on Saturday, January 30, 2021 14:00:56
    Re: Re: Fidonet Reference Library(FSC's)
    By: August Abolins to Carol Shenkenberger on Thu Jan 07 2021 10:50 am


    'In use enough' means a lot more than 2 systems.

    Yeah. But "what if" there were at most 3 systems/mailers (and the rest user in the world - one for each main zone? ;)

    Technically, they could implement all the proposals and that would be their standard - and as long those things don't break some of the older systems should a 4th want to come onboard, then who is to say they are not following standards? ;)


    You and Stas have something unique. There is no reason to not make a proposal on how it operates.

    That would probably take place far from now. But currently it is just a toss project that complies to existing FTN standards. The Telegram "app" is not modified. But maybe in the future someone could build a version that featur things like taglines, quoting options, etc..


    ..In ASIAN_LINK there is a discussion you are in
    relating to cell phones and SD cards. An example of a 3rd party utility following relevant portions of a 'standard' to inter-operate with TELEGRA would be a case of that if it allowed for use of SIM card storage (or pluggin mini-pin external HD?) to store a bigger backlog of messages than their own device could handle.

    Correct. Better "offline" capability would be interesting. That could break that advantage of portability though. But right now, the build-in S)earch o the current app is pretty good - as long as one is still connected online.


    All I really know about TELEGRAM is it works and I have all the same moderator controls as expected. Including to remove a user if they prove problematic (which none have been). To me, it's a unique OLR type setup. Not really different from using Bluewave etc. on the end seen from others Nice job!

    Thank for saying that. I am not sure if the developer follows this echo, bu I'll forward your sentiments.

    I still need to add in your echos. They should be on but not configured.

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)
  • From Carol Shenkenberger@1:275/100 to Oli on Saturday, January 30, 2021 14:30:23
    Re: Fidonet Reference Library(FSC's)
    By: Oli to Carol Shenkenberger on Fri Jan 08 2021 07:54 pm

    Oli wrote (2021-01-07):

    Carol wrote (2021-01-06):

    All I really know about TELEGRAM is it works and I have all the same
    moderator controls as expected. Including to remove a user if they
    prove problematic (which none have been). To me, it's a unique OLR
    type setup. Not really different from using Bluewave etc. on the end
    seen from others.

    and it's also completely different from an offline reader, which doesn't involve big commercial third party messaging services with a privacy policy that the user hasn't agreed to.


    Functionally it is not a BBS, but a way to read messages. It just uses a smartphone or tablet type device for it. As to the 'privacy policy' that is on the users to keep the data internal to the TELEGRAM delivery only. IE: no porting to others or news-servers etc allowed. No public facing web page portals allowed.

    It becomes in essense an 'APP' on a smartphone and has good potential to reach a wider audience.

    Why do you fear it? Or do I misunderstand you?

    To me, it's just a modern tech of the 2020's that operates in a point-to-point delivery mode that functionall is a way to 'Offline Read' BBS messages in those echos available and respond to what is essentially a 'Boss Node' on Fidonet who then promulgates it to the rest of us. Harmless.

    xxcarol
    --- SBBSecho 2.11-Win32
    * Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)