Tillbaka till svenska Fidonet
English   Information   Debug  
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4436
FN_SYSOP   41708
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13615
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16075
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22112
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   930
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1123
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3250
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13301
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/341
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4289
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   33431
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2065
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33946
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24159
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
Möte FTSC_PUBLIC, 13615 texter
 lista första sista föregående nästa
Text 8084, 304 rader
Skriven 2016-02-28 09:29:44 av mark lewis (1:3634/12.73)
   Kommentar till text 8078 av Stephen Hurd (56.fido-ftscpubl)
Ärende: FSP-1040.001 draft 0
============================
NOTE: quotation fixing for clarity...


27 Feb 16 23:11, you wrote to me:

 SH>>> | Type     | 18     | 2     | Int16 | MUST have a value of 2

 ml>> this one is pktver... having a 2 means that it is one of the type 2
 ml>> formats...  if there's a 3 then it is a type 3 packet... a 5 would be
 ml>> a type 5 packet...  the idea of the fixed header was so that software
 ml>> could at least read this one  byte and know if they could possibly
 ml>> handle the pkt or not...

 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?

 SH> I would like more discussion on this before renaming it to something
 SH> less obvious just for the purposes of retaining the same name the
 SH> extension proposals used.

understood...

 SH>>> | password | 26     | 8     | Str   | Packet password, NUL padded

 ml>> str is incorrect for this field... it is a nul padded 8 byte array of
 ml>> characters... str indicates either an ending nul or a leading length
 ml>> byte...

 SH> That's some internal representations of a string, a string is simply a
 SH> sequence of characters.  An array is a set of distinct values... while
 SH> strings may be implemented as arrays in some languages, they two
 SH> aren't interchangable and the password is a string.

true... i thought there was a document specifying what to use for certain types
like str, int, int16, int32, word, byte, and more but i cannot find it... i've
never known of a string in any language to not have some method of determining
the end of the string... i'm not sure which way to go... 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?

 ml>> same thing for fill... it is a nul padded 20 byte array of
 ml>> characters...

 SH> This one makes more sense.  I've changed the type on the fill fields to
 SH> "Bytes".

ok...

 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 ;)

 SH> Not *specified* in this document.

"specified" right... ok... hahaha...

 SH> The RFC-822 and different packet types as well as how to negotiate the
 SH> highest packet type is not specified, only a single bit of the value
 SH> is specified.

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

 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?

 SH> "If your software is capable of using address -1/-1, this is the
 SH> traditional address used by potential sysops."

 SH> The reason it's referenced is because this ends up being a special
 SH> case of 65535 not indicating a point being used.  I've never
 SH> encountered any other use of a net of 65535.

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...

 ml>> aside from that, it doesn't make sense as to why software should do
 ml>> this when  the original fields are specifically there to hold this
 ml>> data... the

 SH> The reason for this is in FSC-0048:

 SH>      2. Although  FSC-0039 provides a way to make packet headers  4D
 SH>         it  is not backwards compatible.  It cannot be used in  FTS-
 SH>         0001 sessions to unknown systems,  making FidoNet still  not
 SH>         totally 4D capable.  Although it implements fields for  zone
 SH>         and point number,  an FTS-0001 compliant application is  not
 SH>         required to look at these fields.  When a point mails  using
 SH>         these  fields  to implement its 4D address,  a  system  only
 SH>         looking  at the net/node info,  as is required by  FTS-0001,
 SH>         still sees it as a boss node, causing the obvious problems.

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...

 ml>> since these two are the preferred, rename the other two and leave
 ml>> these as OrigZone and DestZone.. especially to avoid possible
 ml>> confusion with "Z2" meaning "zone 2"... ya never know what new
 ml>> budding programmers or average joes  may be reading to learn about
 ml>> the intracasies of FTN stuffs... in my code, i  actually have the
 ml>> other two named qorgzone and qdstzone... the 'q' being  significant
 ml>> for some old piece of software but i don't recall which one...

 SH> The "Z2" part makes sense... how about "origZ+" (the names do not need
 SH> to be used in code).

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...

 SH> Since this FSP defines packets in terms of a Type 2 packet, keeping
 SH> the Type 2 fields fixed was something I worked hard to do.  I think
 SH> the name should highlight that this is a Type 2+ extension.

