OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
VE4KLM > JNOS2    01.11.19 04:44l 22 Lines 1235 Bytes #999 (0) @ WW
BID : 21135_VE4KLM
Read: DJ6UX DF7EAV GUEST
Subj: This BID thing and DUPES and stuff
Path: DB0FHN<OE2XZR<OE1XAB<HG8LXL<CX2SA<IW8PGT<IR2UBX<IW2OHX<IR1UAW<I0OJJ<
      I0OJJ<VE4KLM
Sent: 191101/0638z @:VE4KLM.#WPG.MB.CAN.NOAM [Winnipeg] #:21137 $:21135_VE4KLM

playing the devils advocate, I suppose it was wrong of me to impose this change
on the suggestion of a minimal number of people (ie, 1), and perhaps we need to
have a civilized discussion on this. I just took a look at the W0RLI spec and
all it says is that if a BID is missing, the system receiving the message will
assign one. I'm brain dead when it comes to the symantecs of BBS mid/bid ops,
so I depend on others to guid me along. Perhaps the BID assignment is too
generic so if a BID is missing, the then chances of dupes is huge with the
simplied way NOS assigned a BID. Gus, you told me probably years ago that
the BID construct needed to be more 'complex', I forget the word.
Perhaps another solution (Dare I say it), is to get away from this over
simplified NNNNN_CALLSIGN to something that has less chance of creating
a DUPE, we could eliminate dupes and make everyone happy, perhaps by
creating a more intelligent BID value (we have 12 characters no ?)
Just my two cents worth.
This is actually quite fascinating, I need to learn what the real
issue is here, I'm quite open to ideas, I certainly don't want to shut
out my colleqaues in Europe and at the same time make my colleagues in
NA happy as well :)
Maiko / VE4KLM




Read previous mail | Read next mail


 01.05.2026 16:40:48lGo back Go up