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

[Gustavo Ponza]

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