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

[Michael E Fox - N6MEF]

Glenn,

> I disagree. In not specifying case, the spec is ambiguous. In ASCII, 'A'
> is not the same character as 'a', so the unspecified default would seem to
be
> case sensitive. Modifying the case in any way is an extra operation that
is
> apparently not required.

Agreed in theory.  Unfortunately, the various implementations differ.

If I were writing the code today, I'd pass the MID/BID along unchanged.  But
because the spec does not specify case-sensitivity, then technically, I
don't have to worry about case.  That means I can leave it the same, force
it to upper, or force it to lower.

In the example I saw, a message arrived at a BPQ station by two paths.  On
both paths, it appears that JNOS forced the MID to lower.  On one of the
paths, an FBB station later appears to have forced the MID back to upper.
So BPQ received it twice, with two different cases.

BPQ made the implementation decision to declare different cases as different
MIDs.  But that assumes that case has significance and no such significance
is defined in the spec.

BTW, there are lots of examples where it's perfectly fine to use any case,
but that doesn't mean that the comparison should be made in a case sensitive
manager.  As just one example, consider domain names:  ampr.org, AMPR.ORG,
AMPR.org, ampr.ORG, and AmPr.OrG.  They are all the same domain.  And to use
your example, wb6w and WB6W are the same call sign.

> Again we disagree. The simplest thing to do is not change anything, which
would
> default to case sensitive, as I described above.

But a problem currently exists.  I've seen it.  And Maiko found at least one
case where JNOS behaves differently regarding case, depending on whether fbb
is set to 0, or not.  So doing nothing is not a valid option.  And we know
that JNOS does NOT consider case when making the comparison.  So doing
nothing would NOT default to case sensitive.  Bottom line, it's not that
simple.


>This argues for determining how
> the ambiguity is resolved in the most popular implementations and updating
the
> spec to reflect those implementations.
> A clear case of 'painting the roses red', but at this late date it would
be the
> simplest fix.

Yup ... *UNLESS* there is a good reason for choosing one way or the other.
Perhaps there is.  That's why I suggested the first step is to determine
whether there is a technical reason why case sensitive comparison should be
required.

Michael
N6MEF (upper case!)  ;-)