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...
SH>>> Yeah, but it's not the mailers that do the negotiation, it's the SH>>> tossers/packers.
ml>> i don't see how they can do that without some sort of special PKTs ml>> addressed to the tosser where the tossers can communicate back and ml>> forth on their own similar to the way operators can send areafix ml>> messages to the tossers and the way that offline mail users can ml>> communicate with a BBS' offline mail
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?
ml>> :) that's ok, i can wait... i'd rather be able to point to certain ml>> things in the most recent posted as they progress... personally i ml>> think it is a good document so far... just a few tweaks here and ml>> there to enable it to stand closer to being on its own...
SH> I plan to post the next draft in a couple days to give slow routes SH> time to provide feedback.
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 ;)
SH>>> Anyway, the message body is defined as NUL terminated unlimited SH>>> length and that's it. Other standards already define control SH>>> paragraphs, and the rest of the things that are defined are SH>>> presentation details, not packing details. No packer should need to SH>>> worry about soft CRs for example.
ml>> true... i agree... FTS-0001 covers more than just mail packers, ml>> though...
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...
)\/(ark
Always Mount a Scratch Monkey
... The trouble is that you think you have the time. --- * Origin: (1:3634/12.73)
