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