| Both sides previous revisionPrevious revision | Next revisionBoth sides next revision |
| wiki:user:digital_man [2021/12/31 11:21] – [Siloed Development] digital man | wiki:user:digital_man [2021/12/31 11:37] – digital man |
|---|
| ==== Packet Format ==== | ==== Packet Format ==== |
| |
| The standard [[ref:FidoNet Packets|FidoNet Packet format]] (so-called "type-2" or "stone age" packet format) was originally specified and accepted as the FidoNet standard in 1987 and hasn't really progressed much since then. Although there were a few proposed packet format replacements twenty-plus years ago, none of them were accepted as a standard. There have been some incremental improvements to the type-2 packet definition (FSCs 39, 45, and 48) and while FSC-48 ("Type-2+") has long been the majority-preferred packet format, none of these improvements has been ratified as a formal standard. | The so-called "type-2" or "stone age" [[ref:FidoNet Packets|FidoNet Packet format]] was originally specified and accepted as the FidoNet standard method of message exchange in 1987 and hasn't really progressed much since then. Although there were a few proposed packet format replacements twenty-plus years ago, none of them were accepted as a standard. There have been some incremental improvements to the type-2 packet definition (FSCs 39, 45, and 48) and while FSC-48 ("Type-2+") has long been the majority-preferred packet format, none of these improvements has been ratified as a formal standard. |
| |
| The problems with the Type-2 packet format and its derivatives (and their "packed message" format) are: | The problems with the Type-2 packet format and its derivatives (and their "packed message" format) are: |
| - Lack of extensibility (no real way to substantially add more header fields or extend the length/range of any already-defined header fields) | - Lack of extensibility (no real way to substantially add more header fields or extend the length/range of any already-defined header fields) |
| - US-ASCII only text field with no support for using Unicode or other character sets | - US-ASCII only text field with no support for using Unicode or other character sets |
| - DateTime header field format that is plain text with 2-digit year | - DateTime header field that is plain text, represents local time, with a 2-digit year |
| - Artificially limited string lengths (i.e. 35 characters names, 71 character subjects, 8 character passwords) | - Artificially limited string lengths (i.e. 35 characters names, 71 character subjects, 8 character passwords) |
| - Relying on NUL-terminated (ASCIIZ) strings (most of the time) | - Relying on NUL-terminated (ASCIIZ) strings (most of the time) |
| ==== Siloed Development ==== | ==== Siloed Development ==== |
| |
| Prior to and during time that FidoNet technology was being originally defined and implemented, there were parallel peer-reviewed developments with similar Internet technologies (e.g. SMTP, NNTP), and yet, FidoNet standards don't reflect any of the learnings or best practices from these open Internet standards or RFCs. This blindness to more robust existing open solutions to the same or similar problems is pervasive throughout the history of FTN. | Prior to and during time that FidoNet technology was being originally defined and implemented, there were parallel peer-reviewed developments with similar Internet technologies (e.g. SMTP, NNTP), and yet, FidoNet standards don't reflect any of the learnings or best practices from these open Internet standards or RFCs. This blindness to more robust existing open solutions to the same or similar problems is pervasive throughout the history of FTN, but is particularly and painfully obvious in [[faq:misc#ftn_msgid|FTN Message-IDs]]. |
| | |
| | ==== Character Sets ==== |
| | |
| | While there have been enhancements to support non-US/English character sets (code pages) and even UTF-8, they're awkward (e.g. you have to parse a message's text to find a CHRS control paragraph before parsing/displaying the header fields correctly?) and not universally supported. Anything other than US-ASCII in message headers or text is clearly an afterthought and mostly does not work as a user would hope. |
| | |
| | ==== Node List ==== |
| | |
| | Any system that requires extensive manual maintenance is bound to be wrong more than it is right and I think the FidoNet node list is an exemplary case. I have not used a node list on my FidoNet-connected BBS in more than 25 years and I don't miss it. The format, purpose, and use of the node list is all highly suspect and begs to be replaced by something more distributed and automated. |
| ===== Why BBS? ===== | ===== Why BBS? ===== |
| |
