On 12/23/19 10:29 PM, John C Klensin wrote:
Keith,
After reading the rest of the thread up until a short time ago,
it seems most appropriate for me to respond to your original
posting in the thread.
>From your description of IIoT requirements, they are not much
different from those of the many devices, some of them embedded,
that used email as a signaling, command, and logging mechanism
in the 1970s through the early 1990s. [...]
To at least some extent, that suggests that some of
your concerns are less about a need for new features or re-tuned
rules but about remembering how we got here and that we should
not get so carried away with trying to match perceived majority
practices for for interpersonal communications that we prohibit
or discourage mechanisms that are needed for important, but
different, uses and applications.
Yes, at least regarding use of email by IIoT devices, I've been thinking
along similar lines. That's not to say that I want to throw away some
of the improvements that have been made in the architecture of the email
system, but I do want to think about how to make the IIoT use of email
interact well with the mainstream use of email.
(IIoT security, by contrast, is an area where I believe existing
"mainstream Internet" solutions are often a poor fit.)
One question for you and others to think about given your
comments about IIoT: if email is used to alert other devices
about exceptional circumstances, maybe there are strong
arguments for the availability and use of SMTP SEND (even if not
SAML or SOML), with the lower overhead of not having to provide
822-based headers, maybe with some rethinking of at least some
trace fields, MX resolution, and relaying as properties
associated with the MAIL command but not of SMTP more generally
(and hence the un-deprecation of that command). My experience
is very anecdotal, but dedicated (embedded or not) applications
needing signaling, etc., were the only good and long-term use I
ever saw for SEND. I saw even fewer for SOML and SAML other
than creating a real-time "you have mail" mechanism as part of
the transmission protocol (even the 1983 version of Unix talk
was probably better). Anyone prepared to make the case for
restoring and revision SEND?
I have doubts about there being much interest in new use of SEND and
friends. A big part of the reason that customers like for IIoT devices
to be able to send email is that such devices can plug into the existing
and widely deployed Internet email infrastructure to deliver messages to
people's desktops and phones. While it wouldn't be hard to implement
a SEND (or more likely SOML) command on an email gateway intended as an
IIoT-to-something forwarder, my guess is that the most likely use of
such a facility would be to gateway to SMS and similar protocols. But
there are lots of ways to do that - including existing email gateways of
course - and it's not clear to me that SEND/SOML would be favored in the
market.
Something I have seen the need for, however, is a service that will
deliver a message immediately if possible, but which won't queue up the
message for very long if immediate delivery is not possible. Nobody
wants to come back to work and find their mailbox full of messages from
an IoT device because, say, the network was down for a time but the
messages were queued up in the interim. SMTP DELIVERBY is already
defined of course, but I don't know how widely it is implemented.
I fear that, in the IoT (and WoT) spaces, we
may end up with a lot of catching up to do that may turn out to
be even more painful than it has been for applications intended
to support communication among humans.
I share those concerns. IoT (as opposed to IIoT) especially looks like
a huge mess to me, because so many vendors seem to see it as a way to
monetize surveillance, and also because the prevailing assumption seems
to be that every device connects to a server "in the cloud" and
interoperation between devices is sometimes seen as something that users
can be made to pay extra for. I keep hoping that a new architecture
will emerge that is designed to protect users' privacy, but I'm not
holding my breath.
But IIoT looks like an area where useful work can be done. I also
believe that there's potential for improvement in interpersonal Internet
email.
Ketih
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp