Text 8084, 304 rader
Skriven 2016-02-28 09:29:44 av mark lewis (1:3634/12.73)
Kommentar till text 8078 av Stephen Hurd (56.fido-ftscpubl)
Ärende: FSP-1040.001 draft 0
============================
NOTE: quotation fixing for clarity...
27 Feb 16 23:11, you wrote to me:
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.
understood...
SH>>> | password | 26 | 8 | Str | Packet password, NUL padded
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...
ml>> | datetime | 14 | 20 | array | 19 chars + NUL; see notes
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('dd mmm yy hh:nn:ss',Now));
or
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)
|