Text 8087, 167 rader
Skriven 2016-02-28 22:18:26 av Stephen Hurd (67.fido-ftscpubl)
   Kommentar till text 8084 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 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)