a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.
So, yes, I am more FrontDoor oriented in my head. So, instead of dropping a <unique>.REQ - my poll command can also act as a REQ command. We are using it for software updates ~ and I pondered, as a n00b reading the specs, and implementing them over the past 2 years ~ that it helps clarify what the original draft has about doing a FREQ during the negotiation phase. And as a n00b looking at the specs and the workflow of the BSO environments ~ why would I receive an empty pkt from a system that was forcing a poll. * Not all systems do this, but, a couple have.
b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a poll. If LEN>1 then its a CVS string of 1 or more requests. And to keep with security (.REQ lacks) if the M_REQ file is passworded, the system cound using the same MD5-CRAM logic for the individual file password(s). Why? Security.
>What happens when it is a) User or c) EMSI - is it your intention that binkp >becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch >the BBS login screen. For the later, C) EMSI, is it enabling EMSI on the binkp >port? Why would this be needed over just connecting to a different port that >serves EMSI?
* For systems that the Mailer/BBS work as one ~ yes, I let the user login - like a "FroDo" design (and MANY other systems).
One port vs multiple ports. Security acceptance. The companies I have worked for over the years, network CISO do not like to open multiple ports for any reason. And while many may run a BBS at home ~ in the corporate world, it would be nice to see the BBS and the MAILER serve a purpose again.
So part of my question/inquiry was to see if anyone sees a value or not for the protocol itself. I do, but, I am that American guy who develops on his production system... ;-)
