ml>> ahhh... yes, i see what you mean... maybe PktTypeVer is clearer?
SH> I've gone with pktType. I don't know what "Ver" would add to this SH> except confusion.
that works... "ver" only to try to indicate the version but ISWYM...
[trim]
SH> I've now changed it again to Undef after adding a description of that SH> type to the new section 1.1:
SH> 1.1 Field types used in this document SH> -------------------------------------
yes! i like that... it helps to remove any ambiguation that may be perceived...
ml>> ok... i've always wondered how the highest supported packet type is ml>> supposed to be negotiated ;)
SH> Basically, the first packet from each node is 2+, then each side needs SH> to keep a copy of the per-node capability word and select the highest SH> common one.
i still don't understand where the additional packets from the mailer come from and what triggers their transmission... traditional FTN mailers transmit their initial PKT... if the remote mailer doesn't understand it, the connection may be terminated or another protocol may be attempted... another protocol which doesn't use PKTs but can be used to transmit files with a PKT extension... this is, however, probably outside the range of this document... i dunno...
SH> This ends up causing issues if the tosser is replaced with one that SH> supports a differet set or a node number is reuysed, and requires SH> storing details about every node that packets have ever been exchanged SH> with.
yes... plus the tosser doesn't see the initial PKTs that traditional FTN mailers transmit... if the mailers did do this, they would have to support all PKT types and they would end up all using the best one (Type 2+?)... then they still need to communicate that back to the tosser... for non-traditional mailers used in FTNs, the tosser would have to have some method of communicating with other tossers and/or mailers in a non-interactive way...
[trim]
ml>> ahhhhh... they were trying to watch out for the situation where a ml>> traditional FTN mailer's initial handshake pkt is a Type 2+ instead ml>> of a Type 2 or Type 2.2... perhaps that distinction needs to be ml>> added? once the mailers have done their handshake they have no need ml>> to look at the contents of any other PKTs until possibly after the ml>> transaction is complete and the connection terminated...
SH> Yeah, but it's not the mailers that do the negotiation, it's the SH> tossers/packers.
i don't see how they can do that without some sort of special PKTs addressed to the tosser where the tossers can communicate back and forth on their own similar to the way operators can send areafix messages to the tossers and the way that offline mail users can communicate with a BBS' offline mail service to add, remove or rest lastread pointers... that's an interesting idea (tossers talking to each other) that hasn't been seen anywhere AFAIK... traditional tossers won't be able to participate, though, since they do not have the ability to understand this new type of message...
ml>> true on the names in code but some will try to build their code ml>> directly from documentation... i don't know what names to give them, ml>> really... for some reason my code, as mentioned before, has qorgzone ml>> and qdstzone as well as origzone and destzone... funnily my Type 2 ml>> packet definition uses qorgzone and qdstzone for those two fields ml>> immediately following the password field...
SH> Well, they can use origZone_plus or origZ_plus or whatever. SH> QOrgZone/QDstZone are used in FSC-0039 and FSC-0048, so you likely SH> started with 2+ then added basic Type 2 support... keeping the same SH> field names to avoid confusion.
i may very well have... Type 2+ is the first definition i have and then Type 2 and Type 2.2... for some reason i'm getting kicked by a neuron about a Type 2.0 format but i think that was just Type 2 with ".0" added similar to Type 2.2... i don't know of a Type 2.1...
ml>> that's possible and i tried to clarify that in the chart by using "up ml>> to X+NUL"... brevity can be painful at times... let's see what it ml>> looks like when the updated version is posted...
SH> I do updates as I write replies... the latest version is always SH> available at http://bbsdev.net/fsp/FSP-1040.txt if you want to read it SH> before I next post the whole thing here.
:) that's ok, i can wait... i'd rather be able to point to certain things in the most recent posted as they progress... personally i think it is a good document so far... just a few tweaks here and there to enable it to stand closer to being on its own...
ml>> true that but there never should be a datetime with an invalid ml>> length... having it listed in the fixed-length section should ml>> reinforce that it is a fixed-length field of 19 chars plus a NUL... ml>> it isn't like one can just use something like
SH> But having it listed as a NUL-terminated string whose length must be SH> 19 leaves zero wiggle-room at all, which is why I defined it there.
ok :)
[trim]
ml>> ahhh... hummm... so this is just the PKT formats and nothing about ml>> their contents? if you've got the packed message header defined, you ml>> really should include the packed message body in the definition, ml>> too... while the packed message header is slightly different from a ml>> traditional fido bbs MSG format message, the message body is still ml>> unbounded in length and it should have a terminating NUL character...
SH> The MSG format is the most irritating thing about FSC-0001 since that SH> document explicitly states "The application layer is outside the SH> domain of a FidoNet standard".
true but they also defined the mailer comms protocol, too... back when this was done, they also specified the format of the messages... sure, maybe things should have been broken into individual documents but it does document how the original Fido BBS handled this stuff and that's what everything started off as...
SH> Anyway, the message body is defined as NUL terminated unlimited length SH> and that's it. Other standards already define control paragraphs, and SH> the rest of the things that are defined are presentation details, not SH> packing details. No packer should need to worry about soft CRs for SH> example.
true... i agree... FTS-0001 covers more than just mail packers, though...
SH>>> Yeah, the spec clearly states that the message body is NUL SH>>> terminated. This is more of a warning to implementers. I've added SH>>> "Note that" to the beginning of the paragraph to highlight that new SH>>> implementations should not do this.
ml>> i'm confused... the spec states that packed message bodies are ml>> terminated by a NUL but you're adding a "note that" new ml>> implementations should /not/ do this???
SH> No, I'm adding a note that some implementations historically have not done SH> it as follows:
SH> Note that some old systems MAY terminate the message text with an EOF SH> (0x1A) or the literal end of the file. Some even older systems MAY SH> terminate the message text with an empty line (0x0D 0x0A 0x0D 0x0A). SH> To detect this, software MAY use the NUL in the second byte of the Type SH> field to attempt to resynchronize. It is up to the developer if this SH> needs to be supported.
ahhh... ok... that's better... thanks for the clarification :)
)\/(ark
Always Mount a Scratch Monkey
... Tomato paste: what you use to fix broken tomatoes. --- * Origin: (1:3634/12.73)
