Response by W0RLI to a query from KB7OGD about BIDs and MIDs Wed Dec 20 19:17:59 1995:

A MID is the identifier of a message, consisting of the message number and BBS callsign. It does not have any particular display format. That is, you could say, "Message 2387 at W0RLI" or you could say, "2387_W0RLI" or you could say "W0RLI's#2387" It is just a way to identify a particular instance of a message. By instance is meant a specific copy of a message: your message to me had it's first instance on your system, as your number xxx, then it was forwarded to me, where a second instance was created on my system. That second instance was my number yyyy. Through the headers, the message carries information about each instance as it forwards from system to system. That's what a MID is about.

A BID is a bulletin identifier. It is just a string of characters, not longer than 12, which stays with every instance of a message. It is not quite that simple however. A BID actually identifies the contents of a message. Thus, a message containing the orbital data for the Oscar birds might be entered in several different BBS at about the same time. When entered into each BBS, it is given the same BID (ORBS-237.O for example) by the person entering it. The BID is used to assure that only one instance of this message will appear at any one BBS. Which original this instance derives from is unimportant. Every bulletin must carry a BID, so that there is a way to assure that only one instance of the bulletin appears at each BBS, no matter how many different paths that bulletin might take on it's way to the particular BBS. So when a user enters a bulletin and does not specify a BID, the system must generate one for him. That is often done by using the information contained in the MID (message number, BBS callsign). Thus we have the "usual" bulletin BID of nnnn_call or call_nnnn or nnnncall, etc. Some system simply generate a unique string of characters possibly unrelated to the system callsign or message number, for example my list server does exactly that.

Personal messages may also carry a BID. This will occur if the user gives the message a BID (sp w0rli@k1ugm.ma.usa.noam $mybid003), or if the message is to be treated like a bulletin and distributed.

An NTS message may never have a BID.

What happens if a personal message has a BID? Normally, nothing unusual happens. However, if that message has to return to a system where an instance of the message already exists, it will be refused. That is the purpose of the BID. This behavior can cause the loss of personal messages, if they are given a BID.

There is also great confusion between the MID and the representation of the MID. The MID "is" the message number and callsign at the system where the particular instance of the message resides. It can be represented any way the author of the software chooses to represent it. I use <12345@W0RLI> for example (complete with the angle brackets). I do it this way to help the sysop avoid confusing the MID with the generated BID, which "is" the string of characters and not some particular number/callsign etc. The confusion arises because the characters normally shown for a MID are the same characters normally shown for a generated BID, even though the two have nothing whatsoever to do with each other. Some BBS programs confuse the two, which causes serious problems when forwarding. This is where duplicates and lost personal messages occur.

There is one more term we need to be able to discuss all the instances of a particular message. A LID is the ID of an instance of a message. The term "MID" is normally used only to mean the LID of a message at the originating bbs. Messages have lots of different "identities".

A final example: that AMSAT bulletin if it originated at your system, and was then forwarded to mine.

At your system it could be "Number 1234 at KB7OGD". At mine it could be "Number 4321 at W0RLI". Those are both LIDs (they identify the particular instance of the message on each system). It's MID is "Number 1234 at KB7OGD" because it originated there. That information is in your header, which is the first header. Its BID is ORBS-237.O, which was assigned by the user who entered it into your system. The BID is the same for every instance.

Now assume the same bulletin was also entered at WA7SJN. At Bill's system it could be "Number 2345 at WA7SJN." That is it's LID at Bill’s system, and also it's MID at any system to which it is forwarded. It has a BID of ORBS-237.O, just like the other two instances above. It cannot be forwarded to me or to you (that would be a duplicate.)

Now let's see what happens at Duane’s system. It could happen that either message (MID of "Number 1234 at KB7OGD" or MID of "2345 at WA7SJN") gets there first. Whichever one gets there second will be rejected. However, Duane will get exactly one copy of the bulletin, and it will have a BID of ORBS-237.O.

Why do we need to consider LIDs and MIDs? Because we need to be able to talk about HOW the instances of a message arrived at a given BBS, so we can track down forwarding problems, problems of data corruption, etc.

Questions like "Why is the ORBS-237.O at WA7SJN different from the one at W0RLI?" crop up from time to time. Usually we just follow the headers back to the source (follow the LIDs back to the MID) and eventually discover the problem. The same technique can be used to discover the source of duplicates as well. Duplicates occur when some system changes the BID it was given, thus producing a "new bulletin" which happens to have the same contents as an existing bulletin.

This should give some idea why it is important to say what that "1234_KB7OGD" "is". It could be a LID, or a MID, or a BID. Until one specifies which one it is, it is simply a string of characters, with no meaning at all. It could be your Visa card balance for all anyone knows.

Comments by W0RLI to WA8BXN on Wed Dec 20 23:53:39 1995:

If it is a P message, and not to a distribution, then it can only have a BID if the user intentionally entered one. If there is no M in the SID, then FBB will behave properly, and only send a BID with the S command. It is that old confusion about message identity (specifically the difference in identity of message instances depending on message type) that Roy started with the "M in the SID" thing. Not having an "M" in one's SID allows things to work properly (rejecting on duplicate BID, marking for sysop attention on duplicate MID.)

The X-BID: line in the rcc-822 header can only be present if there is a BID. If the message does not have a BID, then the X-BID: line must not be present. The X-BID: line is there to pass the BID if the message has one. The MID is passed in the header, as usual. It is the lack of an X-BID: line that tells you the message has no BID, just as the lack of a trailing "$" field on the S command tells you the user did not assign a BID. (Note that this means you can tell the difference between a "real BID" and a "generated BID" and we could pass this info along also. We don't yet, and the protocol has no means to support this feature. My code keeps track of this difference internally.

This has nothing to do with the proposal. The proposal uses a BID if one exists, and a standardized representation of the MID if no BID exists. One must check only against BIDs already seen. The message cannot be rejected on already seen MID. Note that there will not be confusion between a generated BID and a MID as seen in the proposal. BBS programs store them in different databases so they can tell whether a string of characters one has seen before is a MID or is a BID.

So what you do is check for duplicate BID before you get the actual message, because you can reject the message due to a duplicate BID. You check for duplicate MID after you get the message because you cannot reject the message due to a duplicate MID. You can only mark a message, which has a duplicate MID, for attention of the sysop, since there is probably some routing problem. Doing things any other way will result in lost personal messages, as they will be rejected instead of accepted if they happen to pass through a system more than one time. True, this should "never" happen, but it often does, due to routing changes, HF systems which pass messages back and forth depending on time of day, routing loops, mistakes made in addressing messages, etc. It is far better to allow personal messages to go back where they came from instead of just tossing them into the bit bucket. Thus "reject before you get it on duplicate BID, mark after you get it on duplicate MID."