> MK> No.  See FTS-0004:

 > MK>   "This is not a required field"

 ac>Do you see no advantage in supporting PATH lines?

No, I really don't.  They're 2-D and useless in our modern networks with
5-D FTN addresses and non-FTN addresses.  They're pretty much useless as
soon as you add zones within a single network, for that matter -- is 1/1
1:1/1 or 2:1/1?

What's needed is a more flexible replacement.  I've implemented and
specified one possible version of that (^aSPTH -- see top of this
message and FSC-0067; I'll reprint a bit of FSC-0067.002 just below). It
may not be _the_ solution, but it's a start, and I'm more than willing to
jump on a better bandwagon.

SPTH:   Clint Adams described this as a "5D, sensible order,
        top-of-the-message path" line.  I like that.  Stands for "Sticky
        PaTH."  SPTH displaces the current PATH line.  Instead of being
        located at the bottom of the message, it's located at the top of
        the message.  Instead of being 2-D (net/node), it's 5-D
        (domain#zone:net/node.point)*.  It's sticky like a normal PATH
        line so that the size doesn't get outrageous.  Because it's 5-D
        instead of 2-D it can be used for dupe checking (which a normal
        2-D PATH line cannot; is 1/1 Fidonet#1:1/1 or Dufusnet#2:1/1?).
        Because it's 5-D we would no longer have to go through hideous
        gyrations when gating echo mail from one domain to another; just
        let it flow.  Using SPTH it becomes trivial to cut SEEN-BYs down
        to Tiny Seenbys (only required for backward compatibility with
        old mail processors that barf without some SEEN-BYs, and to
        protect fully enclosed polygon topology).

        SPTH is to be used only in echo mail.  Its format is basically:

            ^aSPTH:   ... 

        SPTH lines, like PATH lines, contain only addresses of mail
        processors that actually processed the message.  SPTH lines are
        specifically not sorted and are "sticky" so that they carry the
        least amount of information that will convey a full address when
        coupled with preceding addresses.  For example, if
        1:380/16.0{at}Fidonet, 1:380/16.1{at}Fidonet, 1:380/100.0{at}Fidonet,
        1:396/100.0{at}Fidonet, 2:4177/1.0{at}Fidonet and 2:4177/1.0{at}Othernet
        processed a message, in that order, you'd have:

         ^aSPTH: Fidonet#1:380/16 .1 100 :396 #2:4177/1 Othernet

        Note that point 0 is assumed if missing and that punctuation
        *precedes* an address element except in the case of a domain
        change (and when the net element is the first change -- this
        dictates that domain names begin with an alphabetical
        character).  This compacts SPTH entries as much as possible for
|       most typical topologies.  In summary, to parse:  check the first
|       character.  If it's numeric, it's a node.  If it's alphabetic,
|       it's a domain.  If it's '#' it's a zone, if ':' it's a net, if
|       '.' it's a point.  Parse from there.

|       *Special exception:  if the first character of an address is '*',
|       it's a non-FTN address and should be treated as just a string.
|       Such address strings may be quoted ("address") if they contain
|       spaces.

        When an SPTH-aware processor forwards a message containing (a)
        PATH line(s) but no SPTH line(s), it should create a new SPTH
        line (or lines as required; SPTH lines shouldn't get longer than
        80 characters, including terminating carriage return) containing
        "fleshed-out" addresses from the PATH line(s), then add itself.
        If this is done at all zone/domain gates, the SPTH will always
        be current even if intermediate nodes are not SPTH-aware.  In
        the event an SPTH-aware processor receives a message containing
        both SPTH line(s) and PATH line(s), it should concatenate the
        "fleshed-out" addresses from the PATH line(s) to the SPTH
        line(s), then add itself.  The PATH line(s) may then be
        discarded from the message.  When exporting new messages, only a
        SPTH line should be created; no PATH line should be generated.
        Tiny Seenbys should be added at the end of the message for the
        reasons noted above.

--- This is just text