= Сообщение: 1963 из 7127 ====================================== FTSC_PUBLIC = От : Stephen Hurd 1:103/1 28 Feb 16 22:18:26 Кому : mark lewis 28 Feb 16 22:18:26 Тема : FSP-1040.001 draft 0 FGHI : area://FTSC_PUBLIC?msgid=67.fido-ftscpubl@1:103/1+1b38a875 На : area://FTSC_PUBLIC?msgid=1:3634/12.73+56d31d05 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://FTSC_PUBLIC?msgid=1:3634/12.73+56d4768f ============================================================================== Re: FSP-1040.001 draft 0 By: mark lewis to Stephen Hurd on Sun Feb 28 2016 09:29 am
> 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?
I've gone with pktType. I don't know what "Ver" would add to this except confusion.
> 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?
Added.
> SH> This one makes more sense. I've changed the type on the fill fields to > SH> "Bytes". > > ok...
I've now changed it again to Undef after adding a description of that type to the new section 1.1:
1.1 Field types used in this document -------------------------------------
Each field in this document has an associated type which defines the format of the field contents. Type values that are used are:
Int8, Int16, Int32: As described above, these are integer values expressed with the number of bits following the "Int" part of the type name. These SHOULD be unsigned integers, but MAY be twos-compliment signed values.
pStr: NUL-padded, fixed length string. Always defined with a count of bytes. NULs are added at the end to fill the field. Since the maximum length of the string is the same as the count of byes, this is not a NUL-terminated string as the last byte may be part of the string.
nStr: NUL-terminated string. A sequence of zero or more non-NUL characters followed by a single NUL character. If a length is specified, does NOT include the terminating NUL. If an nStr with a length of 19 is stored, it will take 20 bytes of storage because of the terminating NUL.
Undef: Undefined sequence of bytes. SHOULD be set to NULs (ASCII zero).
> ok... i've always wondered how the highest supported packet type is supposed > to be negotiated ;)
Basically, the first packet from each node is 2+, then each side needs to keep a copy of the per-node capability word and select the highest common one.
This ends up causing issues if the tosser is replaced with one that supports a differet set or a node number is reuysed, and requires storing details about every node that packets have ever been exchanged with.
> 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...
Yeah, it's a parenthetical example, not normative text.
> 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...
Yeah, but it's not the mailers that do the negotiation, it's the tossers/packers.
> 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...
Well, they can use origZone_plus or origZ_plus or whatever. QOrgZone/QDstZone are used in FSC-0039 and FSC-0048, so you likely started with 2+ then added basic Type 2 support... keeping the same field names to avoid confusion.
> 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...
I do updates as I write replies... the latest version is always available at http://bbsdev.net/fsp/FSP-1040.txt if you want to read it before I next post the whole thing here.
> 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
But having it listed as a NUL-terminated string whose length must be 19 leaves zero wiggle-room at all, which is why I defined it there.
> 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...
I specified the Fido format and gave an exampe of the SEAdog format.
> 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?
Yes, sorry.
> 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...
The MSG format is the most irritating thing about FSC-0001 since that document explicitly states "The application layer is outside the domain of a FidoNet standard".
Anyway, the message body is defined as NUL terminated unlimited length and that's it. Other standards already define control paragraphs, and the rest of the things that are defined are presentation details, not packing details. No packer should need to worry about soft CRs for example.
> it was only a discussion about the used datetime formats... it might be good > to define them explicitly...
Yeah, the Fido format is defined explicitly.
> 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???
No, I'm adding a note that some implementations historically have not done it as follows:
Note that some old systems MAY terminate the message text with an EOF (0x1A) or the literal end of the file. Some even older systems MAY terminate the message text with an empty line (0x0D 0x0A 0x0D 0x0A). To detect this, software MAY use the NUL in the second byte of the Type field to attempt to resynchronize. It is up to the developer if this needs to be supported. --- SBBSecho 2.32-FreeBSD * Origin: BBSDev.net - The BBS Developers Network (1:103/1)
