PP> Calling someone "jello brain", "lame brain" or
"ass wipe" won't help
PP> us develop new standard that will help Fidonet... Please come down... 

HS> Ah bullshit, with this thinking you guys are exhibiting, breaking
HS> the address system and eliminating the functionality of
HS> communications with fidonet users is completely out of line, there

THERE IS *NO* ADDRESSING SYSTEM IN FTS-0009...

HS> is no way on earth NEW standards can be develop with that thinking. 
HS> And for what?  For a stupid, idiotic JAM threading system that will
HS> BREAK 95% of the time anyway? Baloney.

if you want to create a new standard, then do so but do not break
existing implementations... given the following from FTS-0009...

=====

 Implementation of the
 protocols defined in this document is not mandatory,  but all
>implementations of these protocols are expected to adhere to this
>standard.

  ^AMSGID: origaddr serialno
           ^^^^^^^^ ^^^^^^^^

 A REPLY line consists of the string "^AREPLY:" (where ^A is a
 control-A (hex 01) and the double-quotes are not part of the
 string),  followed by a space, and the origaddr and serialno
                                        ^^^^^^^^^^^^^^^^^^^^^
 fields of the MSGID line of the message to which this message is a
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 reply,  i.e.:
 ^^^^^

    ^AREPLY: origaddr serialno
             ^^^^^^^^ ^^^^^^^^

>The origaddr and serialno fields must be identical to the
>corresponding fields in the MSGID of the message to which this
>message is a reply.

=====

no where does it say that the ^AREPLY line can contain the origaddr and
serialno fields from a message's REPLY control line... =READ= the spec
and implement it AS IT IS STATED TO BE IMPLEMENTED...

HS> Where does it say in the FTS-9 specs:

HS>   MSGID can be used for ADDRESS. REPLYID can not be used for ADDRESS
HS>   because of the JAM specification.  REPLYID will be unreliable at
HS> this   point because stupid editors will put the WRONG address
HS> during the   ADVANCE CONCEPT "follow up" reply methods.  If your
HS> software does the   proper thing to keep a chain of reply
HS> possibilities, it will break the   JAM specification.  So therefore
HS> because of the JAM specification, do not   use the REPLY for
HS> addressing.

put your head back on straight, hec... JAM came YEARS after FTS-0009 was
written and approved... JAM =USES= FTS=0009 in its implementation... JAM
just happens to also use the MSGID/REPLY control lines for its true
thread linking... do you know how threads work? it doesn't appear that
you do...

the point of my message is this...

 Implementation of the protocols defined in this document is not
 mandatory,  but all implementations of these protocols are expected to
 adhere to this standard.

if you cannot abide by this standard (like you couldn't do with the PID
spec) then please either STOP using it incorrectly OR write your own
spec and get it to be used throughout fidonet... once it is in
widespread use in fidonet, then it MAY become a FTS... who knows...
maybe it will replace FTS-0009, eh? if you do it right, you won't break
or cause problems with other implementations of other specs...

)\/(ark