SH>>> | Type | 18 | 2 | Int16 | MUST have a value of 2
ml>> this one is pktver... having a 2 means that it is one of the type 2 ml>> formats... if there's a 3 then it is a type 3 packet... a 5 would be ml>> a type 5 packet... the idea of the fixed header was so that software ml>> could at least read this one byte and know if they could possibly ml>> handle the pkt or not...
SH> This is why I named this field as "Type". something with a "2" in the SH> Type field is a "Type 2" packet. It has no name in FTS-0001, and SH> discussions of types generally talk about "Type X" where X matches the SH> value in this field.
ahhh... yes, i see what you mean... maybe PktTypeVer is clearer?
SH> I would like more discussion on this before renaming it to something SH> less obvious just for the purposes of retaining the same name the SH> extension proposals used.
ml>> str is incorrect for this field... it is a nul padded 8 byte array of ml>> characters... str indicates either an ending nul or a leading length ml>> byte...
SH> That's some internal representations of a string, a string is simply a SH> sequence of characters. An array is a set of distinct values... while SH> strings may be implemented as arrays in some languages, they two SH> aren't interchangable and the password is a string.
true... i thought there was a document specifying what to use for certain types like str, int, int16, int32, word, byte, and more but i cannot find it... i've never known of a string in any language to not have some method of determining the end of the string... i'm not sure which way to go... perhaps there should be a chart at the top explaining what things like str, int, int8, int16 and other terms are as they are used in this document?
ml>> same thing for fill... it is a nul padded 20 byte array of ml>> characters...
SH> This one makes more sense. I've changed the type on the fill fields to SH> "Bytes".
ok...
SH>>> This "Capability Word" feature is not specified in this document.
>> not mentioned in this document? which document? it is definitely >> mentioned in this one we're reviewing right now ;)
SH> Not *specified* in this document.
"specified" right... ok... hahaha...
SH> The RFC-822 and different packet types as well as how to negotiate the SH> highest packet type is not specified, only a single bit of the value SH> is specified.
ok... i've always wondered how the highest supported packet type is supposed to be negotiated ;)
SH>>> put the net number in this field. In the case where the originating SH>>> net is 65535 (As recommended by Policy 4), it SHOULD be placed in SH>>> both origNet and auxNet.
>> where is this recommendation by P4? why are political documents being >> referenced in a technical document?
SH> "If your software is capable of using address -1/-1, this is the SH> traditional address used by potential sysops."
SH> The reason it's referenced is because this ends up being a special SH> case of 65535 not indicating a point being used. I've never SH> encountered any other use of a net of 65535.
ahhhh... i thought that was what you were thinking of... as a technical document, discussing this is a "GoodThing<tm> but political documents should not be used to justify its existance... we strive to maintain a distinct separation of technical and political entities... other FTNs do not have a P4 document and they may specify some other value to be used by potential new members that have no other node number they can use to connect with...
ml>> aside from that, it doesn't make sense as to why software should do ml>> this when the original fields are specifically there to hold this ml>> data... the
SH> The reason for this is in FSC-0048:
SH> 2. Although FSC-0039 provides a way to make packet headers 4D SH> it is not backwards compatible. It cannot be used in FTS- SH> 0001 sessions to unknown systems, making FidoNet still not SH> totally 4D capable. Although it implements fields for zone SH> and point number, an FTS-0001 compliant application is not SH> required to look at these fields. When a point mails using SH> these fields to implement its 4D address, a system only SH> looking at the net/node info, as is required by FTS-0001, SH> still sees it as a boss node, causing the obvious problems.
ahhhhh... they were trying to watch out for the situation where a traditional FTN mailer's initial handshake pkt is a Type 2+ instead of a Type 2 or Type 2.2... perhaps that distinction needs to be added? once the mailers have done their handshake they have no need to look at the contents of any other PKTs until possibly after the transaction is complete and the connection terminated...
ml>> since these two are the preferred, rename the other two and leave ml>> these as OrigZone and DestZone.. especially to avoid possible ml>> confusion with "Z2" meaning "zone 2"... ya never know what new ml>> budding programmers or average joes may be reading to learn about ml>> the intracasies of FTN stuffs... in my code, i actually have the ml>> other two named qorgzone and qdstzone... the 'q' being significant ml>> for some old piece of software but i don't recall which one...
SH> The "Z2" part makes sense... how about "origZ+" (the names do not need SH> to be used in code).
true on the names in code but some will try to build their code directly from documentation... i don't know what names to give them, really... for some reason my code, as mentioned before, has qorgzone and qdstzone as well as origzone and destzone... funnily my Type 2 packet definition uses qorgzone and qdstzone for those two fields immediately following the password field...
SH> Since this FSP defines packets in terms of a Type 2 packet, keeping SH> the Type 2 fields fixed was something I worked hard to do. I think SH> the name should highlight that this is a Type 2+ extension.
ahhhh... it wasn't readily apparent that everything was being defined in terms of a Type 2 packet... i can understand why you did that, though... ya done good... i'm not sure which way to go with this now...
ml>> i've never heard it expressed in this manner... specifically the ml>> "variable-length header" part... that section should be better ml>> indicate below as you have done with the fixed-length header here... ml>> see below...
SH> The beginner programmer bit strikes again... it would be easy to think SH> that the other fields could be NUL-padded.
that's possible and i tried to clarify that in the chart by using "up to X+NUL"... brevity can be painful at times... let's see what it looks like when the updated version is posted...
SH> I agonized on putting the datetime in the fixed length vs. the variable SH> length part. Basically, the difference between the two is how a processor SH> would handle a datetime with an invalid length.
true that but there never should be a datetime with an invalid length... having it listed in the fixed-length section should reinforce that it is a fixed-length field of 19 chars plus a NUL... it isn't like one can just use something like
writeln(FormatDateTime(ISO8601,Now));
to get the proper formatted date time string... they must put forth some effort to get one of the current possible string formats...
writeln(FormatDateTime('ddd d mmm yy hh:nn',Now));
(not sure if that last one is space padded for "d" or not)...
SH> If it's a fixed field, using an 18-byte string with two NULs at the SH> end is implicitly valid,
yes as far as fitting into the field but it is implicitly invalid when compared to the two traditional allowed datetime formats, fido (01 Jan 86 02:36:56) and seadog (Mon 1 Jan 86 02:34:56)... i don't recall, and can't look back while writing this post, if you specified the fido and seadog formats and gave examples of them... that should be done if it isn't...
SH> so I put it in the variable length part. I'm not really married to SH> this decision, but I think it needs more discussion.
that's fine by me :)
ml>> | toUserName | array | up to 36+NUL | MUST be NUL terminated
SH> No matter how you clise it, these are strings.
terminology differences... perhaps this would be better?
array | /^[ -~]{0,36}\x00$/
or
bytes | /^[ -~]{0,36}\x00$/
?? ;)
ml>> then follow with something like
ml>> the message body is unbounded. that means that it is not limited in ml>> size by this specification. the message body should be composed of ml>> paragraphs terminated by 0x0d. there should not be any line breaks ml>> attempting to limit the length of the lines in a paragraph. display ml>> of the paragraph is handled by the terminal and it should deal with ml>> the wrapping of paragraph lines according to its view port on the ml>> client's display.
SH> I felt that this was outside the scope of a definition of the packet SH> format, and more suited to a separate document for the message body SH> format. I almost left the packet message format out for the same SH> reason.
first, did you mean "packed message format" in your last sentence?
ahhh... hummm... so this is just the PKT formats and nothing about their contents? if you've got the packed message header defined, you really should include the packed message body in the definition, too... while the packed message header is slightly different from a traditional fido bbs MSG format message, the message body is still unbounded in length and it should have a terminating NUL character...
SH>>> The lengths above do NOT include the NUL terminator.
ml>> shouldn't need this line with the above chart...
SH> Never hurts to be explicit.
true which is why i included the NUL specifically in the chart... but yes, it is ok to be explicit...
ml>> there can be 61 seconds on the day when a lead-second is added... not ml>> allowing for that can cause problems with some software depending on ml>> what they do with the time fields...
SH> Right, but the numbers are 0-60, not 1-61. Done.
true ;)
ml>> these are the only two formats that i've ever seen... the seadog ml>> format comes from the C ISO time format stuff, IIRC... it has a ml>> non-zero-padded day of month but the time is zero-padded but only ml>> hours and minutes... the other (more popular) format dropped the day ml>> of week and added a colon plus the seconds to the time portion... ml>> that took care of the three characters the day of week used... it ml>> had to leave the extra space that trailed the removed day of week to ml>> maintain the field length so it moved that space and added it between ml>> the two digit year and the hour for two spaces in that position...
SH> I'm not sure what change you're suggesting here.
it was only a discussion about the used datetime formats... it might be good to define them explicitly...
SH>>> Some old systems MAY terminate the message text with an EOF (0x1A)
>> or they just terminate the file with no EOF character...
SH> Added.
FWIW: i found out when working with a WWIV system way back... it had to do a double toss to get FTN mail into the system... the first toss was to MSG format and the second toss was from MSG to WWIV's internal format... the WWIV tool refused to import the MSG files created by (IIRC) FMail being used by that system... after weeks and weeks of trying, that operator finally asked me if i could come out and help figure this out... after some time learning the process, a quick look with a hex editor showed the MSG files just terminating with no 0x00 or EOF... i wrote a quick utility that added a trailing 0x00 to each MSG file and the WWIV tool was happy as a lark on a summer's day with those MSG files which it ate and pumped into the WWIV message format... reading the specification of a stored message in FTS-001, it was easy to see why the WWIV tool wanted that ending NUL character ;)
ml>> between messages there should be at least one NUL... message bodies ml>> are unbounded in length but they SHOULD be NUL terminated by the ml>> existing
SH> Yeah, the spec clearly states that the message body is NUL terminated. SH> This is more of a warning to implementers. I've added "Note that" to SH> the beginning of the paragraph to highlight that new implementations SH> should not do this.
i'm confused... the spec states that packed message bodies are terminated by a NUL but you're adding a "note that" new implementations should /not/ do this???
ml>> over all, excellent work gathering this all together and presenting ml>> it like this... i hope you take my comments in the manner they are ml>> intended :)
SH> I was implementing a packet processor/generator, so it made sense to SH> document it all while I was working on it. :-)
i feel it :)
)\/(ark
Always Mount a Scratch Monkey
... Most Scottish food began as a dare. --- * Origin: (1:3634/12.73)
