Text 8078, 181 rader
Skriven 2016-02-27 23:11:10 av Stephen Hurd (56.fido-ftscpubl)
Kommentar till text 8071 av mark lewis (1:3634/12.73)
Ärende: FSP-1040.001 draft 0
============================
Re: FSP-1040.001 draft 0
By: mark lewis to Stephen Hurd on Sat Feb 27 2016 01:47 pm
> s/"original" packet/"original" Type 2 packet/
Done.
> s/packet message/packed message/
Done.
> SH> | Type | 18 | 2 | Int16 | MUST have a value of 2 |
>
> this one is pktver... having a 2 means that it is one of the type 2
> formats... if there's a 3 then it is a type 3 packet... a 5 would be a type
> 5 packet... the idea of the fixed header was so that software could at
> least read this one byte and know if they could possibly handle the pkt or
> not...
This is why I named this field as "Type". something with a "2" in the Type
field is a "Type 2" packet. It has no name in FTS-0001, and discussions of
types generally talk about "Type X" where X matches the value in this field.
I would like more discussion on this before renaming it to something less
obvious just for the purposes of retaining the same name the extension
proposals used.
> SH> | password | 26 | 8 | Str | Packet password, NUL padded |
>
> str is incorrect for this field... it is a nul padded 8 byte array of
> characters... str indicates either an ending nul or a leading length byte...
That's some internal representations of a string, a string is simply a sequence
of characters. An array is a set of distinct values... while strings may be
implemented as arrays in some languages, they two aren't interchangable and the
password is a string.
> same thing for fill... it is a nul padded 20 byte array of characters...
This one makes more sense. I've changed the type on the fill fields to
"Bytes".
> 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 ;)
Not *specified* in this document. The RFC-822 and different packet types as
well as how to negotiate the highest packet type is not specified, only a
single bit of the value is specified.
> 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?
"If your software is capable of using address -1/-1, this is the traditional
address used by potential sysops."
The reason it's referenced is because this ends up being a special case of
65535 not indicating a point being used. I've never encountered any other use
of a net of 65535.
> aside from that, it doesn't make sense as to why software should do this
> when the original fields are specifically there to hold this data... the
The reason for this is in FSC-0048:
2. Although FSC-0039 provides a way to make packet headers 4D
it is not backwards compatible. It cannot be used in FTS-
0001 sessions to unknown systems, making FidoNet still not
totally 4D capable. Although it implements fields for zone
and point number, an FTS-0001 compliant application is not
required to look at these fields. When a point mails using
these fields to implement its 4D address, a system only
looking at the net/node info, as is required by FTS-0001,
still sees it as a boss node, causing the obvious problems.
> since these two are the preferred, rename the other two and leave these as
> OrigZone and DestZone.. especially to avoid possible confusion with "Z2"
> meaning "zone 2"... ya never know what new budding programmers or average
> joes may be reading to learn about the intracasies of FTN stuffs... in my
> code, i actually have the other two named qorgzone and qdstzone... the 'q'
> being significant for some old piece of software but i don't recall which
> one...
The "Z2" part makes sense... how about "origZ+" (the names do not need to be
used in code).
Since this FSP defines packets in terms of a Type 2 packet, keeping the Type 2
fields fixed was something I worked hard to do. I think the name should
highlight that this is a Type 2+ extension.
> pedantic: s/type two packet/type 2 packet/
Done.
> probably should also standardize on "Type" being capatilized, too... Type 2,
> Type 2+, Type 2.2...
Done.
> i've never heard it expressed in this manner... specifically the
> "variable-length header" part... that section should be better indicate
> below as you have done with the fixed-length header here... see below...
The beginner programmer bit strikes again... it would be easy to think that the
other fields could be NUL-padded.
> | datetime | 14 | 20 | array | 19 chars + NUL; see notes |
I agonized on putting the datetime in the fixed length vs. the variable length
part. Basically, the difference between the two is how a processor would
handle a datetime with an invalid length. If it's a fixed field, using an
18-byte string with two NULs at the end is implicitly valid, so I put it in the
variable length part. I'm not really married to this decision, but I think it
needs more discussion.
> | toUserName | array | up to 36+NUL | MUST be NUL terminated |
No matter how you clise it, these are strings.
> then follow with something like
>
> the message body is unbounded. that means that it is not limited in size by
> this specification. the message body should be composed of paragraphs
> terminated by 0x0d. there should not be any line breaks attempting to limit
> the length of the lines in a paragraph. display of the paragraph is handled
> by the terminal and it should deal with the wrapping of paragraph lines
> according to its view port on the client's display.
I felt that this was outside the scope of a definition of the packet format,
and more suited to a separate document for the message body format. I almost
left the packet message format out for the same reason.
> SH> The lengths above do NOT include the NUL terminator.
>
> shouldn't need this line with the above chart...
Never hurts to be explicit.
> there can be 61 seconds on the day when a lead-second is added... not
> allowing for that can cause problems with some software depending on what
> they do with the time fields...
Right, but the numbers are 0-60, not 1-61. Done.
> these are the only two formats that i've ever seen... the seadog format
> comes from the C ISO time format stuff, IIRC... it has a non-zero-padded
> day of month
> but the time is zero-padded but only hours and minutes... the other (more
> popular) format dropped the day of week and added a colon plus the seconds
> to the time portion... that took care of the three characters the day of
> week used... it had to leave the extra space that trailed the removed day
> of week to maintain the field length so it moved that space and added it
> between the two digit year and the hour for two spaces in that position...
I'm not sure what change you're suggesting here.
> SH> Some old systems MAY terminate the message text with an EOF (0x1A)
>
> or they just terminate the file with no EOF character...
Added.
> between messages there should be at least one NUL... message bodies are
> unbounded in length but they SHOULD be NUL terminated by the existing
Yeah, the spec clearly states that the message body is NUL terminated. This is
more of a warning to implementers. I've added "Note that" to the beginning of
the paragraph to highlight that new implementations should not do this.
> over all, excellent work gathering this all together and presenting it like
> this... i hope you take my comments in the manner they are intended :)
I was implementing a packet processor/generator, so it made sense to document
it all while I was working on it. :-)
--- SBBSecho 2.32-FreeBSD
* Origin: BBSDev.net - The BBS Developers Network (1:103/1)
|