FR> Also for discussion... IEM vs EMA flags. Are they the same?
EMA should be replaced with IEM.
FR> Additions/Changes are marked with ">" in column 1.
`diff -burN` could be much better...
FR> 5.5. Gateway Flag
Deprecated.
FR> Daylight saving time
The common solution is to work at least two hours a day, one for ZMH and other for ZMH+DST. Proved by R50 for over 20 years, until DST was cancelled here.
FR> 5.8. ISDN Capability Flags
Do anyone still use it?
FR> 5.9. Internet Capabilities FR> <flag>[:<internet address>][:<port>] FR> Where <internet address> is: FR> * a fully qualified domain name (FQDN), or FR> * an IPv6 address encased in square brackets, or FR> * an IPv4 address in dotted-quad format, or FR> * an email address,
Wrong.
Must be <flag>[:<internet address>] where internet address is <email | <fqdn | ipv4 | ipv6>[:<port>]>
FR> This method is not to be used to signal that a system is IPV4 and FR> IPv6 capable. Additional IPv6 capability should be advertised by FR> adding an AAAA record to an already listed host name.
Wrong.
INA:192.0.2.123,INA:[2001:db8:f1d0::1234],IBN is a legal set of flags.
FR> IP (none) Mostly used during the introduction of IP capable FR> systems to the nodelist, is similar to the INA flag FR> but may or may not specify an Internet address. FR> Both usages are deprecated in favour of INA.
Deprecated, should be removed.
FR> IFT 21 FTP (RFC-0959); Note there is currently no widely FR> accepted authentication scheme for FTP transfers by FR> Fidonet mailers.
Deprecated: no common method for delivering direct netmail to such nodes.
FR> ITN 23 Telnet connection using FTS-1 or any other protocol FR> designed for classic POTS and modem. FR> IVM 3141 Vmodem connection using FTS-1 or any other protocol FR> designed for classic POTS and modem.
Deprecated by IFC.
FR> IEM Indicates an unspecified mail tunnelling method (old FR> usage, similar to IP), or sets the default email FR> address for other flags (similar to INA)
Should be changed to "INA-style" only.
FR> ITX TransX encoding for email tunnelling with receipts FR> enabled.
Is there some common method for delivering direct netmail to such nodes? Hereafter "common" implies at least "free cross-platform software".
FR> ISE SEAT protocol for Email tunnelling with receipts. FR> enabled; should always be accompanied by IUC and/or IMI.
Is there some common method for delivering direct netmail to such nodes?
>> EVY Voyager-compatible
Is there some common method for delivering direct netmail to such nodes?
>> EMA Everything not defined by the aforementioned individual flags
So, how should one deliver direct netmail to such nodes?
FR> PING FR> ----
FR> Specified as exactly "PING" with no arguments. Nodes flying this FR> flag will adhere to the following functionality:
FR> 1) PING-function:
FR> If a message destined to "PING" arrives at its final destination FR> and this final destination flies the "PING"-flag, then the FR> receiving node will bounce the message back to the original sender FR> clearly quoting all the original via-lines.
s/clearly/safely/
FR> WARNING: the sender's name (in either direction) must *NEVER* be FR> "PING".
Wrong: if the sender's name is also "PING", the message _must_ be deleted without notice.
FR> 6. User flags FR> -------------
FR> It is impossible to document all user flags in use. The FTSC makes FR> no attempt at it. This document lists those flags which got at FR> least some kind of official sanction or were deemed of technical FR> interest by FTSC.
Here should be a clear notice that user flags _may_ contain anything except "standard" flags, and all unknown flags _must_ be passed through without any changes.
That means ,U,ENC,BEER is ok.
FR> SDS Software Distribution System FR> SMH Secure Mail Hub
Both are deprecated.
FR> CDP This node will accept points auto-created by the CD-point FR> software.
Is there any common implementation?
-- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii
