= Сообщение: 1954 из 7124 ====================================== FTSC_PUBLIC = От : Stephen Hurd 1:103/1 27 Feb 16 23:11:10 Кому : mark lewis 27 Feb 16 23:11:10 Тема : FSP-1040.001 draft 0 FGHI : area://FTSC_PUBLIC?msgid=56.fido-ftscpubl@1:103/1+1b376346 На : area://FTSC_PUBLIC?msgid=1:3634/12.73+56d1ef32 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://FTSC_PUBLIC?msgid=1:3634/12.73+56d31d05 ============================================================================== 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.
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)
