Hello Bryan,

On 09 Feb 16 01:30, Bryan Ashby wrote to All:

 BA> I've been mostly lurking here as FTN "standards" are very relevant to
 BA> my interests right now developing toss/scan/mailer stuff for my soft.

 BA> Anyway, thought I'd chime in here on a couple things since there
 BA> appear to be some panties in wads around these parts.

 BA> I read through this recently and implemented ENiGMA's MSGID similar to
 BA> Synchronet's (e.g. "1234.agn_bbs@46:1/232@l33t.codes 000af878" thoguh
 BA> the address & domain here are just example/made up) for two
 BA> reasons: 1) From the spec: "The originating address should be
 BA> specified in a form that constitutes a valid return address for the
 BA> originating network.". No where in the particular spec does it define
 BA> the address format. It can be implied that it must be a standard FTN
 BA> address *only* but additional data seems to fall within what is
 BA> "valid" here IMO.

 BA> 2) Having additional data is nice here for creating uniqness. The
 BA> "serial" portion leaves quite a lot of space for messages... sure. But
 BA> that assumes one is even using integer ID's for messages in the first
 BA> place. My own system is uing UUIDs. Then as others have mentioned you
 BA> have usenet groups, etc. to deal with.

 BA> Last of my 2c: The "screw 'em" attitude for non FidoNet using FTN or
 BA> people using formats that have been well established for YEARS but
 BA> don't fall exactly within a fairly loose (and sloppy) spec is
 BA> nonsense. It's poisonous in fact.

 BA> The FTN specs are an absolute mess IMO. There are kludges after kludge
 BA> and softwares have been working around all sorts of things to make it
 BA> all work. This is fine as it's very old... but to act like it's
 BA> perfect, that there is no room for improvement, etc.? Please.

Didn't bother quoting the old ass outdated FTSC document, but you are
completely on point here and I agree 100%. Well said!

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160201