ahhhh... it wasn't readily apparent that everything was being defined in terms
of a Type 2 packet... i can understand why you did that, though... ya done
good... i'm not sure which way to go with this now...

 ml>> i've never heard it expressed in this manner... specifically the
 ml>> "variable-length header" part... that section should be better
 ml>> indicate below  as you have done with the fixed-length header here...
 ml>> see below...

 SH> The beginner programmer bit strikes again... it would be easy to think
 SH> that the other fields could be NUL-padded.

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...

 ml>>      | datetime  | 14     | 20    | array | 19 chars + NUL; see notes

 SH> I agonized on putting the datetime in the fixed length vs. the variable
 SH> length part.  Basically, the difference between the two is how a processor
 SH> would handle a datetime with an invalid length.

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

  writeln(FormatDateTime(ISO8601,Now));

to get the proper formatted date time string... they must put forth some effort
to get one of the current possible string formats...

  writeln(FormatDateTime('dd mmm yy  hh:nn:ss',Now));

or

  writeln(FormatDateTime('ddd d mmm yy hh:nn',Now));

(not sure if that last one is space padded for "d" or not)...

 SH> If it's a fixed field, using an 18-byte string with two NULs at the
 SH> end is implicitly valid,

yes as far as fitting into the field but it is implicitly invalid when compared
to the two traditional allowed datetime formats, fido (01 Jan 86  02:36:56) and
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...

 SH> so I put it in the variable length part.  I'm not really married to
 SH> this decision, but I think it needs more discussion.

that's fine by me :)

 ml>>  | toUserName   | array | up to 36+NUL | MUST be NUL terminated

 SH> No matter how you clise it, these are strings.

terminology differences... perhaps this would be better?

  array | /^[ -~]{0,36}\x00$/

or

  bytes | /^[ -~]{0,36}\x00$/

?? ;)

 ml>> then follow with something like

 ml>> the message body is unbounded. that means that it is not limited in
 ml>> size by this specification. the message body should be composed of
 ml>> paragraphs terminated by 0x0d. there should not be any line breaks
 ml>> attempting to limit the length of the lines in a paragraph. display
 ml>> of the paragraph is handled by the  terminal and it should deal with
 ml>> the wrapping of paragraph lines according to  its view port on the
 ml>> client's display.

 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?

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...

 SH>>>   The lengths above do NOT include the NUL terminator.

 ml>> shouldn't need this line with the above chart...

 SH> Never hurts to be explicit.

true which is why i included the NUL specifically in the chart... but yes, it
is ok to be explicit...

 ml>> there can be 61 seconds on the day when a lead-second is added... not
 ml>> allowing  for that can cause problems with some software depending on
 ml>> what they do with  the time fields...

 SH> Right, but the numbers are 0-60, not 1-61.  Done.

true ;)

 ml>> these are the only two formats that i've ever seen... the seadog
 ml>> format comes  from the C ISO time format stuff, IIRC... it has a
 ml>> non-zero-padded day of month but the time is zero-padded but only
 ml>> hours and minutes... the other (more popular) format dropped the day
 ml>> of week and added a colon plus the seconds to  the time portion...
 ml>> that took care of the three characters the day of week  used... it
 ml>> had to leave the extra space that trailed the removed day of week to
 ml>> maintain the field length so it moved that space and added it between
 ml>> the two digit year and the hour for two spaces in that position...

 SH> I'm not sure what change you're suggesting here.

it was only a discussion about the used datetime formats... it might be good to
define them explicitly...

 SH>>> Some old systems MAY terminate the message text with an EOF (0x1A)

 >> or they just terminate the file with no EOF character...

 SH> Added.

FWIW: i found out when working with a WWIV system way back... it had to do a
double toss to get FTN mail into the system... the first toss was to MSG format
and the second toss was from MSG to WWIV's internal format... the WWIV tool
refused to import the MSG files created by (IIRC) FMail being used by that
system... after weeks and weeks of trying, that operator finally asked me if i
could come out and help figure this out... after some time learning the
process, a quick look with a hex editor showed the MSG files just terminating
with no 0x00 or EOF... i wrote a quick utility that added a trailing 0x00 to
each MSG file and the WWIV tool was happy as a lark on a summer's day with
those MSG files which it ate and pumped into the WWIV message format... reading
the specification of a stored message in FTS-001, it was easy to see why the
WWIV tool wanted that ending NUL character ;)

 ml>> between messages there should be at least one NUL... message bodies
 ml>> are unbounded in length but they SHOULD be NUL terminated by the
 ml>> existing

 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???

 ml>> over all, excellent work gathering this all together and presenting
 ml>> it like this... i hope you take my comments in the manner they are
 ml>> intended :)

 SH> I was implementing a packet processor/generator, so it made sense to
 SH> document it all while I was working on it.  :-)

i feel it :)

)\/(ark

Always Mount a Scratch Monkey

... Most Scottish food began as a dare.
---
 * Origin:  (1:3634/12.73)