= Сообщение: 1975 из 7127 ====================================== FTSC_PUBLIC = От : Stephen Hurd 1:103/1 01 Mar 16 20:48:46 Кому : mark lewis 01 Mar 16 20:48:46 Тема : FSP-1040.001 draft 0 FGHI : area://FTSC_PUBLIC?msgid=78.fido-ftscpubl@1:103/1+1b3b367c На : area://FTSC_PUBLIC?msgid=1:3634/12.73+56d514fd = Кодировка сообщения определена как: CP866 ================================== ============================================================================== 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<sp?> 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 * Origin: BBSDev.net - The BBS Developers Network (1:103/1)
