[nos-bbs] case sensitivity of MID/BID - discussion needed

Michael E Fox - N6MEF n6mef at mefox.org
Mon Feb 9 13:46:04 EST 2015


Gus,

I don't follow what you're saying.

This is not just an academic discussion.  There IS a problem.  There was a
recent case here in NorCal where a single message was forwarded over two
paths.  The MID arriving at the BPQ station over one path was lower case.
It was upper case from the other path.

So, the question is what to do about it. 

One of the earlier emails said that FBB's comparison is case-sensitive.  But
the example I saw showed that FBB changed the case of the incoming MID from
lower to upper case when forwarding to the BPQ station.  Apparently we don't
have all the facts.

M








> -----Original Message-----
> From: nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] On
> Behalf Of Gustavo Ponza
> Sent: Monday, February 9, 2015 9:44 AM
> To: TAPR xNOS Mailing List
> Subject: Re: [nos-bbs] case sensitivity of MID/BID - discussion needed
> 
> Hi Maiko and all,
> 
> as explained below, with the N6RME query message and my reply, the problem
> do not concern the BID/MID project area but only the fallacies of some BBS
> softwares which believe to wrongly reinvent the wheel.
> The lack is on the part of system(s) which wrongly manage the BID/MID
feature
> (read multi-messages if any).
> 
> The fact is that the major standard BBS systems and
> JNOS2 too are almost free from duplicates.
> 
> 73, gus 7 i0ojj
> 
> 
> -------------
> SP N6RME
> Re: BID/MID and BPQ
> 
> Hi Paul,
> good point. Everything OK here, TNX.
> 
> When we refer to dated BBS specs, we are almost concerned with the (x)DOS
> environment, so no care about the use of the upper or lower case ASCII for
> issuing commands or to be indifferently read, as per your example, the
BIDs
> 3112_yt7mpb and 3112_YT7MPB.
> 
> On unix/linux environments everything is case sensitive and so the words:
Rome,
> ROME, rome, RoMe, etc have different meanings and are interpreted as a
> different items.
> 
> As per the two above statements, problems DOESN'T exist because, if I use
one
> of my several systems to write a message, they generate their peculiar
kinda
> BID/MID to identify it and so, everywhere, this will represent the msg
exclusive
> identification.
> 
> The several MID/BID generated/stored by the major systems have the
following
> format:
> 
> Q50I0OJJ_OOY }  obcm/dptnt/diebox and German oriented BBS
> 
> B15337_CX2SA }  mbl/fbb/aa4re/w0rli oriented BBS P11005_N6RME }
> 
> 13337_cx2sa  }  JNOS2/Tnos oriented BBS
> amsatbb1048  }
> 21864_gb7cip }
> arlp006      }
> 
> Now, as stated above, if one (and hopefully not me) is idiot enough to
generate
> two identical (alfa)numeric parts of the BID/MID, one with upper cases
another
> with the lower cases, will cause ONLY (the fact) that the second message
joining
> to a BBS would be discarded because should result (apparently) the same as
the
> previous.
> 
> So, it is my opinion that everything remains as now since (excluding the
> 'pincopallino' idiocy and the false scope of BPQ) the things are running
well and
> nothing should be changed.
> Our life is just complicated per se :)
> 
> 73, gus / i0ojj
> 
> --------------
> >SP I0OJJ < N6RME $11005_N6RME
> >BID/MID and BPQ
> >R:150209/0605Z 1008 at I0OJJ.ILAZ.ITA.EU $:11005_N6RME R:150209/0603Z
> >@:N6RME.#NCA.CA.USA.NOAM #:11005 [El Dorado]
> $:11005_N6RME
> 
> From: N6RME at N6RME.#NCA.CA.USA.NOAM
> To  : I0OJJ at I0OJJ.ILAZ.ITA.EU
> 
> Hi Gus!
> 
> I hope all is well.
> 
> I have been having a discussion with another BBS sysop who uses BPQ
software.
> We discovered that BPQ BBS does not ignore case when comparing BID/MIDs.
> In other words BPQ sees 3112_yt7mpb and 3112_YT7MPB as different
> messages.
> 
> BPQ reads this BBS spec and takes it as a literal meaning:
> The only definition I can find for BID/MID is in W0RLI's BBS Interface
> Specification, published in 1993. Relevant bits are
> 
> The MID looks like a "generated" BID (example 12345_AA4RE).
> ASCII        =  <0x20 - 0x7f>
> ASCII_STR    = ASCII | ASCII_STR ASCII
> BID          =  <ASCII_STR, except ' ', max length 12>
> 
> So it looks like BIDS, and therefore MIDS, can be upper or lower case.
> The definition of "ASCII" here is inclusive of both upper and lower case
ascii,
> suggesting that originating BBS's can use both, which suggests that
comparisons
> should be inclusive of case. However, it SEEMS that there have been
agreements
> between JNOS and FBB authors to the contrary.
> 
> ~~~
> 
> Gus, what do you say? I have never heard of a BBS until now observing case
> when it comes to comparing BID/MIDs.
> 
> 73, Paul - N6RME
> nnnn
> 
> On Sun, 2015-02-08 at 11:53 -0600, Maiko Langelaar wrote:
> > Recently I received an email from a JNOS user, and he brings up a very
> > interesting point. Some of you may have already read up about this on
> > the BPQ32 Yahoo group.
> >
> > Why am I bringing this up ? Apparently the issue cause multiple copies
> > of the same message to appear at people's systems. I suppose one could
> > look at the expression, 'better 2 then none', but anyways ...
> >
> > > I'm no expert on BBSs, but it seems to me the root problem is that
> > > BPQ is making case-sensitive comparisons of MIDs/BIDs and when the
> > > other major BBSs (JNOS, TNOS and apparently FBB) evidently don't
> > > care about case.
> >
> > Putting in my 2 cents worth, JNOS (and TNOS too) may very well be
> > sending out lower case bids for non FBB forwarding session. Other then
> > that, JNOS and TNOS both use uppercase for FBB proposals
> > (automatically uppercase any bid values). As for comparison, JNOS and
> > TNOS use strcasecmp, so the case is actually ignored when 'we' do it. We
don't
> care about case.
> >
> > > After all, if you make the change to always force upper case, then
> > > BPQ still has a problem if an originating BBS uses lower case.  So
> > > either everyone needs to be either case-sensitive or case-insensitive.
Right?
> >
> > I don't want this to be a BPQ vs 'the rest of them' issue.
> >
> > From my perspective, I can try and ensure that NOS is 'consistent'
> > with keeping it uppercase (for starters). But the logistics of asking
> > ALL of the NOS users out there to patch just this one issue is raised.
> > We could probably eliminate the majority of these issues by telling
> > people to just stop using mbox fbb 0 (non fbb forward modes), not sure
> > how well that will be received by sysops. Perhaps that will force them
> > to understand why they are not able to get mbox fbb 1 or higher to work
> properly ?
> >
> > Even if the consensus is to agree to case sensitivity, we still need
> > to get the systems out there updated. What a mess this might be.
> >
> > So, let's talk about it ... the BPQ guys are, so perhaps we should too
> > :)
> >
> > Maybe after this discussion, then we could get the 3 or 4 maintainers
> > or authors to have an internal email talk about the results ? Or am I
> > being naive (even after all these years of doing this) ???
> >
> > Maiko
> > _______________________________________________
> > nos-bbs mailing list
> > nos-bbs at tapr.org
> > http://www.tapr.org/mailman/listinfo/nos-bbs
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> http://www.tapr.org/mailman/listinfo/nos-bbs




More information about the nos-bbs mailing list