BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A'
and 'Z' inclusive). Only MS-DOS compatible filename characters
may be included in a BBS-ID.
Since BBSes that support QWK packet technology must
already have a globally unique ID (the so-called BBS-ID or "Board ID"
from which their QWK packet files are named),
it made logical sense to reuse this same ID as the method of
correlating any message received via FidoNet with the avatar data
stored
for the message author.
BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A' and
'Z' inclusive).
Only MS-DOS compatible filename characters may be included in a
BBS-ID.
Although a BBS sysop would best serve their users by having a globally unique BBS-ID, there's no existing known method to insure that is the case. So some creativity and research on the part of the sysop is recommended when determining what their BBS-ID should be and it should
not be changed once the system usership has been established.
Hello Rob,
On Tuesday December 26 2023 15:05, you wrote to All:
BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII
characters, begining with an alphabetic character (betweeen 'A'
and 'Z' inclusive). Only MS-DOS compatible filename characters
may be included in a BBS-ID.
1) In my logic "between 2 and 8" is the range that starts at 3 and ends at 7.
2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.
3) Although I have done my fair share of MS-DOS programming even I do not know out of head any more exactly which characters are allowed in an MS-DOS file name. It has been too long ago. This will only get worse. It may be better not to refer to MS-DOS but to explicitly specify the characters.
4) But why all these restrictions?
5) But the most daring question is: why should this be a FIDONET standard?
6) As a side note I would like to add that the idea is not entirely new.
Good ${greeting_time}, Rob!
26 Dec 2023 15:05:26, you wrote to All:
Since BBSes that support QWK packet technology must
Must?
already have a globally unique ID (the so-called BBS-ID or "Board ID"
What happens if a BBS lacks such ID?
from which their QWK packet files are named),
What if BBS doesn't use QWK?
it made logical sense to reuse this same ID as the method of correlating any message received via FidoNet with the avatar data stored
Where?
for the message author.
Author or BBS?
BBSID: <bbs-id>
Where <bbs-id> is a string of between 2 and 8 monocased ASCII characters, begining with an alphabetic character (betweeen 'A' and
'Z' inclusive).
The word "monocased" reduces the characters to letters.
Only MS-DOS compatible filename characters may be included in a
BBS-ID.
DOSes are dead for over 20 years. What is the reason for such limitation?
2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.
A.
4) But why all these restrictions?
QWK software is largely MS-DOS software, sor for a BBS ID to be QWK-compatible, it generally needs a MS-DOS-compatible base filename.
I'm not saying it should be. I'm just documenting this new kludge that
you and other FTN nodes will find on their networks now (and over the
past few years).
6) As a side note I would like to add that the idea is not entirely
new.
This is in actual use and has been for years now. It's not just an
idea.
Hello Rob,
On Wednesday December 27 2023 18:50, you wrote to me:
2) What exactly do you mean by "monocased"?
A) Upper case only.
B) Either case but the same case for all characters in the string.
C) Any case but case will be ignored when processing.
D) Something else.
A.
Then I suggest you call it just that: "upper case". Using exotic synonims may benefit poets and novel writers but technical documentation should be as clear and unambigues as possible. Especially when part of the intended audience has a different native languange than the author. I have never come across "monocased" and even Google can not help me.
4) But why all these restrictions?
QWK software is largely MS-DOS software, sor for a BBS ID to be QWK-compatible, it generally needs a MS-DOS-compatible base filename.
Backward compatibility has pros and cons. In the beginning of a transition process it can be usefull but later in the transition process the pros erode and the cons get stronger. It gets in the way of the new. Your BBSID proposal is presented as a means to facilitate the use of Avatars in messages. For this use the maximum of 8 upper case ASCII characters is a serious and needless limitation. So why insist on backward compatibility with QWK. QWK is not even a Fidonet standard!
I'm not saying it should be. I'm just documenting this new kludge that you and other FTN nodes will find on their networks now (and over the past few years).
For things that are not strictly within Fidonet but that are usefull to be documented anyway, there is the reference library.
6) As a side note I would like to add that the idea is not entirely
new.
This is in actual use and has been for years now. It's not just an idea.
Henk Wever's GIF kludge was not just an idea either. It has been in actual use for several years.
Henk Wever's GIF kludge was not just an idea either. It has been in actual use for several years.
Henk Wever's GIF kludge was not just an idea either. It has been in
actual use for several years.
Are you refering to this draft (by Sergey Sokoloff)? https://github.com/Mithgol/node-fidonet-jam/blob/master/avatar.txt
Hello Rob,
On Friday December 29 2023 18:00, you wrote to me:
Henk Wever's GIF kludge was not just an idea either. It has been in
actual use for several years.
Are you refering to this draft (by Sergey Sokoloff)? https://github.com/Mithgol/node-fidonet-jam/blob/master/avatar.txt
I was not refering to any document, I was refering to my memory. As I mentioned, it never made it into an FTSC standard. Possible because there was no FTSC yet when it was used. It was used by Henk Wever's bbs/mailer Dutchie that was not used much outside The Netherlands. I am talking about the very early days of Fidonet. end 80ties, begin 90ties. Here is the picture that Henk used in his GIF kludge:
http://www.vlist.eu/fotos/henkweve.gif
I merely meant to point out that having a kludge to facilitate displaying an image representing the author along with the message is not new. Indeed it differs from what you propose in that the GIF kludge directly gives the name of the file that contains the image.
http://www.vlist.eu/fotos/henkweve.gif
Interesting. Did this "GIF kludge" use the same format as defined by Sergey in 2017? The (few) GIF kludges I see in my message bases seem
to match Sergey's definition.
I merely meant to point out that having a kludge to facilitate
displaying an image representing the author along with the message
is not new. Indeed it differs from what you propose in that the GIF
kludge directly gives the name of the file that contains the image.
Yeah, I was aware. I think the BBS ID kludge could have other uses
too.
Even a kludge that is implemented in this in-the-clear system
as FTN is, is fraught with security issues. Anyone in the
chain of transfer can manipulate a message header kludge to
point something untowardly or inappropriate.
Why not? OpenXP doesn't seem to have a problem with it.
A few years ago, there were some duplicate net/nodes across
zones. Not sure of the situation now.
Yeah, I was aware. I think the BBS ID kludge could have other uses
too.
Possibly. But in Fidonet we already have a way to identify a system: the node number. And that is guaranteed to be globally unique within Fidonet.
What we don't have in FidoNet is a way to correlate systems with multiple FTN addresses (from multiple FTNs) as being the *same* system. That's the problem solved with the BBS ID Kludge.
Possibly. But in Fidonet we already have a way to identify a
system: the node number. And that is guaranteed to be globally
unique within Fidonet.
What we don't have in FidoNet is a way to correlate systems with
multiple FTN addresses (from multiple FTNs) as being the *same*
system. That's the problem solved with the BBS ID Kludge.
This was something that I wanted to address in clrghouz.
So my mailer - I do correlate FTNs to a single system, across fidonet
and othernets. It isnt easy (from my vantage point) - because folks
are listed differently in different nodelists (the only tool I have
that gives me that opportunity).
Has it occured to you that listing in a different way in different networks is because they do /not want/ to be correlated across networks?
Has it occured to you that listing in a different way in different
networks is because they do /not want/ to be correlated across
networks?
I have.
But the differences that I was referring to are what I would put in
the category of spelling mistakes, locations specifics or format
errors.
EG: In the case of one sysop, their BBS is listed as "United_States", "Bendigo_Vic", "Bendigo_AUS" and "Bendigo_VIC_AUS". I've seen some examples with Sysop names as well, normally those with Mac... Mc... or their name (or their BBS name) has an apostrophe that is listed in one nodelist and omitted in another.
| Sysop: | Sarah |
|---|---|
| Location: | Portland, Oregon |
| Users: | 19 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 52:49:58 |
| Calls: | 126 |
| Calls today: | 126 |
| Files: | 84,009 |
| U/L today: |
5 files (318K bytes) |
| D/L today: |
33 files (8,385K bytes) |
| Messages: | 38,254 |
| Posted today: | 25 |
