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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

** 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)

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)

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)

'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)

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)

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)

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)