[nos-bbs] Brief NOS history

[Brian]

Greetings;

On Tue, 2014-12-16 at 17:28 -0800, Michael E Fox - N6MEF wrote:

> Yes, my original question was about the SC and SF commands.

Apparently there was more to your question either not posted or I didn't
see. Your two most recent replies make what you're trying to do clearer.


> Understood.  I just wonder how many users are in this boat and how often it
> happens and why they can't fix that problem themselves by using more current
> software.  As I said, there's lots of functionality we need and my
> supposition is that other features would benefit far more folks far more
> frequently.

You just made it personal, so I'll ignore the above. When gear is
donated you don't INSULT THOSE WHO DONATE IT... aka: don't bite the
hand that feeds you. M$ runs their business model with the above way of
thinking... food for thought.

> But again, as long as we can turn it off, that's fine.

And you can. That's the beauty of backwards compatability.

> My limited understanding of NTS messages is that they have few to no CC's.
> (Not to mention that we haven't seen a real [non-practice] NTS message pass
> through our BBSs in years!)  But if you say there's a real, ongoing,
> regularly occurring need for a legitimate user base then again, I'll accept
> that at face value.  I'm not arguing that it's not useful for anyone.  My
> argument is that, if added, it will slow down everyone else so we should be
> able to disable it.

Just because your BBSs in your region don't use this feature, that
doesn't mean it's not used elsewhere. NTS is passed on a daily basis
here. When there's NTS, there's also reports that need to be made and
sent - to many people at once.

> Yup.  Understood.  But most EmComm messaging is short and can fit in one or
> two packets.  So if you force an extra exchange between the client and
> server, then you've increased the delay by 33-50%.  If you have a small user
> base, that's probably no big deal.  But for a larger system, every little
> bit is important.

Considering you have an MTU of 256 bytes, fitting a ^M into a frame that
may contain 200 bytes is no problem at all. It can still go out in a
single transmission, and unaffecting a congested network. When you think
about it though, a congested network needs revisiting and re-engineering
to properly support the traffic on it.

> Nope.  Remember, JNOS is both a client and a server.  Just two simple
> examples:
> 1)  If someone creates a UTF-8 message (such as from the Windows 8 "Mail"
> tile app), and sends it to my JNOS address, then when I log into JNOS and
> read the message, I see a bunch of jibberish.  
> 2)  If someone sends a MIME message to my JNOS address, then when I log into
> JNOS and read it, I see all the MIME encapsulation junk, even if it's only a
> single part and that part is plain-text.

OK, you're totally mis-defining how things work and you're confusing
yourself. Nos could care less about the true content of the flatfile of
your mail. When you POP it, it's a server to your POP client. YOU are
the client not the server, NOS is. When YOU request to read your mail
from the prompt YOU are still the client. NOS isn't saying "hey that's
Mike, I think I'll push his mail to him without his asking to be a nice
guy". Decoding is the responsibility of the client... you. When you send
mail, NOS is the server to your incoming mail (you are still the
client), THEN it is a client itself to the remote SMTP server it's
sending/relaying your mail to. Think of it this way:
If YOU execute a command to do something, YOU are the CLIENT.


> Sure, if I have an IP network between me and the JNOS system, then I can run
> POP3 or do something more elaborate like Bob Tenty described.  But if I have
> that, then I'll just send a regular email.  The whole need for AX.25 packet
> is when there is no LAN connectivity available.

The N in NOS is for network. If you have AX25 you can MAKE an IP network
to encapsulate under it! After nos was designed as a challenge to get a
DOS pc to talk to a VAX. Later KA9Q discovered he could add server
features to it, an ax25 stack, and a few more gizmos. Since it appears
your true need is to POP mail, route an IP subnet under your ax25. Done
deal! We're doing this with our state police ham network. Can't get
anymore ecomm than that eh? If you're not familiar with this, I'd be
happy to assist. Most xNOS sysops don't know how, so it's not a big
deal. I've been doing it for decades.

> JNOS sends the NDNs, but they don't contain useful information about what
> was wrong, such as no such address or whatever.  So the user knows their
> message didn't go through, but they don't know why or what to do to fix it.
> I've suggested better logging and NDN details to Maiko.  Ultimately, it may
> be that the SMTP stack within JNOS is just too old. 

This should be simple for Maiko.

> I certainly have NOT suggested eliminating JNOS.  

I never said you did. That was my opinion.

> I'm not a software developer so I don't have an opinion about how to solve
> the problem.  

As one, I am aware. Actually Maiko and I have had this discussion in
private.

> My main theme is simple:  in order for packet to continue to remain relevant
> in today's world, it's got to be able to talk to today's other messaging
> systems.  In order to do that, it's got to continue to evolve with the
> relevant RFCs and continue to evolve the user interface in a direction
> that's consistent with other mainstream user interfaces.  I presume you
> would agree with me on that.

NOS code is already extinct compared to modern RFCs. If you were a coder
you'd know this, however the issue isn't with code as much as it is with
cost effectiveness, elmering, and linking to current technologies such
as tablets and smartphones. This is what new hams want to see. The
current methods aren't 100% reasonable.

> But I don't believe it's reasonable to prioritize development time to work
> on 30 year old backward compatibility, especially when there is so much
> forward compatibility to fix/enhance, and especially when folks have the
> ability to solve that problem themselves by upgrading to something that's
> maybe only 10 or 15 years old.  That's the tail wagging the dog, IMHO.  I
> understand we may disagree on that.  ;-)

Not being a coder you wouldn't know that to maintain backwards
compatability is a moot issue as far as the labor involved. I fail to
understand why this is a big thing for you? Only in the M$ type world do
they force you to upgrade to remain compatible with a working system!
See my tagline below.

-- 
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.

73 de Brian Rogers - N1URO
email: <n1uro at n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts, 
New Hampshire, Pennsylvania, 
Rhode Island, and Vermont.