[nos-bbs] including original message in replies, comment text in forwards

[Michael E Fox - N6MEF]

> -----Original Message-----
> If you used the SC command yes.

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

> In the event of emergency mobile purposes I know there are those using
> older hardware/software configurations, much of which are donated
> machines and/or dumb terminals. Such a design is for backwards
> compatibility of these systems. We shouldn't lock out a particular point
> of presence because of such. Hitting enter once is a lot faster than
> having to re-enter a full message because a client's system forces a
> ctrl-m after 80 characters and they have no option but to repeat the
> draft of a message to other addresses they couldn't originally enter due
> to limitations of their local config... whatever that may be.

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.

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

> The NTS group here is based on mobility. Much of this is handled by
> donated hardware, many older 80386-based CPU laptops running DOS and
> Qmodem 4 or 5, some Procomm or even Telix. They're a very active group
> who often runs their own drills. They also install packet systems at red
> cross chapters. Considering their cost of receiving donated hardware, it
> would be a bit much to ask them, and insulting to those making the
> donations.

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.


> In the case of MFNOS, as I mentioned, if you feel you need more room for
> addresses than what you think you can buffer in one line or if your
> client appends a ctrl-m after 80 chars, the SC command is available.
> Again, it's much quicker to hit enter once, than to resend a message
> multiple times to insure delivery to a group of people. Of course, the
> sysop can make an internal mail list to get around this if the
> recipients are a set group of people to bypass this as well and then one
> address would be needed to send to everyone on the list, such as this
> list.

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.


> > There are so many things that JNOS needs in order to bring it into the
> > modern world (understand UTF-8, MIME, informative non-delivery
> > notifications, etc.) so it can interact well with current SMTP systems.
> I'd
> > just hate to see time spent going the other direction.
> 
> JNOS, TNOS, MFNOS, SNOS, and others should handle MIME (base64), UUCP,
> etc. as they are.  The decoding is handled by the client software, not
> the server - which xNOS would then be playing this role.

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.

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.


> As for non-delivery messages, I don't know about JNOS, MFNOS does send
> these. Unfortunately, since xNOS' pbbs mail handler back-end is still
> smtp based, it can't determine the difference between pbbs mail and
> standard email which makes it a bit chatty at times.

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. 

> The quickest way (IMHO) to move xNOS forward overall (if I understand
> you correctly) would be to eliminate it as it is today,

I certainly have NOT suggested eliminating JNOS.  

> and rewrite it
> as a user packet shell which can make use of the native apps and
> protocols on its host box rather than trying to re-invent the wheels
> that already exist and while maintaining backwards compatibility for end
> users. A pbbs routine that could tie a user into their mail spool file
> would be required. You'd gain a LOT of speed, lesser CPU load, and you
> could have it launch from a segmented config. Considering, however, the
> amount of work Maiko's done to JNOS I don't see this as being a
> practical solution. It would also then change NOS (network operating
> system) to something else.

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

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.

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.  ;-)

Michael
N6MEF