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

[Brian]

Michael;

On Tue, 2014-12-16 at 08:11 -0800, Michael E Fox - N6MEF wrote:

> O.K.  But if I understand your description correctly, then after you enter a
> string of comma separated addresses, it would still respond with another cc:
> prompt, asking if there are more, to which I'd have to respond with <return>
> to indicate that I'm done with CC, right?  If so, then I'd still have an
> extra prompt and an extra over-the-air exchange.

If you used the SC command yes. If you did not, than no it would not
offer an additional prompt.  A single ax25 frame to continue is no
different than hitting enter to confirm you wish to send a message after
entering in the body.

> 1)  I didn't suggest everyone runs a clone of our system.

Ok.

> 2)  It's not my design and it's not for my specific needs.  It's how modern
> clients work (for the last 20 or so years) and an extra prompt slows
> everyone down.

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. 

> Let's not make this personal.

I wasn't attempting this to be such. Perhaps a better way to phrase it
would have been to maintain backwards compatibility. 

> Which "older emulations" are a problem, specifically?  Is it too much to ask
> those folks to use a current piece of client software, rather than slow
> everyone else down?  Let's suggest whole-system solutions that move everyone
> forward, not backward.  Or, at the very least, if the extra prompt were
> configurable to turn it off, then it wouldn't drag everyone else backwards.

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.

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.

> 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. If you smtp
send yourself a MIME encoded attachment, you'd have to pop receive it,
and your pop client would decode it. I know this is not an issue for
MFNOS. UUCP/MIME (base64), etc., are all designed NOT to send system
control characters of an attachment inside the body of a mail message.
>From a mailbox prompt itself on xNOS, for it to send you an attachment
it would still need some sort of a protocol such as YAPP to do this
after searching for an attachment(s), decoding them, and then try to
send each to you. This would violate SMTP and even POP protocol
procedures. You're basically reading mail from the spool's flatfile, not
popping anyway. You can learn more about this in the upcoming Winter
PSR. The article was already sent and accepted.

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.

The quickest way (IMHO) to move xNOS forward overall (if I understand
you correctly) would be to eliminate it as it is today, 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. 
-- 
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.