Text 8089, 163 rader
Skriven 2016-02-29 11:18:28 av mark lewis (1:3634/12.73)
   Kommentar till text 8087 av Stephen Hurd (67.fido-ftscpubl)
Ärende: FSP-1040.001 draft 0
============================
28 Feb 16 22:18, you wrote to me:

 SH>>> value in this field.

 ml>> ahhh... yes, i see what you mean... maybe PktTypeVer is clearer?

 SH> I've gone with pktType.  I don't know what "Ver" would add to this
 SH> except confusion.

that works... "ver" only to try to indicate the version but ISWYM...

[trim]

 SH> I've now changed it again to Undef after adding a description of that
 SH> type to the new section 1.1:

 SH>   1.1 Field types used in this document
 SH>   -------------------------------------

yes! i like that... it helps to remove any ambiguation that may be perceived...

 ml>> ok... i've always wondered how the highest supported packet type is
 ml>> supposed to be negotiated ;)

 SH> Basically, the first packet from each node is 2+, then each side needs
 SH> to keep a copy of the per-node capability word and select the highest
 SH> common one.

i still don't understand where the additional packets from the mailer come from
and what triggers their transmission... traditional FTN mailers transmit their
initial PKT... if the remote mailer doesn't understand it, the connection may
be terminated or another protocol may be attempted... another protocol which
doesn't use PKTs but can be used to transmit files with a PKT extension... this
is, however, probably outside the range of this document... i dunno...

 SH> This ends up causing issues if the tosser is replaced with one that
 SH> supports a differet set or a node number is reuysed, and requires
 SH> storing details about every node that packets have ever been exchanged
 SH> with.

yes... plus the tosser doesn't see the initial PKTs that traditional FTN
mailers transmit... if the mailers did do this, they would have to support all
PKT types and they would end up all using the best one (Type 2+?)... then they
still need to communicate that back to the tosser... for non-traditional
mailers used in FTNs, the tosser would have to have some method of
communicating with other tossers and/or mailers in a non-interactive way...

[trim]

 ml>> ahhhhh... they were trying to watch out for the situation where a
 ml>> traditional  FTN mailer's initial handshake pkt is a Type 2+ instead
 ml>> of a Type 2 or Type  2.2... perhaps that distinction needs to be
 ml>> added? once the mailers have done  their handshake they have no need
 ml>> to look at the contents of any other PKTs  until possibly after the
 ml>> transaction is complete and the connection  terminated...

 SH> Yeah, but it's not the mailers that do the negotiation, it's the
 SH> tossers/packers.

i don't see how they can do that without some sort of special PKTs addressed to
the tosser where the tossers can communicate back and forth on their own
similar to the way operators can send areafix messages to the tossers and the
way that offline mail users can communicate with a BBS' offline mail service to
add, remove or rest lastread pointers... that's an interesting idea (tossers
talking to each other) that hasn't been seen anywhere AFAIK... traditional
tossers won't be able to participate, though, since they do not have the
ability to understand this new type of message...

 ml>> true on the names in code but some will try to build their code
 ml>> directly from  documentation... i don't know what names to give them,
 ml>> really... for some  reason my code, as mentioned before, has qorgzone
 ml>> and qdstzone as well as  origzone and destzone... funnily my Type 2
 ml>> packet definition uses qorgzone and  qdstzone for those two fields
 ml>> immediately following the password field...

 SH> Well, they can use origZone_plus or origZ_plus or whatever.
 SH> QOrgZone/QDstZone are used in FSC-0039 and FSC-0048, so you likely
 SH> started with 2+ then added basic Type 2 support... keeping the same
 SH> field names to avoid confusion.

i may very well have... Type 2+ is the first definition i have and then Type 2
and Type 2.2... for some reason i'm getting kicked by a neuron about a Type 2.0
format but i think that was just Type 2 with ".0" added similar to Type 2.2...
i don't know of a Type 2.1...

 ml>> that's possible and i tried to clarify that in the chart by using "up
 ml>> to X+NUL"... brevity can be painful at times... let's see what it
 ml>> looks like when  the updated version is posted...

 SH> I do updates as I write replies... the latest version is always
 SH> available at http://bbsdev.net/fsp/FSP-1040.txt if you want to read it
 SH> before I next post the whole thing here.

:) that's ok, i can wait... i'd rather be able to point to certain things in
the most recent posted as they progress... personally i think it is a good
document so far... just a few tweaks here and there to enable it to stand
closer to being on its own...

 ml>> true that but there never should be a datetime with an invalid
 ml>> length... having it listed in the fixed-length section should
 ml>> reinforce that it is a fixed-length field of 19 chars plus a NUL...
 ml>> it isn't like one can just use something like

 SH> But having it listed as a NUL-terminated string whose length must be
 SH> 19 leaves zero wiggle-room at all, which is why I defined it there.

ok :)

[trim]

 ml>> ahhh... hummm... so this is just the PKT formats and nothing about
 ml>> their contents? if you've got the packed message header defined, you
 ml>> really should include the packed message body in the definition,
 ml>> too... while the packed message header is slightly different from a
 ml>> traditional fido bbs MSG format message, the message body is still
 ml>> unbounded in length and it should have a terminating NUL character...

 SH> The MSG format is the most irritating thing about FSC-0001 since that
 SH> document explicitly states "The application layer is outside the
 SH> domain of a FidoNet standard".

true but they also defined the mailer comms protocol, too... back when this was
done, they also specified the format of the messages... sure, maybe things
should have been broken into individual documents but it does document how the
original Fido BBS handled this stuff and that's what everything started off
as...

 SH> Anyway, the message body is defined as NUL terminated unlimited length
 SH> and that's it.  Other standards already define control paragraphs, and
 SH> the rest of the things that are defined are presentation details, not
 SH> packing details.  No packer should need to worry about soft CRs for
 SH> example.

true... i agree... FTS-0001 covers more than just mail packers, though...

 SH>>> Yeah, the spec clearly states that the message body is NUL
 SH>>> terminated. This is more of a warning to implementers.  I've added
 SH>>> "Note that" to the beginning of the paragraph to highlight that new
 SH>>> implementations should not do this.

 ml>> i'm confused... the spec states that packed message bodies are
 ml>> terminated by a  NUL but you're adding a "note that" new
 ml>> implementations should /not/ do this???

 SH> No, I'm adding a note that some implementations historically have not done
 SH> it as follows:

 SH>   Note that some old systems MAY terminate the message text with an EOF
 SH>   (0x1A) or the literal end of the file.  Some even older systems MAY
 SH>   terminate the message text with an empty line (0x0D 0x0A 0x0D 0x0A).
 SH>   To detect this, software MAY use the NUL in the second byte of the Type
 SH>   field to attempt to resynchronize.  It is up to the developer if this
 SH>   needs to be supported.

ahhh... ok... that's better... thanks for the clarification :)

)\/(ark

Always Mount a Scratch Monkey

... Tomato paste: what you use to fix broken tomatoes.
---
 * Origin:  (1:3634/12.73)