Re: FSP-1040.001 draft 0
  By: mark lewis to Stephen Hurd on Mon Feb 29 2016 10:55 pm

 >  ml>> with a PKT extension... this is, however, probably outside the range
 >  ml>> of this document... i dunno...
 >
 >  SH> Yeah, it was pretty clear it was outside the realm of "Type 2
 >  SH> compatible packet formats" and, if anyone actually uses it, should be
 >  SH> documented in a different spec (since by definition it applies to
 >  SH> non-type-2 packets).
 >
 > yes and no... Type 2 PKTs and vairants have the same packed message body
 > format... Type 3 and Type 10 proposals carry a different packed message body
 > format...

I think that was about the capability word, not the packet message body, sorry
I didn't provide enough context in my quoting.

 >  SH> Basically, when you parse a packet, you save the capability word
 >  SH> associated with the node.  When it comes time to packetize, you look
 >  SH> at your saved copy of *their* capability word, and pick the highest
 >  SH> packet format that they support and use that format.
 >
 > when you parse a PKT with what? the mailer or the tosser or any PKT parser?
 > some documents seem to assume that the tosser is doing all the packing but
 > there are mailers that pack messages, too... i'm trying to draw attention to
 > the distinction between them as far as negotiations of the preferred PKT
 > type  go... how is a Type 3 or Type 10 system going to negotiate a Type 3 or
 > Type 10  preferred PKT format if only the tosser can negotiate this? how is
 > the tosser  going to convey this to the mailer?

That's implementation defined.  Basically *something* needs to store the last
capability word seen from a node, and whatever does the packing needs to look
at that.  At the end of it all though, it's a bad idea that would simply end up
causing problems... which is part of the reason I'm not specifying it.

 > understood but i don't know what qualifies as "slow routes" these days where
 > 99% of the traffic is transmitted via the internet in a crash-me-crash-you
 > format... my system is one of few that process mail on a timed schedule
 > instead of an ASAP processing method ;)

Well, the FTSC process is documented as taking six to twelve months to move
something from FSP to FTS, so there's really no rush here.  I think that
posting the full draft more often than once a week would be annoying behaviour.
;-)

 >  SH> Yeah, but this is very much *not* a replacement for FTS-0001.  I'm not
 >  SH> the guy who's going to take that job on.  No sir.  This FSP is just
 >  SH> for software dealing with packets.
 >
 > i can understand that! there's not been many folks willing to stand up and
 > propose a replacement for FTS-0001 in the last few decades though many have
 > raised the spectre of replacing it and they have proffered numerous
 > reasons why it should be done...

My thoughs on replacing FTS-0001 are that it should be done piecemeal, not as a
single spec.  I agree with the statement in FTS-0001 that the stored message
format is outside of what should be stndardized by Fidonet, so I absolutely
won't write a spec for that.

I'm mildly interested in the XModem based packet transfer, but unless/until I
end up writing such a thing then testing it with basically all of Fidonet, I
won't really be able to write that spec either... and without a proper spec for
that, FTS-0001 needs to be kept around.

So yeah, this document may be part of an effort to get rid of FTS-0001, but
there's still a lot of work to do on that front, some of which I'll never do
and some of which I'm merely unlikely to ever do.  :-)
--- SBBSecho 2.32-FreeBSD